Well Architected Framework : Recommandations pour un déploiement professionnel

• Les piliers du WAF : des fondamentaux universels
  • Excellence opérationnelle
  • Sécurité
  • Fiabilité (ou « Reliability »)
  • Performance et Efficacité
  • Optimisation des coûts
• L’architecture Hub’n’Spoke : Centraliser pour mieux régner
  • Pourquoi se lancer dans une architecture Hub’n’Spoke
  • L’architecture Hub’n’Spoke est la réponse professionnelle pour éviter le chaos
• La gouvernance : l’implication pour l’entreprise
• Quel coût pour cette mise en place ?
• Ressources

Nous y sommes. Après avoir exploré le scripting robuste, la puissance de Git et les fondations du réseau virtuel, notre application n’est plus un simple prototype. Elle vit dans le Cloud, elle supporte de plus en plus de trafic et elle commence peut-être à devenir le cœur d’une véritable activité. Mais une question nous taraude souvent à ce stade : notre infrastructure est-elle réellement solide ? Tiendrait-elle le choc face à une panne majeure d’un centre de données ou à une tentative d’intrusion sophistiquée ? Passer du statut de vibecoder talentueux à celui de professionnel aguerri nécessite d’adopter un cadre de référence.

Le Well Architected Framework (WAF) est une véritable boussole méthodologique que nous retrouvons chez tous les grands fournisseurs Cloud (Azure, AWS, GCP, OVH, etc.) pour garantir la viabilité à long terme de nos systèmes.

Dans cet article, nous allons décortiquer les piliers de ce framework et explorer l’architecture Hub’n’Spoke, indispensable pour maîtriser nos flux dès que notre écosystème s’agrandit.

§Les piliers du WAF : des fondamentaux universels

Le Well Architected Framework s’appuie sur des grilles d’évaluation pour mesurer l’alignement de nos architectures avec les meilleures pratiques du marché. L’objectif est double : identifier les risques critiques avant qu’ils ne deviennent des catastrophes et saisir les opportunités d’optimisation.

Nous ne construisons pas seulement pour que « ça marche », nous construisons pour que cela perdure et évolue sans douleur. Pour guider notre réflexion, le WAF se structure autour de cinq piliers fondamentaux.

§Excellence opérationnelle

Ce premier pilier est central, car il est constitué de toute l’expertise, de toutes les bases de connaissances et de tous les processus permettant de gérer et surveiller les systèmes sur lesquels reposent nos produits.

Sur le plan technique, l’excellence concerne notamment l’automatisation (par exemple via nos pipelines de CI/CD) et la surveillance continue de la plateforme au moyen d’outils de supervision. La rigueur sur ces deux premiers points est fondamentale justement pour garantir la qualité du produit une fois qu’il arrive entre les mains des clients.

Sur le plan organisationnel, ce sont la gestion des changements et l’amélioration continue des processus qui vont contribuer à l’excellence opérationnelle. Ce sont précisément les points que nous traitons avec les méthodes agiles, que nous avons développés au travers de notre précédente série d’articles.

Enfin, tout ceci ne tiendrait pas sur le temps long sans la documentation. Des guides détaillés apportent des exemples d’architecture de référence et des outils aidant à l’application des principes du WAF. Ces ressources incluent des études de cas, des modèles de déploiement et des recommandations spécifiques à différents types de charges de travail (base de données, IA, etc.). La documentation des fournisseurs Cloud regorge de ce genre d’exemples, fournissant un socle sur lequel les entreprises peuvent s’appuyer pour développer leurs bonnes pratiques.

§Sécurité

Ce second pilier est également fondamental. Nous devons protéger les données et les actifs par une approche multicouche. Cela inclut le chiffrement, mais aussi une gestion fine des identités et l’utilisation systématique des Security Groups comme remparts, ou des réseaux virtuels.

