Cloud native est le nom d’une approche pour créer des applications et de services spécifiquement pour un environnement cloud. Ce sont aussi les caractéristiques de ces applications et services.
Cloud-native est en effet un terme utilisé pour décrire les environnements basés sur des conteneurs. Les technologies cloud-natives sont utilisées pour développer des applications construites avec des services conditionnés dans des conteneurs.
Ces services sont déployés en tant que microservices. Puis, ils sont gérés sur une infrastructure élastique via des processus DevOps agiles et des workflows de livraison continue.
Comment fonctionne le Cloud Native ?
Les équipes opérationnelles géraient manuellement les allocations de ressources d’infrastructure aux applications traditionnelles.
Les applications cloud-natives sont par contre déployées sur une infrastructure. Cette dernière abstrait les primitives de calcul, de stockage et de mise en réseau sous-jacentes.
Les développeurs et opérateurs traitent de cette nouvelle génération d’applications. Ceci étant, ils n’interagissent pas directement avec les interfaces de programmation d’applications (API) exposées par les fournisseurs d’infrastructure.
Au contraire, l’orchestrateur gère l’allocation des ressources automatiquement, selon les politiques définies par les équipes DevOps. Le contrôleur et le planificateur sont en effet des composants essentiels du moteur d’orchestration. Ils gèrent l’allocation des ressources et le cycle de vie des applications.
Les plateformes cloud-natives
Les plateformes cloud-natives, comme Kubernetes, exposent un réseau plat.
Il est en effet superposé aux topologies de réseau existantes et aux primitives des fournisseurs cloud. De même, la couche de stockage native est souvent abstraite pour exposer les volumes logiques intégrés aux conteneurs.
Les opérateurs peuvent allouer des quotas de stockage et des stratégies réseau accessibles aux développeurs et aux administrateurs de ressources.
C’est ainsi que l’abstraction de l’infrastructure répond au besoin de portabilité dans les environnements cloud. Elle permet également aux développeurs de tirer parti des nouvelles tendances pour créer et déployer des applications.
Les gestionnaires d’orchestration deviennent ainsi la cible de déploiement, quelle que soit l’infrastructure sous-jacente. Cette dernière peut en effet être basée sur des serveurs physiques ou des machines virtuelles, des cloud privés ou des cloud publics.
L’importance de Kubernetes
Kubernetes est une plateforme idéale pour exécuter des charges de travail contemporaines conçues comme des applications cloud-natives.
Elle devient ainsi le système d’exploitation de facto pour le cloud, de la même manière que Linux est le système d’exploitation pour les machines sous-jacentes.
Tant que les développeurs suivront les meilleures pratiques de conception et de développement de logiciels sous la forme d’un ensemble de microservices comprenant des applications cloud-natives, les équipes DevOps pourront les packager et les déployer dans Kubernetes.
Pourquoi les applications cloud-natives sont uniques ?
Les applications et services cloud-natifs sont différents de leurs anciens homologues car ils sont spécifiquement conçus pour le cloud dès leur création.
Ceci étant, ils peuvent être déployés et modifiés plus rapidement. Ils ont en effet une architecture plus fluide. Ils peuvent être placés et déplacés facilement dans différents environnements.
Par conséquent, de nombreuses entreprises adaptent leurs anciennes applications créées avant le cloud pour avoir des caractéristiques du cloud-native.
Quoi qu’il en soit, les applications non cloud-natives sont également créées après la montée en puissance du cloud. Elles continueront de l’être dans certaines circonstances.
Avec le cloud, les utilisateurs peuvent accéder aux applications via une connexion Internet. Cela dit, l’application et ses données sont accessibles via potentiellement n’importe quel appareil connecté à Internet.
De plus, des mises à jour et des corrections de bogues peuvent ainsi être fournies aux utilisateurs de manière organique. Si l’application utilise des conteneurs, la mise à l’échelle horizontale devient facile et lorsque la requête atteint un pic, les utilisateurs sont beaucoup moins susceptibles de subir des interruptions.
Les applications cloud-natives sont en principe développées pour exister dans des conteneurs. Elles sont ainsi déployées comme une collection de microservices.
Chacun a ses fonctions respectives au sein d’une application. Elles ont également un système d’intégration et de développement de livraison continue.
La production d’applications et de services cloud-natifs
Conteneurs et microservices
Les applications cloud-natives sont généralement constituées de microservices conditionnés dans des conteneurs.
Ces microservices sont en effet traités indépendamment les uns des autres par les développeurs. Cela leur permet de se concentrer sur les principes fondamentaux d’un microservice pour programmer une fonctionnalité spécialisée.
Les microservices s’exécutent dans des conteneurs gérés par des plateformes telles que Kubernetes.
Le but de ces conteneurs est d’effectuer une seule tâche. Red Hat a publié le livre blanc « Principles of container-based application design (Principes de conception d’applications basées sur des conteneurs) » en 2017. Il parle en fait du principe de préoccupation unique (SCP). Cela signifie que « chaque conteneur doit répondre à une seule préoccupation et bien le faire. »
Pour réaliser une seule tâche, les microservices travaillent bien ensemble avec les conteneurs. L’isolement inhérent aux conteneurs signifie également que les mises à jour d’une application ne peuvent cibler que quelques microservices seulement. Elles ne modifient pas aussi toute une version pour mettre à jour une partie de l’application.
En d’autres termes, les problèmes et les bogues qui se trouvent dans une application peuvent être détectés et résolus plus rapidement et avec une plus grande spécificité.
Intégration continue/Système de développement de livraison continue
Une architecture de microservices et une infrastructure de conteneurs d’applications cloud-natives permettent aux services informatiques d’identifier rapidement un problème.
Elles permettent également de le résoudre sans affecter l’ensemble du système. Contrairement dans le développement d’applications traditionnel, les mises à jour étaient une révision totale du logiciel.
Le système de correction constante des bogues et de déploiement des mises à jour est appelé intégration continue et livraison continue (CI/CD). Pour le rendre facile, les groupes de développement de logiciels et d’opérations informatiques sont souvent combinés en équipes DevOps plus petites.
Un service informatique en évolution
Le passage d’une application ou une plateforme entière d’une grande version à l’approche CI/CD entraîne un changement dans la structure du service informatique d’une entreprise et de son flux de travail.
Ce changement va ensuite combiner les équipes de développement logiciel et d’exploitation informatique en groupes DevOps.
Il y a une résistance à la transition vers DevOps parce que les deux groupes ne sont pas habitués à travailler en étroite collaboration, comme l’a montré une enquête de 2018 de la Cloud Native Computing Foundation.
Cependant, beaucoup estiment que la lutte en vaut la peine. Avoir des équipes plus petites qui surveillent un ou plusieurs microservices et développent des correctifs permet d’avoir une approche plus efficace de la maintenance des applications cloud-natives.
Applications et services cloud-natifs
Il y a une petite différence entre les applications régulières et les services. Les applications sont en effet des programmes auxquels les humains ont accès.
Les services sont par contre des programmes auxquels les humains ne peuvent pas accéder, fonctionnant dans le backend pour assurer le bon fonctionnement des choses.
Lorsqu’il s’agit des applications cloud-natives, les développeurs sont préoccupés par l’effet de l’expérience utilisateur sur les besoins de l’utilisateur. Ceci étant, les services cloud-natifs doivent être en mesure de servir une gamme d’applications.
Les applications cloud-natives doivent être portables, c’est là que les conteneurs entrent en jeu. Elles ne dépendent d’aucune API de cloud spécifique.
D’un autre côté, les services cloud-natifs peuvent dépendre de la plateforme cloud, car c’est la manière pour laquelle les applications accèdent à ce que la plateforme cloud a à offrir.
L’approche cloud-native pour la création d’applications et de services semble aller dans la bonne direction. Les entreprises tentent de déplacer leurs applications traditionnelles vers le cloud, tandis que les startups adoptent d’emblée des approches cloud-natives et DevOps.
Les caractéristiques adaptables inhérentes à l’approche cloud-native la rendent attrayante pour les entreprises nouvelles et anciennes. L’approche cloud-native a changé la façon dont les applications et les services sont créés (architecture de microservices, infrastructure basée sur des conteneurs), mais cela évolue.
Le plus grand changement concerne en effet le processus de développement qui a affecté de manière spectaculaire l’apparence et le fonctionnement des services informatiques.
10 principaux attributs des applications cloud-natives
Voici les 10 principaux attributs des applications cloud-natives que les développeurs doivent garder à l’esprit lors de la conception d’applications cloud-natives :
1. Packagées sous forme de conteneurs légers
Les applications cloud-natives sont une collection de services indépendants et autonomes. Ils sont packagés sous forme de conteneurs légers.
Contrairement aux machines virtuelles, les conteneurs peuvent être mis à l’échelle rapidement. Étant donné que l’unité de mise à l’échelle passe aux conteneurs, l’utilisation de l’infrastructure est optimisée.
2. Développées avec les meilleurs langages et frameworks
Chaque service d’une application cloud-native est développé en utilisant le langage et le framework les mieux adaptés à la fonctionnalité.
En outre, les applications cloud-natives sont polyglottes. Ainsi, les services utilisent une variété de langages, d’exécutions et de frameworks. A titre d’exemple, les développeurs peuvent créer un service de streaming en temps réel basé sur WebSockets, développé dans Node.js, tout en choisissant Python et Flask pour exposer l’API.
L’approche plus détaillée du développement de microservices leur permet en effet de choisir le meilleur langage et le meilleur framework pour un travail spécifique.
3. Conçues comme des microservices à couplage faible
Les services appartenant à la même application se découvrent au cours de l’exécution de l’application.
Cela dit, ils existent indépendamment des autres services. Lorsque l’infrastructure élastique et les architectures d’application sont correctement intégrées, elles peuvent être mises à l’échelle avec efficacité et hautes performances.
Les services faiblement couplés permettent aux développeurs de traiter chaque service indépendamment de l’autre. Grâce à ce découplage, un développeur peut se concentrer sur les fonctionnalités de base de chaque service pour fournir des fonctionnalités précises.
Cette approche conduit à une gestion efficace du cycle de vie de l’application en général. En effet, chaque service est géré de manière indépendante et avec une propriété claire.
4. Centrées sur les API d’interaction et de collaboration
Les services cloud-natifs utilisent des API légères basées sur des protocoles tels que le transfert d’état représentatif ou « representational state transfer » (REST), l’appel de procédure distante open source de Google (Google’s open source remote procedure call ou gRPC) ou NATS.
Tout d’abord, REST est utilisé comme le plus petit dénominateur commun pour exposer les API via le protocole de transfert hypertexte (HTTP).
Pour les performances, gRPC est en principe utilisé pour la communication interne entre les services. Par contre, NATS possède des fonctionnalités de publier-s’abonner ou « publish-subscribe ». Elles permettent ainsi une communication asynchrone au sein de l’application.
5. Architecturées avec une séparation nette des services sans état et avec état
Les services persistants et durables suivent un modèle différent qui assure une disponibilité et une résilience plus élevées.
Ceci étant, les services sans état existent indépendamment des services avec état. Ils sont tout de même liés sur la façon dont le stockage joue dans l’utilisation des conteneurs.
La persistance est un facteur à considérer de plus en plus que ce soit avec ou sans état des environnements de micro-stockage.
6. Isolées des dépendances du serveur et du système d’exploitation
Les applications cloud-natives n’ont pas de lien au système d’exploitation ou à une machine particulière. Elles fonctionnent à un niveau d’abstraction plus élevé. Seulement, un microservice a besoin de certaines capacités, notamment des disques SSD et des unités de traitement graphique (GPU), qui peuvent être exclusivement offertes par un sous-ensemble de machines.
7. Déployées sur une infrastructure cloud élastique et libre-service
Les applications cloud-natives sont déployées sur une infrastructure virtuelle, partagée et élastique.
Pour s’adapter à la charge variable, elles peuvent ainsi s’aligner sur l’infrastructure sous-jacente pour une mise à l’échelle et une réduction de façon dynamique.
8. Gérées via des processus DevOps agiles
Chaque service d’une application cloud-native passe par un cycle de vie indépendant. Ce dernier est géré via un processus DevOps agile. Plusieurs pipelines d’intégration continue/livraison continue (CI/CD) peuvent en effet travailler en collaboration pour déployer et gérer une application cloud-native.
9. Capacités automatisées
Les applications cloud-natives peuvent être hautement automatisées. Elles jouent bien avec le concept d’infrastructure en tant que code.
En effet, un certain niveau d’automatisation est important pour gérer ces applications volumineuses et complexes.
10. Allocation de ressources définie et basée sur des règles
Enfin, les applications cloud-natives s’alignent sur le modèle de gouvernance défini via un ensemble de règles.
Elles adhèrent aux politiques telles que l’unité centrale de traitement (CPU) et les quotas de stockage, ainsi qu’aux politiques de réseau qui allouent des ressources aux services.
A titre d’exemple, dans un scénario d’entreprise, le service informatique central peut définir des politiques pour allouer des ressources à chaque département.
Les développeurs et les équipes DevOps de chaque département ont ainsi un accès et une propriété complets à leur part des ressources.