Modèles de services et de déploiement cloud

D’une définition à de nombreux modèles

Le chapitre 0 a présenté les serveurs et le cloud : la définition du NIST (Special Publication 800-145, 2011), avec ses cinq caractéristiques essentielles (libre-service à la demande, large accès réseau, mutualisation des ressources, élasticité rapide et service mesuré), et l’idée que les modèles de services confient une part plus ou moins grande de la pile à un fournisseur. Cette section approfondit ces idées autant qu’un architecte en a besoin pour choisir où un système s’exécute et pour défendre ce choix.

Le NIST définit trois modèles de services (infrastructure, plateforme et logiciel en tant que service) et quatre modèles de déploiement : public (ouvert à tous, détenu par un fournisseur), privé (réservé à une seule organisation, quel que soit son emplacement et quel que soit son exploitant), communautaire (partagé par des organisations ayant des préoccupations communes, comme des organismes publics) et hybride (deux ou plusieurs de ces modèles, reliés de sorte que les données et les applications puissent passer de l’un à l’autre). Le secteur a depuis ajouté les fonctions et les conteneurs en tant que service aux modèles de services, et le multicloud au vocabulaire du déploiement.

L’endroit où s’exécute un logiciel fait partie de ce que le chapitre 1 appelait la structure d’allocation d’une architecture (définir l’architecture) : la correspondance entre le logiciel et le matériel, les réseaux et les organisations. Il est significatif au sens du chapitre 1 parce qu’il coûte cher à défaire, et parce qu’il fixe une grande partie du coût d’un système, sa disponibilité, sa frontière de sécurité et la vitesse à laquelle ses équipes peuvent livrer.

Modèles de services : qui gère quoi

Les modèles de services forment un continuum. À une extrémité, vous louez de la capacité brute et faites vous-même tout ce qui se trouve au-dessus ; à l’autre, vous louez une application finie et vous vous contentez de la configurer. Chaque pas vers la droite retire du travail d’exploitation et retire des choix. Le tableau ajoute les deux modèles postérieurs au document du NIST : les conteneurs en tant que service et les fonctions en tant que service.

En pratique, les frontières s’estompent. Les plateformes de conteneurs serverless comme Google Cloud Run et Azure Container Apps exécutent une image de conteneur comme un PaaS exécute du code, en descendant à zéro comme une fonction. Un Kubernetes managé peut aller d’un plan de contrôle hébergé, où vous continuez à appliquer les correctifs et les mises à niveau aux machines de travail, jusqu’à un mode entièrement managé où le fournisseur exploite aussi les nœuds. La question utile n’est jamais de savoir quelle étiquette s’applique, mais quelles tâches concrètes restent les vôtres : correctifs, décisions de mise à l’échelle, planification de la capacité, sauvegardes, basculement, mises à niveau et astreinte.

Une seconde distinction utile est l’unité de déploiement et de facturation. L’IaaS facture les machines à la seconde ou à l’heure, qu’elles soient occupées ou non ; le FaaS facture les invocations et le temps d’exécution et ne coûte rien au repos ; le PaaS et les conteneurs serverless se situent entre les deux. Le chapitre 6 explique pourquoi la tarification à la requête est moins chère qu’une capacité toujours active en dessous d’un volume de bascule, et plus chère au-dessus (architectures serverless). C’est la forme de la charge, et non sa taille, qui décide de quel côté du point de bascule elle se trouve.

Le modèle de responsabilité partagée

Chaque grand fournisseur publie un modèle de responsabilité partagée. AWS le résume ainsi : le fournisseur est responsable de la sécurité du cloud, et le client de la sécurité dans le cloud. Le fournisseur sécurise les bâtiments, le matériel, le réseau, l’hyperviseur et les services qu’il exploite ; le client sécurise ce qu’il construit et configure par-dessus. L’emplacement de la frontière dépend du modèle de services, comme le montre le diagramme.

Trois choses ne se transfèrent jamais. Le client détient toujours ses données (ce qui est stocké, où, pendant combien de temps, qui peut le lire), ses identités et ses autorisations, et la configuration des services qu’il utilise. De nombreuses violations dans le cloud ont résulté d’erreurs de configuration du client plutôt que de défaillances du fournisseur : stockage objet laissé lisible par tous, clés d’administrateur commitées dans des dépôts publics, autorisations trop larges. En 2019, par exemple, un attaquant a exploité un pare-feu applicatif web mal configuré chez Capital One pour obtenir des identifiants cloud et copier des données concernant plus de 100 millions de personnes aux États-Unis et au Canada ; l’infrastructure du fournisseur s’est comportée comme prévu.

