Architecture cloud native et d’infrastructure

Bienvenue dans le chapitre 10 : Architecture cloud native et d’infrastructure. Pendant la plus grande partie de l’histoire du logiciel, l’infrastructure venait après l’architecture : une équipe d’exploitation recevait une application terminée et trouvait des serveurs pour la faire tourner. Cette séparation a disparu. Aujourd’hui, le choix entre machines virtuelles, conteneurs, plateformes et fonctions détermine une grande partie du coût. Le nombre de zones de disponibilité et de régions détermine la disponibilité. Et le pipeline de déploiement détermine à quelle vitesse et avec quelle sécurité une équipe peut changer quoi que ce soit.

Ce chapitre s’adresse aux développeurs et aux architectes qui veulent choisir, justifier et exploiter les plateformes dont dépendent leurs systèmes, sans se laisser vendre une pile toute faite. Il s’appuie sur le chapitre 0, qui a présenté les serveurs, les machines virtuelles, les conteneurs, les modèles de services cloud, les régions et les zones de disponibilité, et sur le chapitre 9, qui a expliqué comment faire passer les systèmes à l’échelle, les faire se dégrader gracieusement et les garder observables. Ici, ces idées rencontrent les plateformes sur lesquelles tournent aujourd’hui la plupart des systèmes. Les décisions sur l’endroit et la manière dont un logiciel s’exécute coûtent cher à défaire, elles concernent toutes les équipes, et elles fixent les attributs de qualité que le chapitre 2 vous a demandé de spécifier. Et le chapitre 11 suivra, avec la manière de juger une architecture, infrastructure comprise, et de la faire évoluer sans risque dans le temps.

L’exemple récurrent est la plateforme de livraison de repas utilisée tout au long du cours : applications pour les clients et les restaurants, service des commandes, cartes, paiements, affectation des livreurs, et un coup de feu du soir très marqué. Les quatre premières sections portent sur les fondations. La section dix point un établit qui gère quoi, de l’infrastructure en tant que service, ou IaaS, jusqu’au SaaS, en passant par le PaaS et les fonctions. Dans le modèle de responsabilité partagée, vos données, vos identités et votre configuration restent toujours votre affaire. La section dix point deux explique les images de conteneurs, le plan de contrôle et les nœuds de Kubernetes, et la boucle de réconciliation qui en est le cœur. Elle dit aussi franchement quand Kubernetes est surdimensionné. La section dix point trois passe en revue les douze facteurs de l’application douze facteurs, avec leurs limites actuelles, et montre comment auditer un service existant à leur aune. La section dix point quatre traite de l’infrastructure en tant que code : outils déclaratifs, état et dérive, modules, infrastructure immuable, GitOps, politiques en tant que code et tests.

L’idée la plus importante de ce chapitre est celle d’un état souhaité déclaré, réconcilié en continu par l’automatisation. Ce diagramme de la section dix point deux montre comment Kubernetes s’y prend. Vous déclarez l’état souhaité. Ici, trois répliques de la version deux point quatre du service des commandes. Un contrôleur observe l’état réel du cluster, et ne trouve que deux pods en cours d’exécution. Il compare ce qu’il voit avec ce qui a été déclaré, et constate qu’il manque un pod. Il agit donc, et demande un nouveau pod. La boucle se répète à chaque événement de changement, et périodiquement. Comme il agit sur la différence actuelle, et non sur une suite d’événements mémorisée, les événements manqués et les redémarrages ne causent aucun dommage durable. La même idée se retrouve dans le code d’infrastructure, GitOps, les pipelines de déploiement et l’infrastructure immuable. Une personne modifie une description, qui est revue, versionnée et auditable, et les machines font le reste.

Les quatre sections suivantes portent sur le changement, l’échelle, les personnes et l’argent. La section dix point cinq suit un changement du commit jusqu’à la production à travers un pipeline CI/CD, compare les déploiements progressifs, bleu-vert, canari et fantômes, et sépare le déploiement de la mise en production grâce aux feature flags. La section dix point six compare les stratégies de reprise après sinistre, explique ce que la réplication des données entre régions fait à la cohérence, et traite de l’architecture cellulaire et des fonctions en périphérie. La section dix point sept traite la plateforme interne de développement comme un produit, avec des golden paths et des garde-fous, et montre comment mesurer si elle aide. Et la section dix point huit fait du coût une qualité architecturale, mesurée par commande, et traite la dépendance au fournisseur comme un compromis à chiffrer plutôt que comme un péché à éviter.

La seconde idée est que chaque option de ce chapitre est un compromis. Ce diagramme de la section dix point six montre côte à côte quatre stratégies de reprise après sinistre. Chacune se juge à deux chiffres fixés par le métier : l’objectif de temps de reprise, ou RTO, c’est-à-dire combien de temps vous pouvez être indisponible, et l’objectif de point de reprise, ou RPO, c’est-à-dire combien de données vous pouvez perdre. Avec la sauvegarde et restauration, les sauvegardes sont copiées dans une région de reprise où rien ne tourne. La reprise prend des heures, et vous perdez tout ce qui a suivi la dernière sauvegarde. Avec le pilot light, ou veilleuse, les données sont répliquées mais les serveurs d’application sont éteints. Avec le warm standby, ou secours tiède, une petite copie fonctionnelle tourne déjà et monte en charge. Le temps de reprise tombe à quelques dizaines de minutes, puis à quelques minutes. Avec l’actif-actif, une seconde région complète sert déjà du trafic, et les deux chiffres sont proches de zéro. Chaque pas vers la droite achète une reprise plus rapide et moins de pertes de données, au prix d’un coût permanent et d’une complexité plus élevés. Le bon choix dépend de la charge de travail et de l’organisation.

À la fin du chapitre, vous saurez comparer les modèles de services et de déploiement cloud, et répartir les responsabilités d’une charge de travail selon le modèle de responsabilité partagée. Vous comprendrez comment Kubernetes maintient un état souhaité déclaré, et vous saurez juger quand il est surdimensionné. Vous saurez choisir entre déploiements progressifs, bleu-vert, canari et fantômes, et utiliser les feature flags pour séparer le déploiement de la mise en production. Et vous saurez calculer des coûts unitaires, comme le coût par commande, et évaluer la dépendance au fournisseur comme un compromis chiffré.

Chaque section peut se lire seule, mais l’ordre est voulu. On ne peut pas raisonner sur les stratégies de déploiement sans savoir ce que fait Kubernetes pendant un déploiement. Si l’exploitation est nouvelle pour vous, lisez d’abord les encadrés pour débutants, ainsi que la section du chapitre 0 sur les serveurs et le cloud. Ne cherchez pas à mémoriser les noms d’outils. Les produits changent tous les quelques ans, alors que les mécanismes durent. Les fournisseurs sont cités à titre d’exemples, non de recommandations. À la fin de chaque section, vous trouverez des questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses. Comptez environ trois heures pour lire tout le chapitre. Quand vous serez prêt, un test facultatif du chapitre vous attend, d’environ quarante-cinq minutes, avec vingt questions à choix multiples et deux réponses rédigées. La note de réussite est de quatre-vingts pour cent.

Voilà la structure du chapitre. Commencez par la section dix point un, sur les modèles de services et de déploiement cloud, et sur qui est responsable de quoi. À très vite.