Le cloud natif, la solution moderne pour développer des logiciels

De façon générale, le terme « cloud natif » fait référence à une approche qui exploite les avantages du modèle de livraison du cloud pour développer et exécuter des applications. Il désigne la manière dont sont créées et déployées les applications, et non le lieu où elles sont créées. Il implique que les applications résident dans un cloud public et privée non dans un serveur ou une machine virtuelle dédiée sur site. La Cloud Native Computing Foundation (CNCF) a une définition un peu plus circonscrite du « cloud natif ». Selon le CNCF, le « cloud natif’ est une pile logicielle open source destinée à être conteneurisée ; où chaque partie de l'application est packagée dans son propre conteneur ; orchestrée dynamiquement pour que chaque partie soit planifiée et gérée activement afin d'optimiser l’usage des ressources ; orientée microservices pour augmenter l'agilité et la maintenabilité globale des applications.

« Une application cloud native est spécifiquement conçue pour être exécutée dans l’environnement élastique et distribué qui sied aux plates-formes cloud modernes », a expliqué Mike Kavis, directeur général chez Deloitte. « Ces applications sont couplées de manière assez libre. Cela signifie que le code n'est pas lié à l'un des composants de l'infrastructure, si bien que l'application peut être mise à l’échelle à la demande et satisfaire pleinement aux concepts d'infrastructure immuable. En général, ces architectures sont construites à l'aide de microservices, mais ce n'est pas obligatoire ».

Qu’est-ce que le « cloud natif » ?

« Dans le cas des applications cloud natives, la grande différence se situe donc dans la manière dont l'application est construite, livrée et exploitée », a également expliqué Andi Mann, Chief Technology Advocate chez Splunk, un fournisseur de services clouds. « Tirer parti des services clouds signifie utiliser des composants agiles et évolutifs comme les conteneurs pour délivrer des fonctionnalités discrètes et réutilisables qui s'intègrent de manière bien décrite, en s’affranchissant même des limites technologiques comme dans le multicloud. Cela permet aux équipes chargées de la livraison de procéder à une itération rapide en utilisant l'automatisation et l'orchestration reproductible ». Le développement d'applications cloud natives inclut généralement les devops, la méthodologie agile, les microservices, les plates-formes clouds, les conteneurs comme Kubernetes et Docker, et un mode de livraison continu.

En bref, toute nouvelle méthode moderne de déploiement d'applications. C’est pour cette raison que les utilisateurs veulent un modèle de plate-forme en tant que service (PaaS). Mais le PaaS n'est pas nécessaire, même s’il simplifie beaucoup les choses. La grande majorité des clients du cloud démarrent souvent par une infrastructure en tant que service (IaaS), qui permet de dissocier leurs applications du hardware sous-jacent. Mais le PaaS ajoute une couche supplémentaire pour abstraire le système d'exploitation sous-jacent, de sorte qu’ils peuvent se concentrer entièrement sur la logique métier de leur application sans se préoccuper des appels au système d'exploitation.

Quelles différences entre applications natives et applications sur site ?

Le développement d'applications natives nécessite une architecture très différente de celle des applications traditionnelles.

- Les langages

Les applications sur site destinées à tourner sur les serveurs de l'entreprise sont généralement écrites dans des langages traditionnels comme le C/C++, le C# ou un autre langage Visual Studio, si elles sont déployées sur une plate-forme Windows Server, et Java Entreprise. Et si l’ordinateur est un mainframe, c'est probablement du Cobol. Les applications cloud natives sont plutôt écrites dans un langage centré sur le Web, donc HTML, CSS, Java, JavaScript, .Net, Go, Node.js, PHP, Python et Ruby.

- Les possibilités de mise à jour

Les applications cloud natives sont toujours à jour et disponibles. A contrario, les applications sur site ont besoin de mises à jour, généralement fournies par le fournisseur sur la base d'un abonnement. L'installation de ces mises à jour nécessite un temps d’interruption.

• L’élasticité

Les applications cloud natives tirent parti de l'élasticité du cloud, c’est-à-dire qu’en cas de pic d'utilisation elles peuvent disposer de ressources accrues. Si une application de commerce électronique dans le cloud connaît un pic d'utilisation, il est possible de la configurer pour qu'elle utilise des ressources de traitement supplémentaires (calcul, stockage et réseau) jusqu'à la fin du pic, puis de libérer ces ressources. Une application cloud native peut s’ajuster à une augmentation des ressources et de l'échelle selon les besoins. Une application sur site ne peut pas s'adapter dynamiquement.

• Le multi-tenant ou multi-location