Pour un architecte, le modèle est une liste de contrôle des tâches à attribuer à quelqu’un. Si une équipe déplace la base de données des commandes de la plateforme de livraison de repas d’une machine virtuelle vers un service de base de données managé, l’application des correctifs au moteur de base de données passe au fournisseur, mais pas le choix d’une fenêtre de maintenance, le test des mises à niveau de version majeure, l’octroi d’accès selon le moindre privilège, l’activation du chiffrement ni la vérification que les sauvegardes peuvent être restaurées. Le chapitre 8 traite en profondeur des principes de sécurité qui sous-tendent ces responsabilités (principes de sécurité pour les architectes).

Les modèles de déploiement et leurs vraies raisons

Les organisations choisissent rarement un modèle de déploiement pour une seule raison, et la raison affichée n’est pas toujours la vraie. Il est utile de distinguer les motivations qui résistent à l’examen de celles qui n’y résistent pas.

L’erreur courante consiste à adopter le multicloud comme une couverture abstraite. Faire tourner une charge de travail à l’identique chez deux fournisseurs implique de n’utiliser que les services que proposent les deux, de construire et tester deux jeux de code d’infrastructure, d’entretenir les compétences pour les deux, et souvent de payer des frais de transfert de données entre eux. C’est le piège du plus petit dénominateur commun : vous payez chaque jour le coût de la portabilité en échange d’une sortie dont vous ne vous servirez peut-être jamais. La section 10.8 traite la dépendance au fournisseur comme un compromis à chiffrer, et non comme un péché à éviter à tout prix (FinOps, architecture des coûts et dépendance au fournisseur).

Les régions et les zones de disponibilité comme données de conception

Une région est une zone géographique dotée de son propre ensemble indépendant de centres de données ; une zone de disponibilité est un ou plusieurs centres de données d’une région, avec une alimentation électrique, un refroidissement et un réseau distincts, suffisamment éloignés des autres pour qu’un incendie, une inondation ou une panne de courant locale n’en touche qu’un seul, et suffisamment proches pour des allers-retours de quelques millisecondes au plus. Le chapitre 0 a expliqué l’idée. Pour la conception, trois points supplémentaires comptent.

Premièrement, chaque service managé a un périmètre de défaillance : les ressources zonales (une machine virtuelle isolée, un disque) disparaissent avec leur zone ; les services régionaux (la plupart des bases de données managées en mode multizone, le stockage objet, les files d’attente) sont répliqués entre zones par le fournisseur ; quelques services mondiaux (DNS, identité, certains services de diffusion de contenu et d’équilibrage de charge) couvrent plusieurs régions, ce qui rend leurs rares pannes très étendues. Connaître le périmètre de chaque dépendance est la première étape de toute analyse de disponibilité (voir disponibilité et fiabilité).

Deuxièmement, la répartition entre zones est le choix par défaut, peu coûteux et très rentable. Faire tourner les services sans état de la plateforme de livraison de repas dans trois zones derrière un équilibreur de charge, avec une base de données qui garde une instance de secours synchrone dans une deuxième zone, permet de survivre à la perte d’un centre de données avec un basculement automatique et un léger coût en latence. Trois zones plutôt que deux comptent pour tout ce qui utilise des quorums, comme etcd dans Kubernetes ou une base de données fondée sur un consensus, car une majorité doit survivre. Le trafic entre zones n’est pas toujours gratuit pour autant : la plupart des grands fournisseurs facturent les données qui circulent entre zones, si bien que des services bavards répartis entre zones ajoutent une ligne visible à la facture.

Troisièmement, les régions ne sont pas identiques. Les régions plus récentes ou plus petites peuvent manquer de certains services, certaines ont moins de zones, les prix varient d’une région à l’autre, et la juridiction applicable suit la région. La section 10.6 traite des régions multiples, de la reprise après sinistre et de la résidence des données (multirégion, reprise après sinistre et edge computing).

Services managés ou autogérés

Un service managé est un composant (base de données, file d’attente, cache, moteur de recherche, plan de contrôle Kubernetes) que le fournisseur installe, exploite, corrige, sauvegarde et met à l’échelle pour vous. L’alternative consiste à exploiter vous-même le même logiciel open source sur des machines virtuelles ou dans des conteneurs. Le compromis oppose la charge de travail et le risque d’un côté, au contrôle, au coût et à la portabilité de l’autre.

Les services managés l’emportent quand le composant n’est pas différenciant : toute entreprise de livraison de repas a besoin d’une base de données PostgreSQL fiable, mais aucune ne gagne de clients grâce à sa façon d’appliquer les correctifs à sa base de données. En termes de conception pilotée par le domaine, ce sont des sous-domaines génériques, ceux qu’il vaut mieux acheter que construire. Une base de données managée offre un basculement multizone, une restauration à un instant donné et l’application des correctifs de versions mineures, qui exigeraient sinon une équipe compétente d’astreinte. L’autogestion l’emporte quand vous avez besoin d’une version, d’une extension ou d’un paramètre de réglage que le fournisseur ne propose pas, quand les limites ou quotas du fournisseur ne conviennent pas, quand le surcoût du service managé devient important à grande échelle, ou quand la portabilité entre environnements compte plus que la commodité.

