Retour d’expérience d'architecture Cloud-ready

Depuis une dizaine d’années, je forme des architectes Cloud chez CentraleSupélec Executive Education. La plateforme de la Fresque du Climat a été pour moi l’occasion de mettre en pratique certains patterns d’architecture Cloud-ready que j’enseigne. J’ai déjà fait un retour d’expérience sur les architectures multi-tenant dans cet article, voici mon retour sur les architectures Cloud-ready.

Cloud-ready kesako ?

Une architecture Cloud-ready est conçue pour proposer une application qui a les mêmes caractéristiques qu’un outil SaaS (cf. Office 365, Salesforce, …), à savoir :

une application accessible “Anywhere Anytime”, c’est-à-dire compatible avec tous les contextes d’usage (bureau, domicile, transports, …) et tous les types d’écrans (ordinateur, tablette, smartphone, …)
une application scalable, capable de gérer 100 comme 10 millions d’utilisateurs en ajoutant des ressources, mais sans refonte de l’architecture.
une application (presque) toujours disponible : la SLA (Service-Level Agreement) standard dans le Cloud est 99,9%, soit moins de 8 heures d’indisponibilité par an
une application résiliente, capable d’offrir une haute durabilité aux données, c’est à dire une haute garantie sur leur intégrité (par exemple, AWS S3 offre une durabilité de de 99,999999999 %)

Anywhere Anytime

Plusieurs approches permettent en 2024 d’offrir une application multi-écran :

des applications natives, avec un code pour chaque système (développement Swift pour iOS, Kotlin pour Android, C# pour Windows..)
des applications hybrides permettant d’utiliser un code unique pour plusieurs applications natives (React Native, Flutter)
une progressive web app (PWA), une application Web qui “simule” une application native
une application web responsive, qui s’adapte à la taille de l’écran

A la Fresque du Climat, nous avons fait le choix du PWA pour 3 raisons :

nous n’avons pas assez de développeurs pour gérer plusieurs bases de code
les applications hybrides étaient immatures au démarrage de nos développements en 2021
par soucis de simplicité et de rapidité de développement, nous avons fait le choix du server side rendering, et non d’une architecture headless

Par ailleurs, notre plateforme est :

“international by design” c’est-à-dire qu’elle est multilingue (grâce à une solution d’internationalisation open source), multipays, multidevise.
accessible

Architecture logicielle scalable

Les containers sont une solution de référence pour créer une architecture élastique, capable de gérer 100 comme 10 millions d’utilisateurs. En effet, la combinaison container/ orchestrateur offre les possibilités suivantes :

ajuster les ressources sans changer l’architecture, car ils font de la distribution des traitements et de la scalabilité “by design”. En effet, si l’on a la responsabilité de la conception d’une architecture à base de machines virtuelles, les containers donnent un cadre qui force à distribuer les middlewares (serveur d’application, base de données,…) dans des clusters scalables.
ajuster les ressources de manière automatique. Grâce à l’auto-scaling, il est possible d’ajouter/supprimer des containers de manière automatique selon la charge utilsateur
déléguer la gestion de certains incidents de production, grâce au concept de self-healing (auto-réparation). Les orchestrateurs (comme Kubernetes) permettent de recréer un container de manière automatique en cas de crash

NB : il est possible d’utiliser des containers sans faire de micro-services : commencer par un “monolithe” applicatif, que l’on découpera plus tard, quand le besoin s’en fera sentir.

Le pattern asynchrone permet de faciliter la scalabilité d’une architecture en cas de forte charge utilisateur. On distingue 2 types de traitements :

les traitements synchrones, appelés “web roles” en architecture Cloud : ils gèrent le parcours utilisateur en continu, en assurant des temps de réponse acceptables
les traitements asynchrones, appelés “worker roles” en architecture Cloud : ils font des opérations en tâche de fond (génération de PDF, envoi d’email, calcul de score,…) qui ne nécessitent pas d’interactivité avec l’utilisateur. Ils sont effectués en “best effort” quand des ressources deviennent disponibles. Ils reposent sur une file d’attente.

Il existe diverses solutions pour gérer des files d’attentes :

un stockage dans des bases de données NoSQL, rapides en lecture/écriture (comme Redis)
l’utilisation de middlewares orientés messages (MOM) basiques comme AWS SQS, GCP Pub/Sub
l’utilisation de bus applicatifs plus sophistiqués (capables de faire des traitements de données, des processus de routage,..). On peut donner l’exemple de solutions open source déployables on premises comme ActiveMQ et RabbitMQ, ou de solutions Cloud comme Zapier ou Salesforce MuleSoft.

Les plateformes PaaS, comme Salesforce Heroku, GCP App Engine , Azure App Service, … reposent sur les concepts précédents. Elles déploient des containers lorsque les développeurs poussent leur code, en leur permettant de faire abstraction de la gestion de ces containers.

A la Fresque du Climat, nous avons fait le choix d’utiliser 2 clusters de containers pour les web et workers. Et notre file d’attente repose sur une base de données NoSQL.

Disponibilité et durabilité

Pour assurer disponibilité et durabilité en architecture Cloud-Ready, il faut distribuer et redonder tous les composants :

traitements (containers, machines virtuelles, fonctions Serverless, …)
stockage (fichiers, base de données SQL ou NoSQL, …)

Et répartir la charge entre ces composants via des load balancers (comme AWS ELB ou GCP CLB)

Ce pattern d’architecture totalement redondant est appelé “design for failure”, c’est-à-dire qu’il est résilient à la perte de n’importe quel composant.

Les grandes plateformes Cloud (AWS, GCP, Azure) fournissent ces services “by design” c’est-à-dire que l’architecture distribuée est proposée par défaut. Sa mise en œuvre est simple : les 3 plateformes proposent pour cela une topologie de régions divisées en 3 à 5 datacenters, appelés zones de disponibilité (exemple AWS).

Par contre, la redondance de tous les composants a un coût certain.

A la Fresque du Climat, nous avons fait le choix d’une architecture redondée chez un fournisseur cloud, mais en sacrifiant la redondance de certains composants réseaux, pour des raisons de coûts.

Infrastructure “managée”

Pour maximiser la sécurité, je recommande d’utiliser une infrastructure la plus “managée” possible. J’entends par “managé” le fait de déléguer le plus d’opérations possibles à un fournisseur cloud : mise à jour de sécurité, mises à jour logicielles, sauvegardes, etc.

Aussi pour héberger une application Cloud-ready, je recommande par ordre de priorité, sous contrainte de coûts et de réversibilité :

une API ou une application SaaS (exemple : wordpress.com plutôt que le logiciel wordpress hébergé sur IaaS)
une plateforme PaaS (voir plus haut), pour héberger du code sans gérer les tâches de production
une plateforme Containers as-a-Service (CaaS comme AWS EKS, AWS ECS, GCP GKE,..) pour héberger du code lorsqu’on a des besoins plus spécifiques (voir l’exemple de la Fresque).
une plateforme IaaS (comme AWS EC2 ou GCP Compute Engine) en dernier recours

Dans cette logique, nous avons fait le choix d’une DBaaS (base de données managée) à la Fresque du Climat, plutôt que de déployer nos bases dans des containers. Nous aurions aimé héberger nos développements sur une PaaS comme Heroku (très rapide à prendre en main) ou CleverCloud, Scalingo (acteurs français du PaaS). Mais les exigences de sécurité, décrites dans ce précédent article, nous ont amené à faire le choix d’une plateforme CaaS. Cette plateforme a nécessité quelques semaines de paramétrage via une solution d’Infrastructure as code. Elle fonctionne aujourd’hui en déploiement continu.