La sécurité passe également par le contrôle de l’accès aux données. Intuitivement, nous pensons aux utilisateurs devant accéder à leurs propres données et pas à celles des autres utilisateurs. Cependant, nous devons également penser à sécuriser l’accès à l’infrastructure de notre application. Par exemple, nous pouvons placer ce que nous appelons un bastion, à l’entrée de notre réseau virtuel, agissant comme un sas de sécurité : l’administrateur utilisera une clé qu’il possède sur son ordinateur personnel pour s’y connecter, puis une autre clé qui lui permettra de se connecter du bastion vers tel ou tel autre serveur de l’infrastructure. De la sorte, si l’ordinateur personnel de l’administrateur est compromis, seul l’accès au bastion sera compromis.

Lorsque notre infrastructure se complexifie, nous devons également gérer les accès de plus de personnes, pour répondre à des besoins plus spécifiques. Les rôles vont donc se spécialiser et avec eux les besoins d’accès. Une règle souvent appliquée est une extension d’un principe Linux que nous avions vu par le passé : le principe de moindre privilège (ou « Least Privilege »). Appliquée à une infrastructure plus complexe, elle consiste à nous assurer qu’un responsable donné dispose uniquement des accès dont il a besoin pour son rôle spécifique.

§Fiabilité (ou « Reliability »)

Un système professionnel doit être résilient : il doit être capable de se remettre d’une panne automatiquement. Nous privilégions pour cela des programmes « stateless » pour qu’une instance puisse être remplacée par une autre sans perte de service.

Un programme est stateless quand il ne gère pas directement son état. Et ce n’est pas qu’une simple tautologie : sur le principe, le programme va constamment stocker les informations qu’il reçoit de sorte à pouvoir les récupérer la prochaine fois qu’il reçoit une requête, sans avoir à conserver des données de contexte. Pour cela, il devra s’appuyer sur des informations conservées par le client (par exemple en utilisant une session dans le navigateur, qui est une mémoire locale et persistante) qui seront par la suite essentielles pour pouvoir récupérer et lire les données de l’utilisateur. C’est comme si, au restaurant, nous devions constamment rappeler notre numéro de table au serveur pour qu’il retrouve notre commande.

Nous voyons ainsi qu’un principe permettant de garantir la récupération du serveur permet également de renforcer la sécurité, quand elle est correctement mise en place.

Un autre principe utile à connaître à ce niveau est l’idempotence. Derrière ce terme se cache l’idée que lorsqu’un client envoie une requête, le traitement peut réussir sans que le client le sache. Il sera alors tenté de rejouer sa requête, appliquant une nouvelle fois la modification. Un exemple couramment utilisé pour l’expliquer est celui de l’application bancaire.

Si nous envoyons un ordre de virement vers le compte de l’école des petits ou vers le garage pour la voiture, la requête qui sera exécutée ne va pas dire « retire 1000€ et envoie-les vers le compte XXX. » Si la requête est rejouée par erreur, nous refaisons un virement de 1000€ (le garagiste serait content, mais pas nous). Nous enverrons donc une requête du style « passe le solde du compte de 2500€ à 1500€. » Une solution plus moderne que nous retrouvons par exemple chez Stripe consiste à envoyer une clé unique à chaque requête. De la sorte, le serveur est capable de contrôler si la requête a déjà été reçue ou non, pour éviter de la rejouer par erreur (bien sûr, l’exemple est très simplifié pour l’exercice).

§Performance et Efficacité

Il s’agit d’ajuster les ressources techniques (CPU, RAM, stockage) en fonction de la charge réelle pour ne jamais gaspiller de puissance. Pour cela, la plupart des fournisseurs d’offres Cloud proposent une fonctionnalité appelée « auto-scaling » sur laquelle reposent des offres de plus haut niveau, qu’on appelle le « serverless. »