Managé ne veut pas dire sans maintenance. Le fournisseur imposera des mises à niveau de version majeure selon son propre calendrier quand les anciennes versions arriveront en fin de support, modifiera des valeurs par défaut, imposera des quotas que vous découvrirez au pire moment et subira des pannes que vous ne pourrez pas réparer, seulement attendre qu’elles passent. Vous restez responsable de la conception du schéma, des performances des requêtes, des choix de capacité, du coût et du test régulier qui prouve qu’une restauration fonctionne. Traitez chaque service managé comme une dépendance qui a ses propres modes de défaillance et son propre coût de sortie.

Ce que signifie cloud native

La Cloud Native Computing Foundation (CNCF), qui fait partie de la Linux Foundation et héberge Kubernetes, publie la définition la plus citée du cloud native. La version 1.0 (2018) décrivait des technologies permettant aux organisations de construire et d’exploiter des applications scalables dans des environnements dynamiques comme les clouds publics, privés et hybrides, et citait comme exemples typiques les conteneurs, les service meshes, les microservices, l’infrastructure immuable et les API déclaratives. La version 1.1, approuvée en 2024, déplace l’accent des technologies vers les pratiques : développer, construire et déployer des charges de travail de façon programmatique et reproductible à grande échelle, ce qui se caractérise par des systèmes faiblement couplés qui interopèrent de manière sécurisée, résiliente, gérable, durable et observable.

Deux conséquences en découlent. Le cloud native décrit comment un système est construit et exploité, et non où : un cluster Kubernetes dans un centre de données privé, provisionné à partir de code et déployé de nombreuses fois par jour, est cloud native ; une machine virtuelle configurée à la main et copiée telle quelle dans un cloud public ne l’est pas. Et le cloud native est un moyen plutôt qu’une fin. Ses pratiques (automatisation, composants jetables, configuration déclarative, élasticité, observabilité) sont rentables quand un système a besoin de changements fréquents, d’une échelle variable et d’une haute disponibilité ; elles ajoutent du coût et de la complexité pour un outil interne stable utilisé par vingt personnes.

Les migrations sont souvent décrites à l’aide des « six R », qu’il vaut la peine de connaître parce qu’ils fixent les attentes : rehost (« lift and shift », sans changement), replatform (petits changements comme le passage à une base de données managée), refactor ou réarchitecture (refonte pour un fonctionnement cloud native), repurchase (remplacement par un SaaS), retain (laisser en place) et retire (arrêter le système). Le rehosting est rapide, mais il apporte généralement peu des avantages du cloud et, exécuté sur des machines toujours actives dimensionnées pour le pic, peut coûter plus cher que le centre de données qu’il a quitté.

Quand le cloud n’est pas moins cher

Le contre-exemple le plus connu est 37signals, l’entreprise derrière Basecamp et HEY. En octobre 2022, son directeur technique, David Heinemeier Hansson, a annoncé qu’elle quittait le cloud, en citant une facture AWS annuelle de plus de 3 millions USD pour des charges de travail à la charge régulière et prévisible. Elle a acheté pour environ 700 000 USD de serveurs Dell, les a installés dans un espace de colocation loué et a retiré ses applications du calcul AWS au cours de 2023 ; elle a indiqué que cela réduisait sa facture cloud d’environ 2 millions USD par an. En 2025, elle a annoncé la seconde étape : déplacer environ 18 pétaoctets de fichiers d’Amazon S3 vers des baies de stockage d’environ 1,5 million USD, pour remplacer une facture S3 d’environ 1,5 million USD par an, avec l’objectif déclaré de fermer son compte AWS. L’entreprise a projeté des économies d’environ 10 millions USD sur cinq ans. Sortir ainsi des charges de travail du cloud s’appelle le rapatriement depuis le cloud (cloud repatriation).

Les deux camps méritent d’être entendus. En faveur du raisonnement de 37signals : sa charge est régulière, elle gagnait donc peu à l’élasticité ; elle employait déjà des ingénieurs d’exploitation expérimentés et a indiqué n’avoir eu besoin d’aucun personnel supplémentaire ; les fournisseurs de colocation s’occupent de l’alimentation, du refroidissement et de la sécurité physique ; et les serveurs peuvent servir cinq ans ou plus, si bien que leur coût par année de calcul est très inférieur à la location à la demande. De l’autre côté : 37signals est une entreprise mature à la demande prévisible, ce que ne sont pas la plupart des nouveaux produits ; la comparaison dépend fortement de ce qu’aurait été la facture cloud avec des remises d’engagement et un dimensionnement ajusté ; posséder du matériel implique des dépenses d’investissement, des délais de livraison de plusieurs semaines ou mois et une capacité achetée à l’avance ; et une équipe plus petite, sans compétences d’exploitation poussées, devrait les recruter, ce qui peut effacer l’économie. Les critiques soulignent aussi que les chiffres d’économies proviennent de l’entreprise elle-même.