Blog 

16.11.22 ● Mor Dioum, Lead Cloud and DevOps ● 5 minutes lecture 

Une application Cloud Native est conçue pour tirer tous les avantages du cloud et de ses innovations : développement, exécution, stockage … Attention, une application hébergée sur le cloud ne fait pas d’elle une application Cloud Native. Cette dernière se distingue par son architecture en microservices. Nous allons voir dans cette article ce qu'implique le développement d'une application Cloud Native, ses avantages mais aussi ses complexités.

Avant 2014, nous travaillions sur des structures monolithiques. Un monolithe est un gigantesque bloc de données et de code compact où chaque infime modification influence toute la structure. En bref, un crash quelque part, c’est un crash partout. 

Sauf que le monde a changé, les technologies informatiques et les habitudes consommateurs aussi. Face à l’avènement du cloud computing et des consommateurs toujours plus exigeants, les ingénieurs ont dû redoubler d’ingéniosité pour repenser ces structures monolithiques obsolètes.  C’est ainsi que sont nées les applications Cloud Native offrant des avantages conséquents : 

• réduire le temps des processus d’intégration et de déploiement par l’automatisation (CI & CD) ;

• être en capacité de monter en charge sur des pics d’activités (élasticité / scalabilité) ;

• profiter des fonctionnalités de calcul distribué ;

• bénéficier de l’interopérabilité du logiciel avec d'autres services ou des solutions tierces ;

• développer des applications bien plus résilientes…

En somme, engager une migration de vos applications Legacy vers un modèle Cloud Native, vous permet de développer une offre numérique ultra concurrentielle.

Ce qui distingue un tel modèle d’application c’est son architecture en microservices.  L’application est segmentée en plusieurs microservices : paiement, IAM, formulaire, panier … Chacun des services est isolé, et donc chaque action aussi. Si, hier, un changement sur votre application perturbait toute votre structure, aujourd’hui vous pouvez mettre à jour le microservice n°1, supprimer le microservice n°2, déployer le service n°3 … sans affecter la totalité de votre système. En supprimant l’interdépendance entre vos services, vous accélérez vos processus d’intégration et de déploiement tout en assurant un service continu pour vos clients, et en développant votre offre avec de nouvelles fonctionnalités.

Pour avoir une architecture microservices, il faut séparer chaque unité de votre application dans un conteneur. Dans son conteneur, le microservice bénéficie de son propre environnement d'exécution #donttouchmycode. Là nous pourrions nous dire : “simple/efficace. Si j’ai bien compris, ce sont des boîtes de rangement dans un placard. Je me lance”.  Oui, en effet. Notons toutefois qu’avec le temps les boîtes se multiplient et les administrer une à une relève de l’impossible. Pour éviter les migraines (enfin… à chaque solution suffit sa peine), nous intégrons dans notre pipeline le plus connu des orchestrateurs : Kubernetes !

Kubernetes est l’orchestrateur de conteneur référence. Le fameux gouvernail va vous permettre d’automatiser vos processus de déploiement, de gestion, d’élasticité et autres avantages sur un cluster de serveurs physique ou cloud (privé, public, hybride).

Acteurs du changement depuis près d’une décennie et confortés par tous les indicateurs chiffrés de notre marché, nous en sommes convaincus : les applications cloud native et les technologies qu’elles impliquent sont l’avenir de ceux qui s’y appliquent dans le présent. Il est vital aujourd’hui de migrer son offre numérique sur des architectures en microservices pour bénéficier de ses avantages et rester compétitif.  Alors, est-ce aussi simple que ça ?

Premièrement, développer une offre numérique Cloud Native implique d’intégrer un nouvel outillage, et donc de nouvelles compétences techniques. Soyons honnêtes, Kubernetes n’est pas simple techniquement. Deuxièmement, Kubernetes n’est pas simple humainement. 

Même avec les meilleures ressources humaines IT disponibles sur le marché, votre transition pourrait se conclure par un échec. Il est fondamental de considérer les changements organisationnels indispensables à votre réussite en amont et de les accompagner tout au long de votre migration. 

Nous pouvons citer en premier lieu le concept DevOps - la fédération des développeurs et des opérateurs vers un objectif commun - auquel nous privilégions le concept DevSecOps  - la direction des développeurs, de la sécurité informatique et des opérateurs vers un objectif commun. Mais pas que ! Le Cloud Native et les microservices impliquent toutes les parties prenantes quel que soit leur niveau hiérarchique dans une organisation où la mise en commun des ressources, la communication transversale et la transparence de l'information sont primordiales.

Certes, sur le court terme votre investissement en énergie, en temps et en argent sera plus important que vos retours sur investissement (Comme tout changement de cette ampleur, non ?). Vous allez sûrement devoir faire appel à  des consultants externes, mettre en place des plans de formation internes, augmenter votre consommation de café… Mais ce court terme sera vite remplacé par un moyen terme lucratif et un long terme pérenne si vous engagez votre transition correctement. 

L’audit de vos infrastructures duquel découle votre plan d’action est crucial. Dans celui-ci toutes les parties prenantes doivent être impliquées et l’outillage technique soigneusement sélectionné. Dans cet article “Cloud Computing” nous donnons quelques pistes de questionnement à approfondir pour bien engager une transition vers le cloud. 

Si vous souhaitez échanger avec nous sur vos problématiques techniques et métier, nos équipes se tiennent tout ouïe ici : contact@beopenit.com

Assurons que vos efforts investis dans le cloud soient rentables … dans le temps !

© Copyright BeOpen IT.  All Rights Reserved