L’auto-scaling consiste à s’appuyer sur le suivi de l’activité de notre serveur (le nombre de requêtes reçues, le délai de traitement, etc.) pour adapter dynamiquement les ressources à la demande. Si le nombre de requêtes augmente, le fournisseur mettra plus de ressources à disposition, tandis que si la demande diminue, ces ressources seront « décommissionnées » (libérées et retirées, car devenues inutiles).

Quant au serverless, c’est une offre pour laquelle nous n’avons plus à gérer nous-même le serveur, mais seulement notre application. Le concept d’auto-scaling est alors complètement caché derrière une mécanique plus générale, visant à nous laisser nous concentrer sur notre application. Sur des architectures complexes, nécessitant de maîtriser précisément la gestion de la charge de notre infrastructure, c’est une équipe interne à l’entreprise qui va gérer toute la logique derrière la notion de « serverless. »

§Optimisation des coûts

Enfin, un déploiement n’est réussi que s’il est économiquement viable. Nous cherchons à aligner chaque euro dépensé avec un objectif métier concret.

Nous devons ainsi évaluer le gain réel de performance ou de résilience offert par l’ajout d’une ressource supplémentaire (comme une machine virtuelle supplémentaire). Si les premiers serveurs déployés procurent une utilité immense en rendant l’application fonctionnelle, chaque ajout suivant subit la loi des rendements décroissants : une dixième machine virtuelle n’apporte qu’un bénéfice utilisateur marginal, presque invisible, alors que son coût de facturation reste identique.

Optimiser son infrastructure exige donc d’identifier précisément ce point de bascule où le coût marginal (le prix de cette ressource en plus) dépasse son utilité marginale, évitant ainsi le piège financier du surplus d’approvisionnement inutile.

Ces exigences ont atteint un tel niveau qu’un nouveau domaine d’expertise s’est développé : le FinOps. Ce sont des experts disposant d’une vision fine sur la consommation et les coûts liés à l’infrastructure, capables d’agir sur deux tableaux en simultané. D’un côté, ils peuvent remonter à la direction de l’entreprise et aux responsables financiers des métriques donnant de la visibilité sur les besoins en budget à venir. De l’autre côté (technique) ils accompagnent les équipes de développement et celles en charge de l’infrastructure (les opérations) dans l’amélioration de la consommation.

§L’architecture Hub’n’Spoke : Centraliser pour mieux régner

§Pourquoi se lancer dans une architecture Hub’n’Spoke

Lorsque nous commençons à gérer plusieurs produits ou plusieurs environnements, la topologie réseau peut vite devenir un plat de spaghettis illisible.

La gestion des produits, ou d’un portefeuille de produits, est un sujet transverse de l’entreprise, entre la stratégie produit, l’organisation des équipes et les choix de technologie. Il couvre donc de nombreux domaines que nous avons pu explorer au cours de nos précédents articles, mais à plus grande échelle encore.

Nous parlons d’avoir plusieurs environnements, lorsque nous voulons garantir la meilleure qualité possible avant de mettre entre les mains de nos clients une version stable de notre produit. Nous maintiendrons donc plusieurs versions de notre environnement : une version de développement, sur laquelle notre équipe travaille ; une version de test (souvent appelée « staging ») sur laquelle nous validerons que les modifications des développeurs sont prêtes pour aller en production ; et une version de production correspondant à la version de l’application à laquelle les clients peuvent accéder.

Lorsque nous avons plusieurs produits différents, destinés à des usages différents et plusieurs environnements, exposés à des publics différents (internes et externes à l’entreprise), l’architecture Hub’n’Spoke permet de garantir un minimum de lisibilité sur l’ensemble de l’infrastructure.

§L’architecture Hub’n’Spoke est la réponse professionnelle pour éviter le chaos