Une application cloud native peut fonctionner sans problème dans un espace virtualisé et partager des ressources avec d'autres applications. De nombreuses applications sur site ne s’exécutent pas bien - voire pas du tout - dans un environnement virtuel et ne peuvent fonctionner que dans un environnement non virtualisé.

• Les ressources connectées

Une application sur site est assez rigide pour ce qui est de ses connexions aux ressources du réseau, notamment les réseaux, la sécurité, les permissions et le stockage. Beaucoup de ces ressources ont besoin d'être codées en dur, et elles sont déconnectées si quelque chose est déplacé ou modifié. « Le réseau et le stockage sont complètement différents dans le cloud. On parle de transformation de la plateforme, une opération qui permet de s'adapter aux changements dans les technologies réseaux, de stockage et même les bases de données pour permettre à l'application de s'exécuter dans le cloud », a expliqué Mike Kavis de Deloitte.

• Le temps d’interruption

Il y a plus de redondance dans le cloud qu'il n'y en a dans les environnements sur site, de sorte que si un fournisseur de cloud subit une panne, une autre région peut prendre le relais. Des solutions existent pour basculer les applications sur site, mais si le serveur tombe en panne, il y a de fortes chances que l'application tombe également en panne.

• L’automatisation

Une grande partie du cloud est automatisée. C’est notamment le cas de la gestion des applications. « Les avantages de la livraison d’applications cloud natives, notamment la vitesse et l'agilité, reposent en grande partie sur des processus fiables, éprouvés et vérifiés, exécutés de façon répétée par des outils d'automatisation et d'orchestration et non par une intervention manuelle », a expliqué Andi Mann. Les ingénieurs devraient systématiquement chercher à automatiser virtuellement chaque tâche qui doit être répétée plus d’une fois pour permettre la répétabilité, le libre-service, l'agilité, l'évolutivité, l'audit et le contrôle. Les applications sur site doivent être gérées manuellement.

• La conception modulaire

Les applications sur site sont souvent de conception très monolithique. Certes, elles s’allègent d’une partie du travail en se déchargeant sur les bibliothèques, mais au final, on a toujours une grosse application avec beaucoup de sous-programmes. Les applications cloud natives sont beaucoup plus modulaires, avec de nombreuses fonctions décomposées en microservices. Cela permet de clore les services quand ils ne sont pas nécessaires et de déployer les mises à jour sur un module spécifique, plutôt que sur l'ensemble de l'application.

Des apps sans état

La nature librement couplée du cloud signifie que les applications ne sont pas liées à l'infrastructure. Autrement dit, elles sont sans état. Une application cloud native stocke son état dans une base de données ou une autre entité externe de sorte que lorsqu’on ajoute ou soustrait des instances, l'application arrive toujours à savoir dans quelle unité de travail elle est exécutée. « C'est le fondement même de ce couplage libre. Le fait de ne pas être lié à l'infrastructure permet à l'application de fonctionner de manière hautement distribuée et de maintenir son état indépendamment de la nature élastique de l'infrastructure sous-jacente », a encore expliqué M. Kavis. La plupart des applications sur site sont dites avec état, ce qui signifie qu'elles stockent l'état de l'application sur l'infrastructure sur laquelle le code s'exécute. C’est pour cette raison qu’en cas d'ajout de ressources serveur, l'application peut être rompue.

Les défis de l'informatique cloud native

« L'une des grosses erreurs commises par les entreprises est d'essayer de porter et de migrer leurs anciennes applications sur site vers le cloud », explique M. Mann. « Prendre des applications existantes - en particulier les applications historiques monolithiques - et les transférer sur une infrastructure cloud ne leur permettra pas de profiter des spécificités des applications cloud natives. Elles auraient tout intérêt à faire des choses nouvelles autrement, soit en intégrant de nouvelles applications cloud natives dans une nouvelle infrastructure cloud, soit en remaniant complètement les applications monolithiques existantes selon les principes du cloud natif.

Elles devraient également renoncer à leurs anciennes pratiques de développement. Le modèle traditionnel en cascade ne fera certainement pas l'affaire, et même un développement agile pourrait ne pas suffire. Elles devraient donc adopter de nouvelles approches cloud natives, par exemple le développement de produit minimum viable (MVP), les tests multivariables, l'itération rapide, et la collaboration transversale selon le mode devops. La notion de cloud natif va de pair avec plusieurs caractéristiques, en particulier les services d'infrastructure, l'automatisation/orchestration, la virtualisation et la conteneurisation, l'architecture des microservices et le caractère observable. L’adoption du cloud natif implique de rompre avec les vieilles pratiques. Elle peut se faire de manière progressive.