Qu’est-ce que le natif Cloud ?
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Arrêtez ce que vous faites et demandez à vos collègues de définir le terme « natif Cloud ». Il y a de grandes chances que vous obteniez plusieurs réponses différentes.
Commençons par une définition simple :
L’architecture et les technologies natives Cloud sont une approche de la conception, de la construction et de l’exploitation des charges de travail intégrées dans le cloud et tirent pleinement parti du modèle de cloud computing.
La Cloud Native Computing Foundation fournit la définition officielle :
Les technologies natives Cloud permettent aux organisations de créer et d’exécuter des applications évolutives dans des environnements modernes et dynamiques tels que des clouds publics, privés et hybrides. Les conteneurs, les maillages de service, les microservices, l’infrastructure immuable et les API déclaratives illustrent cette approche.
Ces techniques permettent d’avoir des systèmes faiblement couplés qui sont résilients, gérables et observables. Combinés à une automatisation robuste, ils permettent aux ingénieurs d’apporter des modifications à impact élevé de manière fréquente et prévisible avec un minimum de peine.
Le natif Cloud concerne la vitesse et l’agilité. Les systèmes métier évoluent, allant de l’activation des capacités métier aux outils de transformation stratégique qui accélèrent la vélocité et le développement de l’entreprise. Il est impératif d’avoir de nouvelles idées sur le marché immédiatement.
En même temps, les systèmes métier sont de plus en plus complexes à mesure que la demande des utilisateurs s’accroît. Ils attendent une réactivité rapide, des fonctionnalités innovantes et aucun temps d’arrêt. Les problèmes de performances, les erreurs récurrentes et l’incapacité à agir rapidement ne sont plus acceptables. Vos utilisateurs se tourneront vers la concurrence. Les systèmes natifs Cloud sont conçus pour englober changements rapides, grande échelle et résilience.
Voici quelques entreprises qui ont implémenté des techniques natives Cloud. Réfléchissez à la vitesse, à l’agilité et à la scalabilité qu’elles ont obtenues.
| Company | Expérience |
|---|---|
| Netflix | Dispose de plus de 600 services en production. Effectue des déploiements 100 fois par jour. |
| Uber | Dispose de plus de 1 000 services en production. Effectue des déploiements plusieurs milliers de fois par semaine. |
| Dispose de plus de 3 000 services en production. Effectue des déploiements 1 000 fois par jour. |
Comme vous pouvez le voir, Netflix, Uber et WeChat exposent des systèmes natifs Cloud qui se composent de nombreux services indépendants. Ce style architectural leur permet de répondre rapidement aux conditions du marché. Elles mettent instantanément à jour de petites zones d’une application complexe en service, sans redéploiement complet. Elles mettent à l’échelle individuellement les services en fonction des besoins.
Les piliers du natif Cloud
La vitesse et l’agilité du natif Cloud dérivent de nombreux facteurs. Avant tout, il y a l’infrastructure cloud. Mais ça n’est pas tout : cinq autres piliers fondamentaux présentés dans la figure 1-3 fournissent également la pierre angulaire des systèmes natifs Cloud.
Figure 1-3. Piliers fondamentaux natifs Cloud
Prenons un certain temps pour mieux comprendre l’importance de chaque pilier.
Cloud
Les systèmes natifs Cloud tirent pleinement parti du modèle de service cloud.
Conçus pour prospérer dans un environnement cloud dynamique et virtualisé, ces systèmes utilisent beaucoup l’infrastructure de calcul Platform as a Service (PaaS) et les services gérés. Ils traitent l’infrastructure sous-jacente comme pouvant être éliminées, approvisionnés en quelques minutes et redimensionnés, mis à l’échelle ou détruits à la demande, via l’automatisation.
Considérez la différence entre la façon dont nous traitons les animaux de compagnie et les marchandises. Dans un centre de données traditionnel, les serveurs sont traités comme des animaux domestiques : ce sont des machines physiques auxquelles on donne un nom significatif et dont on prend soin. Vous effectuez une mise à l’échelle en ajoutant d’autres ressources à la même machine (scale-up). Si le serveur devient défaillant, vous vous en occupez jusqu’à ce qu’il soit rétabli. Si le serveur n’est pas disponible, tout le monde le remarque.
Le modèle de service des marchandises est différent. Vous approvisionnez chaque instance en tant que machine virtuelle ou conteneur. Elles sont identiques et attribuées à un identificateur système tel que Service-01, Service-02, etc. Vous effectuez une mise à l’échelle en créant davantage d’instances (montée en charge). Personne ne remarque lorsqu’une instance devient indisponible.
Le modèle des marchandises englobe les infrastructures immuables. Les serveurs ne sont pas réparés ou modifiés. Si l’un est défaillant ou nécessite une mise à jour, il est détruit et un nouveau est provisionné, le tout étant effectué via l’automatisation.
Les systèmes natifs cloud adoptent le modèle de service des marchandises. Ils continuent à s’exécuter à mesure que l’infrastructure est mise à l’échelle ou hors service, sans tenir compte des machines sur lesquelles elles s’exécutent.
La plateforme cloud Azure prend en charge ce type d’infrastructure hautement élastique avec des fonctionnalités de mise à l’échelle automatique, d’auto-réparation et de supervision.
Conception moderne
Comment concevriez-vous une application native Cloud ? À quoi ressemblait votre architecture ? Quels principes, modèles et bonnes pratiques respecteriez-vous ? Quelles seraient les préoccupations liées à l’infrastructure et aux opérations ?
Application à douze facteurs
Une méthodologie largement acceptée pour la construction d’applications basées sur le cloud est l’application à douze facteurs. Il décrit un ensemble de principes et de pratiques que les développeurs suivent pour construire des applications optimisées pour les environnements cloud modernes. Une attention particulière est accordée à la portabilité entre les environnements et l’automatisation déclarative.
Si elle s’applique à n’importe quelle application web, de nombreux praticiens considèrent la méthodologie douze facteurs comme une base solide pour la création d’applications natives Cloud. Les systèmes basés sur ces principes peuvent déployer et mettre à l’échelle rapidement et ajouter des fonctionnalités pour réagir rapidement aux changements du marché.
Le tableau suivant met en évidence la méthodologie douze facteurs :
| Facteur | Explication |
|---|---|
| 1 – Base de code | Base de code unique pour chaque microservice, stockée dans son propre référentiel. Suivi avec le contrôle de version, elle peut être déployée sur plusieurs environnements (AQ, préproduction, production). |
| 2 – Dépendances | Chaque microservice isole et package ses propres dépendances, en adoptant les modifications sans avoir d’impact sur l’ensemble du système. |
| 3 – Configurations | Les informations de configuration sont déplacées hors du microservice et externalisées par le biais d’un outil de gestion de configuration en dehors du code. Le même déploiement peut se propager entre les environnements avec la configuration appropriée appliquée. |
| 4 – Services de stockage | Les ressources auxiliaires (magasins de données, caches, répartiteurs de messages) doivent être exposées via une URL adressable. Cela dissocie la ressource de l’application, ce qui lui permet d’être interchangeable. |
| 5 – Générer, mettre en production, exécuter | Chaque version doit appliquer une séparation stricte entre les étapes de génération, de mise en œuvre et d’exécution. Chacune doit être marquée avec un ID unique et prendre en charge la possibilité de restaurer. Les systèmes CI/CD modernes aident à respecter ce principe. |
| 6 – Processus | Chaque microservice doit s’exécuter dans son propre processus, isolé des autres services en cours d’exécution. Externalisez l’état requis à un service de stockage tel qu’un cache distribué ou un magasin de données. |
| 7 – Liaison de port | Chaque microservice doit être autonome avec ses interfaces et ses fonctionnalités exposées sur son propre port. Cela permet l’isolement d’autres microservices. |
| 8 – Concurrence | Lorsque la capacité doit augmenter, effectuez un scale-out des services horizontalement sur plusieurs processus identiques (copies) par opposition au scale-up d’une seule grande instance sur l’ordinateur le plus puissant disponible. Développez l’application pour qu’elle effectue un scale-out simultané dans des environnements cloud transparents. |
| 9 – Élimination | Les instances de service doivent pouvoir être éliminées. Privilégiez le démarrage rapide pour augmenter les opportunités d’extensibilité et les arrêts appropriés pour laisser le système dans un état correct. Les conteneurs Docker ainsi qu’un orchestrateur répondent intrinsèquement à cette exigence. |
| 10 – Parité Dév/Prod | Conservez les environnements dans le cycle de vie de l’application aussi similaire que possible, ce qui évite les raccourcis coûteux. Ici, l’adoption des conteneurs peut apporter une contribution considérable en favorisant le même environnement d’exécution. |
| 11 – Journalisation | Traitez les journaux générés par les microservices en tant que flux d’événements. Traitez-les avec un agrégateur d’événements. Propagez les données de journal aux outils de gestion des journaux/d’exploration de données comme Azure Monitor ou Splunk et éventuellement à l’archivage à long terme. |
| 12 – Processus d’administration | Exécutez des tâches d’administration/de gestion, telles que le nettoyage des données ou l’analytique informatique, en tant que processus ponctuels. Utilisez des outils indépendants pour appeler ces tâches à partir de l’environnement de production, mais séparément de l’application. |
Dans le livre, Beyond the Twelve-Factor App, l’auteur Kevin Hoffman détaille chacun des 12 facteurs d’origine (rédigé en 2011). En outre, il aborde trois facteurs supplémentaires qui reflètent la conception moderne de l’application cloud d’aujourd’hui.
| Nouveau facteur | Explication |
|---|---|
| 13 – L’API en premier | Tout doit être un service. Présupposez que votre code sera consommé par un client frontal, une passerelle ou un autre service. |
| 14 – Télémétrie | Sur une station de travail, vous avez une visibilité approfondie sur votre application et son comportement. Dans le cloud, cela n’est pas le cas. Assurez-vous que votre conception inclut la collection de données de surveillance, spécifiques au domaine et d’intégrité/système. |
| 15 – Authentification/Autorisation | Implémentez l’identité dès le début. Envisagez des fonctionnalités RBAC (contrôle d’accès en fonction du rôle) disponibles dans les clouds publics. |
Nous faisons référence à un grand nombre des 12 facteurs de ce chapitre et tout au long du livre.
Azure Well-Architected Framework
La conception et le déploiement de charges de travail basées sur le cloud peuvent être difficiles, en particulier lors de l’implémentation de l’architecture native Cloud. Microsoft fournit des meilleures pratiques standard du secteur d’activité pour vous aider, ainsi que votre équipe, à fournir des solutions cloud robustes.
Microsoft Well-Architected Framework fournit un ensemble de principes directeurs qui peuvent être utilisés pour améliorer la qualité d’une charge de travail native Cloud. L’infrastructure se compose de cinq piliers de l’excellence architecturale :
| Principes | Description |
|---|---|
| Gestion des coûts | Concentrez-vous sur la génération anticipée de la valeur incrémentielle. Appliquez les principes Build-Measure-Learn pour accélérer le délai de commercialisation tout en évitant les solutions gourmandes en capitaux. En recourant à une stratégie de paiement à l’utilisation, investissez à mesure que vous effectuez un scale-out, plutôt que de fournir un investissement important dès le départ. |
| Excellence opérationnelle | Automatisez l’environnement et les opérations pour augmenter la vitesse et réduire le risque d’erreur humaine. Restaurez les mises à jour des problèmes ou restaurez-les par progression rapidement. Implémentez la surveillance et les diagnostics dès le début. |
| Efficacité des performances | Répondez efficacement aux demandes placées sur vos charges de travail. Privilégiez la mise à l’échelle horizontale (scale-out) et concevez-la dans vos systèmes. Effectuez continuellement des tests de performances et de charge pour identifier les goulots d’étranglement potentiels. |
| Fiabilité | Créez des charges de travail résilientes et disponibles. La résilience permet aux charges de travail de récupérer des défaillances et de continuer à fonctionner. La disponibilité garantit aux utilisateurs l’accès à votre charge de travail à tout moment. Concevez des applications de manière à vous attendre à des échecs et à pouvoir ensuite effectuer une récupération. |
| Sécurité | Implémentez la sécurité tout au long du cycle de vie d’une application, de la conception et de l’implémentation au déploiement et aux opérations. Faites attention à la gestion des identités, à l’accès à l’infrastructure, à la sécurité des applications et à la souveraineté et au chiffrement des données. |
Pour commencer, Microsoft fournit un ensemble d’évaluations en ligne pour vous aider à évaluer vos charges de travail cloud actuelles par rapport aux cinq piliers Well-Architected.
Microservices
Les systèmes natifs Cloud adoptent les microservices, un style architectural populaire pour construire des applications modernes.
Construit en tant qu’ensemble distribué de petits services indépendants qui interagissent via une infrastructure partagée, les microservices partagent les caractéristiques suivantes :
Chacun implémente une fonctionnalité métier spécifique dans un contexte de domaine plus grand.
Chacun est développé de manière autonome et peut être déployé indépendamment.
Chacun est autonome encapsulant sa propre technologie de stockage de données, ses dépendances et sa plateforme de programmation.
Chacun s’exécute au sein de son propre processus et communique avec les autres à l’aide de protocoles de communication standard tels que HTTP/HTTPS, gRPC, WebSockets ou AMQP.
Ils composent ensemble pour former une application.
La figure 1-4 met en contraste une approche d’application monolithique et une approche de microservices. Notez comment le monolithe est composé d’une architecture en couches, qui s’exécute dans un seul processus. Il consomme généralement une base de données relationnelle. Toutefois, l’approche de microservice sépare les fonctionnalités en services indépendants, chacun avec sa logique, son état et ses données qui lui sont propres. Chaque microservice héberge son propre magasin de données.
Figure 1-4. Architecture monolithique et de microservices
Notez comment les microservices favorisent le principe Processus de l’application à douze facteurs, décrit précédemment dans le chapitre.
Le facteur nº 6 spécifie que « chaque microservice doit s’exécuter au sein de son propre processus, isolé des autres services en cours d’exécution ».
Intérêt des microservices
Les microservices offrent une agilité.
Précédemment dans le chapitre, nous avons comparé une application d’e-commerce créée en tant que monolithe à celle des microservices. Dans l’exemple, nous avons vu quelques avantages clairs :
Chaque microservice a un cycle de vie autonome et peut évoluer indépendamment et effectuer des déploiements fréquemment. Vous n’avez pas besoin d’attendre une version trimestrielle pour déployer une nouvelle fonctionnalité ou une mise à jour. Vous pouvez mettre à jour une petite zone d’une application en service avec moins de risque de perturber l’ensemble du système. La mise à jour peut être effectuée sans redéploiement complet de l’application.
Chaque microservice peut être mis à l’échelle indépendamment. Au lieu de mettre à l’échelle l’ensemble de l’application en tant qu’unité unique, vous effectuez un scale-out uniquement de ces services qui nécessitent plus de puissance de traitement pour répondre aux niveaux de performances souhaités et aux contrats de niveau de service. La mise à l’échelle affinée offre un meilleur contrôle de votre système et permet de réduire les coûts globaux à mesure que vous mettez à l’échelle des parties de votre système, et non le tout.
Un excellent guide de référence pour comprendre les microservices est Microservices .NET : Architecture pour les applications .NET conteneurisées. Le livre aborde en détail la conception et l’architecture des microservices. C’est un vrai compagnon pour une architecture de référence de microservices à pile complète disponible gratuitement auprès de Microsoft.
Développement de microservices
Les microservices peuvent être créés sur n’importe quelle plateforme de développement moderne.
La plateforme Microsoft .NET est un excellent choix. Gratuite et en open source, elle comporte de nombreuses fonctionnalités intégrées qui simplifient le développement de microservices. .NET est multiplateforme. Les applications peuvent être créées et exécutées sur Windows, macOS et la plupart des versions de Linux.
.NET est très performante et a obtenu de bonnes évaluations par rapport à Node.js et à d’autres plateformes concurrentes. Il est intéressant de noter que TechEmpower a mené une évaluation d’un ensemble complet de points de référence de performance sur de nombreuses plateformes et frameworks d’applications web. .NET se place dans les 10 premières, bien au-dessus de Node.js et d’autres plateformes concurrentes.
.NET est géré par Microsoft et la communauté .NET sur GitHub.
Défis liés aux microservices
Bien que les microservices natifs Cloud distribués puissent fournir une agilité et une vitesse très élevées, ils présentent de nombreux défis :
Communication
Comment les applications clientes front-end communiquent-elles avec les microservices principaux back-end ? Allez-vous autoriser la communication directe ? Ou bien, allez-vous faire abstraction des microservices back-end avec une façade de passerelle qui offre une flexibilité, un contrôle et une sécurité ?
Comment les microservices principaux back-end communiqueront-ils entre eux ? Autoriserez-vous des appels HTTP directs qui peuvent augmenter le couplage et impacter les performances et l’agilité ? Ou pouvez-vous envisager de dissocier la messagerie avec des technologies de file d’attente et de rubrique ?
La communication est abordée dans le chapitre Modèles de communication natifs Cloud.
Résilience
Une architecture de microservices déplace votre système de la communication réseau au sein du processus vers une hors processus. Dans une architecture distribuée, que se passe-t-il quand le service B ne répond pas à un appel réseau du service A ? Ou, que se passe-t-il lorsque le service C devient temporairement indisponible et que d’autres services qui l’appellent se bloquent ?
La résilience est abordée dans le chapitre Résilience native Cloud.
Données distribuées
Par conception, chaque microservice encapsule ses propres données, exposant les opérations via son interface publique. Si c’est le cas, comment interroger des données ou implémenter une transaction entre plusieurs services ?
Les données distribuées sont couvertes dans le chapitre Modèles de données natifs Cloud.
Secrets
Comment vos microservices stockent-ils et gèrent-ils en toute sécurité les secrets et les données de configuration sensibles ?
Les secrets sont abordés en détail dans Sécurité native Cloud.
Gérer la complexité avec Dapr
Dapr est un runtime d’application open source distribué. Grâce à une architecture de composants enfichables, il simplifie considérablement le raccordement derrière les applications distribuées. Il fournit une colle dynamique qui lie votre application à des fonctionnalités et composants d’infrastructure prédéfinis du runtime Dapr. La figure 1-5 montre Dapr vu de très haut.
Figure 1-5. Dapr vu de très haut.
Dans la ligne supérieure de la figure, notez comment Dapr fournit des SDK spécifiques au langage aux plateformes de développement populaires. Dapr v1 inclut la prise en charge de .NET, Go, Node.js, Python, PHP, Java et JavaScript.
Bien que les kits SDK spécifiques au langage améliorent l’expérience du développeur, Dapr est indépendant de la plateforme. Plus précisément, le modèle de programmation de Dapr expose les fonctionnalités par le biais de protocoles de communication HTTP/gRPC standard. Toute plateforme de programmation peut appeler Dapr via ses API HTTP et gRPC natives.
Les carrés bleus au centre de la figure représentent les blocs de construction Dapr. Chacun expose du code de raccordement prédéfini pour une fonctionnalité d’application distribuée que votre application peut consommer.
La ligne Composants représente un grand ensemble de composants d’infrastructure prédéfinis que votre application peut consommer. Considérez les composants comme du code d’infrastructure que vous n’avez pas besoin d’écrire.
La ligne inférieure met en évidence la portabilité de Dapr et les différents environnements dans lesquels il peut s’exécuter.
En ce qui concerne l’avenir, Dapr a le potentiel d’avoir un impact profond sur le développement d’applications natives Cloud.
Conteneurs
Il est naturel d’entendre le terme conteneur mentionné dans n’importe quelle conversation native Cloud. Dans le livre Cloud Native Patterns, l’autrice Cornelia Davis observe que « les conteneurs sont un excellent moteur du logiciel natif Cloud ». La Cloud Native Computing Foundation place la conteneurisation de microservices comme première étape de leur carte de piste native Cloud, un ensemble de conseils pour les entreprises qui commencent leur parcours natif Cloud.
La conteneurisation d’un microservice est simple et directe. Le code, ses dépendances et son runtime sont packagés dans un binaire appelé image conteneur. Les images sont stockées dans un registre de conteneurs, qui agit comme référentiel ou bibliothèque pour les images. Un registre peut se trouver sur votre ordinateur de développement, dans votre centre de données ou dans un cloud public. Docker gère lui-même un registre public via Docker Hub. Le cloud Azure dispose d’un registre de conteneurs privé pour stocker des images conteneur proches des applications cloud qui les exécuteront.
Quand une application démarre ou se met à l’échelle, vous transformez l’image conteneur en une instance de conteneur en cours d’exécution. L’instance s’exécute sur n’importe quel ordinateur doté d’un moteur runtime de conteneur installé. Vous pouvez avoir autant d’instances du service conteneurisé que nécessaire.
La figure 1-6 montre trois microservices différents, chacun dans son propre conteneur, qui s’exécutent tous sur un seul hôte.
Figure 1-6. plusieurs conteneurs s’exécutant sur un hôte de conteneurs
Notez comment chaque conteneur conserve son propre ensemble de dépendances et de runtime, qui peuvent être différents des uns des autres. Ici, nous voyons différentes versions du microservice Product s’exécutant sur le même hôte. Chaque conteneur partage une tranche du système d’exploitation hôte sous-jacent, de la mémoire et du processeur, mais il est isolé des autres.
Notez comment le modèle conteneur adopte le principe Dépendances de l’application à douze facteurs.
Le facteur nº 2 spécifie que « chaque microservice isole et package ses propres dépendances, adoptant les modifications sans impact sur l’ensemble du système ».
Les conteneurs prennent en charge les charges de travail Linux et Windows. Le cloud Azure s’intègre ouvertement aux deux. Il est intéressant de noter que c’est Linux, et non Windows Server, qui est devenu le système d’exploitation le plus populaire dans Azure.
Bien que plusieurs fournisseurs de conteneurs existent, Docker s’est taillé la part du lion du marché. L’entreprise a emmené le mouvement des conteneurs logiciels. Ils sont devenus la norme de facto pour le packaging, le déploiement et l’exécution d’applications natives Cloud.
Pourquoi des conteneurs ?
Les conteneurs offrent une portabilité et garantissent la cohérence entre les environnements. En encapsulant tout dans un package unique, vous isolez le microservice et ses dépendances de l’infrastructure sous-jacente.
Vous pouvez déployer le conteneur dans n’importe quel environnement qui héberge le moteur d’exécution Docker. Les charges de travail conteneurisées éliminent également les frais de préconfiguration de chaque environnement avec des infrastructures, des bibliothèques de logiciels et des moteurs d’exécution.
En partageant le système d’exploitation sous-jacent et les ressources hôtes, un conteneur a une empreinte beaucoup plus faible qu’une machine virtuelle complète. La taille inférieure augmente la densité, ou le nombre de microservices, qu’un hôte donné peut exécuter à la fois.
Orchestration de conteneurs
Bien que les outils tels que Docker créent des images et exécutent des conteneurs, vous avez également besoin d’outils pour les gérer. La gestion des conteneurs est effectuée avec un programme logiciel spécial appelé orchestrateur de conteneurs. Lors de l’exploitation à grande échelle avec de nombreux conteneurs en cours d’exécution indépendants, l’orchestration est essentielle.
La figure 1-7 montre les tâches de gestion que les orchestrateurs de conteneurs automatisent.
Figure 1-7. Ce que les orchestrateurs de conteneurs font
Le tableau suivant décrit les tâches d’orchestration courantes.
| Tâches | Explication |
|---|---|
| Planification | Provisionnement automatique des instances de conteneur. |
| Affinité/Anti-affinité | Provisionnement des conteneurs à proximité ou éloignés les uns des autres, favorisant la disponibilité et les performances. |
| Surveillance de l’intégrité | Détection et correction automatique des défaillances. |
| Basculement | Réapprovisionnement automatique d’une instance ayant échoué sur un ordinateur sain. |
| Mise à l'échelle | Ajout ou suppression automatique d’une instance de conteneur pour répondre à la demande. |
| Mise en réseau | Gestion d’une superposition réseau pour la communication de conteneur. |
| Découverte de service | Possibilité pour les conteneurs de se localiser les uns les autres. |
| Mises à niveau propagées | Coordination des mises à niveau incrémentielles avec un déploiement sans temps d’arrêt. Restauration automatique des modifications problématiques. |
Notez la façon dont les orchestrateurs de conteneurs adoptent les principes Élimination et Concurrence de l’application à douze facteurs.
Le facteur nº 9 spécifie que « les instances de service doivent pouvoir être éliminées, ce qui aide les start-ups rapides à augmenter les opportunités de scalabilité et les arrêts corrects pour laisser le système dans un bon état ». Les conteneurs Docker avec un orchestrateur répondent intrinsèquement à cette exigence.
Le facteur nº 8 spécifie que « les services sont mis à l’échelle sur un grand nombre de petits processus identiques (copies) par opposition au scale-up d’une seule grande instance sur l’ordinateur le plus puissant disponible ».
Bien que plusieurs orchestrateurs de conteneurs existent, Kubernetes est devenu la norme de facto pour le monde natif Cloud. Il s’agit d’une plateforme portable, extensible et open source pour la gestion des charges de travail conteneurisées.
Vous pouvez héberger votre propre instance de Kubernetes, mais vous êtes alors responsable de l’approvisionnement et de la gestion de ses ressources, ce qui peut être complexe. Le cloud Azure propose Kubernetes en tant que service géré. Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift (ARO) vous permettent tous les deux de tirer pleinement parti des fonctionnalités et de la puissance de la plateforme Kubernetes en tant que service géré, sans avoir à l’installer et à la gérer.
L’orchestration de conteneurs est décrite en détail dans Mise à l’échelle des applications natives Cloud.
Services de stockage
Les systèmes natifs Cloud dépendent de nombreuses ressources auxiliaires différentes, telles que les magasins de données, les répartiteurs de messages, la surveillance et les services d’identité. Ces services sont appelés services de stockage.
La figure 1-8 montre de nombreux services de stockage courants que les systèmes natifs Cloud consomment.
Figure 1-8. Services de stockage courants
Vous pouvez héberger vos propres services de stockage, mais vous êtes alors responsable des licences, de l’approvisionnement et de la gestion de ces ressources.
Les fournisseurs de cloud offrent un vaste éventail de services de stockage gérés. Au lieu de posséder le service, vous l’utilisez tout simplement. Le fournisseur de cloud exploite la ressource à grande échelle et assume la responsabilité des performances, de la sécurité et de la maintenance. La surveillance, la redondance et la disponibilité sont intégrées au service. Les fournisseurs garantissent les performances au niveau du service et prennent entièrement en charge leurs services gérés : ouvrez un ticket et ils résolvent votre problème.
Les systèmes natifs Cloud favorisent les services de stockage gérés des fournisseurs de cloud. Les économies de temps et de travail peuvent être significatives. Le risque opérationnel d’héberger vo propre service et de rencontrer des problèmes peut être rapidement coûteux.
Une meilleure pratique consiste à traiter un service de stockage en tant que ressource attachée, liée dynamiquement à un microservice avec des informations de configuration (une URL et des informations d’identification) stockées dans une configuration externe. Cette aide est expliquée dans l’application à douze facteurs, décrite précédemment dans le chapitre.
Le facteur nº 4 spécifie que les services de stockage « doivent être exposés via une URL adressable. Cela dissocie la ressource de l’application, ce qui lui permet d’être interchangeable ».
Le facteur nº 3 spécifie que « les informations de configuration sont déplacées hors du microservice et externalisées par le biais d’un outil de gestion de la configuration en dehors du code ».
Avec ce modèle, un service de stockage peut être attaché et détaché sans modification du code. Vous pouvez promouvoir un microservice de l’AQ vers un environnement intermédiaire. Vous mettez à jour la configuration du microservice pour pointer vers les services de stockage en phase intermédiaire et injecter les paramètres dans votre conteneur via une variable d’environnement.
Les fournisseurs de cloud fournissent des API qui vous permettent de communiquer avec leurs services de stockage propriétaires. Ces bibliothèques encapsulent le raccordement et la complexité propriétaires. Toutefois, la communication directe avec ces API couplera étroitement votre code à ce service de stockage spécifique. Il s’agit d’une pratique largement acceptée pour isoler les détails de l’implémentation de l’API fournisseur. Introduisez une couche intermédiaire ou une API intermédiaire, exposant des opérations génériques à votre code de service et incluez le code du fournisseur à l’intérieur de celui-ci. Ce couplage libre vous permet d’échanger un service de stockage pour un autre ou de déplacer votre code vers un autre environnement cloud sans avoir à apporter de modifications au code du service principal. Dapr, abordé précédemment, suit ce modèle avec son ensemble de blocs de construction prédéfinis.
Lors d’une dernière réflexion, les services de stockage favorisent également le principe Sans état de l’application à douze facteurs, décrit plus haut dans le chapitre.
Le facteur nº 6 spécifie que « chaque microservice doit s’exécuter au sein de son propre processus, isolé des autres services en cours d’exécution. Externalisez l’état requis à un service de stockage tel qu’un cache distribué ou un magasin de données ».
Les services de stockage sont abordés dans Modèles de données natifs Cloud et Modèles de communication natifs Cloud.
Automatisation
Comme vous l’avez vu, les systèmes natifs Cloud adoptent les microservices, les conteneurs et la conception moderne du système pour accroître la vitesse et l’agilité. Mais ce n’est qu’une partie de l’histoire. Comment provisionner les environnements cloud sur lesquels ces systèmes s’exécutent ? Comment déployer rapidement des fonctionnalités et des mises à jour d’application ? Comment arrondir l’image complète ?
Découvrez la pratique largement acceptée Infrastructure as Code, ou IaC.
Avec IaC, vous automatisez l’approvisionnement de plateforme et le déploiement d’applications. Vous appliquez essentiellement des pratiques d’ingénierie logicielle telles que le test et le contrôle de version à vos pratiques DevOps. Votre infrastructure et vos déploiements sont automatisés, cohérents et reproductibles.
Automatisation de l’infrastructure
Des outils tels que Azure Resource Manager, Azure Bicep, Terraform d’HashiCorp et Azure CLI vous permettent de scripter de manière déclarative l’infrastructure cloud dont vous avez besoin. Les noms de ressources, les emplacements, les capacités et les secrets sont paramétrés et dynamiques. Le version du script est gérée et ce dernier est archivé dans le contrôle de code source en tant qu’artefact de votre projet. Vous appelez le script pour approvisionner une infrastructure cohérente et reproductible dans les environnements système, tels que l’AQ, la préproduction et la production.
Plus en détail, l’IaC est idempotent, ce qui signifie que vous pouvez exécuter le même script encore et encore, sans effets secondaires. Si l’équipe doit apporter une modification, elle modifie et réexécute le script. Seules les ressources mises à jour sont affectées.
Dans l’article , Qu’est-ce que l’infrastructure en tant que code, l’auteur Sam Guckenheimer décrit comment « les équipes qui implémentent IaC peuvent fournir des environnements stables rapidement et à grande échelle. Elles évitent la configuration manuelle des environnements et appliquent la cohérence en représentant l’état souhaité de leurs environnements via du code. Les déploiements d’infrastructure avec IaC sont reproductibles et empêchent les problèmes d’exécution causés par la dérive de configuration ou les dépendances manquantes. Les équipes DevOps peuvent collaborer avec un ensemble unifié de pratiques et d’outils pour fournir rapidement des applications et leur infrastructure de support, de manière fiable et à grande échelle ».
Automatisation des déploiements
L’application de douze facteurs, décrite précédemment, appelle des étapes distinctes lors de la transformation du code terminé en une application en cours d’exécution.
Le facteur nº 5 spécifie que « chaque version doit appliquer une séparation stricte entre les étapes de génération, de mise en œuvre et d’exécution ». Chacune doit être marquée avec un ID unique et prendre en charge la possibilité de restaurer ».
Les systèmes CI/CD modernes aident à respecter ce principe. Ils fournissent des étapes de génération et de livraison distinctes qui permettent de garantir un code cohérent et de qualité facilement disponible pour les utilisateurs.
La figure 1-9 montre la séparation entre le processus de déploiement.
Figure 1-9. Étapes de déploiement dans un pipeline CI/CD
Dans la figure précédente, portez une attention particulière à la séparation des tâches :
- Le développeur construit une fonctionnalité dans son environnement de développement, en effectuant une itération via ce qu’on appelle la « boucle interne » du code, de l’exécution et du débogage.
- Une fois terminé, ce code est envoyé (push) dans un référentiel de code, tel que GitHub, Azure DevOps ou BitBucket.
- L’envoi (push) déclenche une phase de génération qui transforme le code en artefact binaire. Le travail est implémenté avec un pipeline d’intégration continue (CI). Il génère, teste et package automatiquement l’application.
- La phase de mise en production récupère l’artefact binaire, applique les informations de configuration de l’application externe et de l’environnement et produit une version immuable. La version est déployée dans un environnement spécifié. Le travail est implémenté avec un pipeline de livraison continue (CD). Chaque version doit être identifiable. Vous pouvez dire : « Ce déploiement exécute la version 2.1.1 de l’application. »
- Enfin, la fonctionnalité publiée est exécutée dans l’environnement d’exécution cible. Les versions sont immuables, ce qui signifie que toute modification doit créer une nouvelle version.
L’application de ces pratiques, les organisations ont radicalement évolué dans leur façon de fournir des logiciels. Un grand nombre est passé des versions trimestrielles à des mises à jour à la demande. L’objectif est de détecter les problèmes au début du cycle de développement lorsqu’ils sont moins coûteux à résoudre. Plus la durée entre les intégrations est longue, plus il est coûteux de les résoudre. En disposant d’un processus d’intégration cohérent, les équipes peuvent valider les modifications de code plus fréquemment, ce qui entraîne une meilleure collaboration et une meilleure qualité logicielle.
L’infrastructure en tant qu’automatisation du code et du déploiement, ainsi que GitHub et Azure DevOps, sont décrits en détail dans DevOps.
