Architecture d’entreprise cloud-native : principes et gouvernance
Le cloud-native décrit une manière automatisée et reproductible de construire et de déployer des charges de travail. L’architecture d’entreprise fixe les standards de plateforme et suit ce que chaque application utilise.
Mis à jour le
La définition de la CNCF
La Cloud Native Computing Foundation (CNCF) publie une définition du cloud-native, dans sa version 1.1. Selon elle, ces pratiques servent à développer, construire et déployer des charges de travail dans des clouds publics, privés ou hybrides. Elles répondent aux besoins de l’organisation à grande échelle, de façon programmable et reproductible.
Les systèmes visés sont faiblement couplés et interagissent de manière sûre, résiliente, pilotable, durable et observable. La définition cite, sans liste fermée, les conteneurs, les maillages de services, la multilocation, les microservices, l’infrastructure immuable, le serverless et les API déclaratives. Avec une automatisation solide, ces pratiques permettent des changements importants, fréquents et prévisibles.
Monolithe et services indépendants
Dans une application monolithique, les composants se livrent ensemble. Une modification locale oblige à redéployer l’ensemble, les dépendances entre composants freinent les mises à jour et la montée en charge porte sur toute l’application. Une panne d’un composant peut aussi arrêter le reste.
Le cloud-native découpe le système en services qui se livrent et se dimensionnent séparément. Les équipes intègrent un nouveau service plus vite, mais chaque découpage ajoute des interfaces et des dépendances à gouverner.
Les pratiques à décrire
Une architecture cloud-native combine plusieurs pratiques :
- Microservices : chaque service se développe, se déploie et se dimensionne indépendamment.
- Conteneurs : le même paquet s’exécute de la même façon d’un environnement à l’autre.
- Orchestration : la plateforme automatise le déploiement, la montée en charge, la reprise et l’allocation des ressources. Kubernetes est une plateforme open source de ce type pour les charges de travail conteneurisées.
- DevOps et intégration continue : les livraisons sont plus fréquentes et vérifiées automatiquement, ce qui réduit le risque de chacune.
- Infrastructure as Code : réseaux, machines et services se créent à partir de fichiers versionnés et relus comme du code.
- API d’abord : chaque service publie son contrat d’interface avant son implémentation.
Le rôle de l’architecture d’entreprise
Le cloud-native multiplie les services, les environnements et les fournisseurs. L’architecture d’entreprise fixe les standards cloud et structure les plateformes partagées. Elle gouverne aussi les API, suit la sécurité et la conformité et limite la complexité des microservices.
Sans ce travail, les ressources cloud se multiplient sans responsable ni usage connu : c’est la prolifération du cloud (cloud sprawl).
Gains attendus et contraintes
Un service se dimensionne selon sa propre charge, et une panne peut rester confinée à un service. Les équipes livrent plus souvent et peuvent changer de technologie service par service. Le coût peut suivre l’usage réel, à condition que chaque ressource ait un responsable.
Ces gains ont des contraintes. Chaque service ajoute des interfaces, des identités, des journaux et des coûts à suivre. La sécurité porte sur davantage de points d’accès, et les équipes ont besoin de compétences en plateformes cloud, Kubernetes, DevOps et automatisation.
Une adoption progressive
La transition peut se faire application par application. Elle vise une plateforme commune sur laquelle les équipes livrent vite en respectant les standards de l’entreprise.
- Moderniser les applications existantes dont la cible est décidée.
- Passer ces applications en conteneurs.
- Mettre en place une plateforme Kubernetes partagée.
- Automatiser la livraison avec DevOps et l’intégration continue.
- Définir la gouvernance d’architecture cloud : règles, responsables des environnements et revues.
La plateforme technique dans ArchiLU
Dans ArchiLU, le catalogue des technologies range les briques par type, dont les plateformes de conteneurs, les services d’infrastructure et les environnements d’exécution. Le paysage technologique relie les technologies par trois relations : héberge, dépend de, succède à.
Chaque application montre sa pile technique. À 90 jours d’une fin de support, un case s’ouvre : prolonger, migrer, retirer ou accepter le risque. Dans le périmètre autorisé, le collecteur Discovery observe les machines Linux, les conteneurs Docker et leurs connexions TCP ; ces faits deviennent des propositions à valider.
Les contrats des fournisseurs, cloud compris, s’imputent aux applications qu’ils couvrent, avec leur échéance et leur renouvellement automatique repéré.
Questions fréquentes
- Cloud-native veut-il dire microservices uniquement ?
- Non. La définition de la CNCF cite les microservices parmi d’autres techniques, comme les conteneurs, l’infrastructure immuable, le serverless et les API déclaratives. Le style applicatif se choisit application par application.
- Quelle priorité d’architecture en premier ?
- Un socle de plateforme partagé : identité, réseau, observabilité et standards de déploiement. Les équipes construisent ensuite leurs services sur ce socle.
- Comment contrôler les coûts cloud ?
- Avec des garde-fous FinOps, un étiquetage des charges de travail et une responsabilité de coût par domaine. La FinOps Foundation décrit le FinOps comme un cadre opérationnel et une pratique culturelle qui maximise la valeur métier de la technologie.