Cette architecture repose sur un canal central, le Hub (« Moyeu » central) sur lequel sont rassemblés tous les services partagés : les passerelles de sécurité (ou Firewalls), les tunnels VPN pour sécuriser les flux réseau entre les bureaux, etc. Nous y retrouvons également les outils de supervision, permettant de surveiller le trafic et l’état du réseau. Le hub nous permet enfin de définir des règles de sécurité communes à tous les projets de l’entreprise et de contrôler que chaque produit a son propre canal.

Le Hub garantit ainsi que chaque environnement de chaque application puisse avoir son propre Spoke (ou rayon) isolé des autres, dans son propre réseau virtuel et relié au Hub via un « VPC Peering », qui est un service réseau que proposent les fournisseurs Cloud précisément pour appairer deux réseaux virtuels (ou VPC) entre eux.

Nous avions déjà parlé d’architecture Hub’n’Spoke pour l’industrialisation de l’IA. Cette structure nous permet de maîtriser les flux de données de manière granulaire. Par exemple, nous pouvons décider qu’aucune donnée ne sort d’un Spoke sans passer par le Hub, où elle sera inspectée. Ou bien nous pouvons ouvrir un canal spécifique et soigneusement sécurisé entre deux réseaux virtuels, parce qu’ils hébergent deux produits collaborant sur des services aux clients. Dans le cas de l’IA, nous pourrons maîtriser les données qu’échangent les agents IA et ce qui se retrouve chez les prestataires (comme Anthropic, OpenAI, xAI, etc.).

L’architecture Hub’n’Spoke est l’assurance d’avoir une vision globale de nos accès et de nos droits sur l’ensemble de notre parc Cloud.

§La gouvernance : l’implication pour l’entreprise

Les choix d’architecture et les bonnes pratiques entrent dans le cadre plus large de l’entreprise et de ses responsabilités, notamment vis-à-vis de ses clients et de ses actionnaires. La gouvernance concerne tout ce qui permet de traiter les questions de responsabilité, de régulation, de gestion du risque, d’implication des parties prenantes au niveau de l’administration de l’entreprise.

La gouvernance vise à rendre l’entreprise fiable pour les partenaires et suffisamment stable et solide pour anticiper, atténuer et si besoin gérer les défis et incidents auxquels elle pourrait faire face. Le Well Architected Framework devient alors un instrument de cette gouvernance.

Nous aurons l’occasion de revenir en détail sur les enjeux de la gouvernance dans notre prochain article.

§Quel coût pour cette mise en place ?

Adopter les principes du Well Architected Framework, ce n’est pas ajouter de la complexité pour le plaisir technique. C’est une démarche d’amélioration continue qui implique des investissements en temps et en énergie, par la mise en place d’une infrastructure dans le style du Hub’n’Spoke.

Mais cette mise en place a un coût qui doit être pris en compte lorsque nous étudions les bonnes pratiques d’architectures sécurisées. Comme pour tout le reste, nos choix seront pilotés par nos besoins et dans ce cas précis, par l’ampleur des risques que nous devons prendre en compte.

Ceux-ci dépendent de l’exigence de nos clients et utilisateurs, qui elle-même dépendra du type de données que nous serons amenés à manipuler : une application bancaire n’aura pas les mêmes enjeux qu’un jeu vidéo. La première exigera de contrôler les moindres flux de données et la moindre transaction (e.g. pour garantir émetteur et récepteur) via le Hub, tandis que le second exigera simplement de sécuriser les connexions pour éviter que les joueurs perdent leurs sauvegardes et leur progression.

Traiter de la sécurité et de la gouvernance des données et des flux de données est une démarche d’amélioration continue qui nous force à poser les bonnes questions. C’est ce qui transforme une application vibecodée en une solution robuste capable de porter une entreprise.

§Ressources

• Google Cloud Well-Architected Framework
• AWS Well-Architected Framework
• Azure Well-Architected Framework
• Architecture Centre d’OVH
• Les Bonnes pratiques faisant partie des Guides techniques d’Outscale
• Well-Architected Frameworks : la boussole de l’architecture cloud, de Stéphane Robert