• Architecture 3-tiers ?
• Quand on touche le plafond
• Une solution pour les gouverner toutes ?
  • Hébergement Cloud
  • Kubernetes
• Conclusion

Dernièrement, j’ai eu l’occasion de me pencher sur les offres de Kubernetes Managé des différents Cloud Providers (cf. Solution Cloud — Managed Kubernetes). En introduction, j’ai expliqué de façon vraiment très succincte comment, d’un petit projet, on peut en arriver à avoir besoin d’une solution aussi complexe qu’un Kubernetes Managé.

Aujourd’hui, je vous proposes de repartir d’une base qui pourrait parler à n’importe quel vibe-coder : le déploiement d’une architecture 3-tiers dans le Cloud …

§Architecture 3-tiers ?

Imaginez, vous avez eu une idée génialissime. Vous avez lancé votre Claude Code, ou Opencode, vous avez papoté avec votre agent favoris, puis transformé votre idée en une application web classique. Chat GPT, Gemini, ou Grok, peu importe vos habitudes, vous a ensuite accompagné dans le déploiement de votre superbe application. Il y a fort à parier qu’il vous a orienté vers une solution d’hébergement style Replit ou Railways, accompagnée d’une base de donnée MongoDB Atlas.

En fait, vous avez typiquement déployé une application sur une architecture 3-tiers : Replit ou Railways gèrent l’hébergement de l’interface web, sans doute développé avec React, ainsi que le backend, très certainement avec Express. Ce sont les deux premiers tiers : l’interface pour l’affichage côté client, et le backend pour le traitement des donnés. Le 3è tiers, c’est tout simplement votre base de donnée MongoDB Atlas.

C’est une architecture très classique, et parfaitement adaptée à la plupart des projets les plus simples (surtout au début).

Une combinaison comme celle-ci (Replit et MongoDB Atlas) a l’avantage d’être gratuite, ce qui est bien pratique, quand on travaille sur un prototype, ou une première version “MVP” (Minimum Viable Product).

Mais dès qu’on veut accueillir un peu plus de monde, donc encaisser un peu plus de charge, et stocker leurs donnés, on atteint vite les limites.

À ce moment là, l’usage classique est d’étudier les offres des différents opérateurs de Cloud et voir laquelle correspond le mieux à nos besoins.

Arrivé à ce point, vous allez commencer à avoir du trafic (en tout cas, je vous le souhaite), et vous devrez adapter votre infrastructure.

§Quand on touche le plafond

Les problèmes que vous verrez apparaître seront pour l’essentiel liés à la performance.

• Lenteur de l’application : vos utilisateurs s’étaient habitués à un résultat immédiat, et avec le temps, ils se retrouvent à attendre 2…3…5 secondes.
• Pertes de donnés : le stockage arrive à saturation, faisant apparaître des goulots d’étranglement dans le traitement et le stockage des donnés, et certains services se dégradent, car l’application n’arrive plus à traiter toutes les requêtes.

Si vous demandez à votre assistant favoris, il va vous recommander des améliorations de votre architecture spécifiquement pour palier à ces problèmes.

• Le cache pour soulager votre base de donné : On propose souvent Redis, bien que d’autres solutions existent et peuvent être plus adaptées à certains cas d’usages. Redis est ce qu’on appelle une base de donnée clé-valeur, avec un système d’expiration configurable. Grâce à cela, il est possible de conserver des données pour un certain temps, que les clients pourront récupérer sans solliciter la base de donnée. De fait, on s’en sert souvent pour des données qui ne bougent pas beaucoup ou qui sont en insertion seule, sans mise à jour à postériori.
• Load Balancer, pour distribuer la charge, et plus encore : L’idée, c’est d’avoir plusieurs exemplaires (qu’on appelle “instances”) du backend de l’application en service (sur des VMs ou des containers, mais on creusera à une autre occasion). Cette brique logicielle (souvent NginX ou HAProxy) servira alors à distribuer les appels des clients sur ces différentes instances, de sorte qu’aucune ne se retrouvent avec l’essentiel de la charge. Dans le Cloud, on peut trouver des offres de Load Balancer qui apportent en bonus ce qu’on appel l’auto scaling : Lorsque les instances commencent à saturer, le Load Balancer sera capable de déclencher automatiquement la création de nouvelles instances, ou au contraire, de supprimer celles qui ne servent plus … Pratique, pour maîtriser ses coûts.
• Servir du contenu statique : Il existe également des solutions qui permettent de faciliter la gestion du image, gros fichiers, etc. Souvent basés sur du stockage objet (où la notion d’objet correspond justement à des fichiers traités comme un objet spécifique), on retrouve des offres comme Cloudflare. L’intérêt est d’avoir un stockage optimisé spécifiquement pour des fichiers volumineux (donc typiquement les images) de sorte à disposer d’un accès rapide.
• Optimiser les requêtes en base de donné : Ce dernier axe d’amélioration touche à des subtilités des base de données elles-mêmes. La plupart des serveurs de base de donnée utilisent un système d’index pour optimiser la récupération d’information. Par défaut, on va indexer sur l’identifiant (par exemple un ID de produit), mais quand on fournit des solutions de recherche, souvent sur le nom, d’autres index peuvent aider à optimiser la récupération des données en base (ce qu’on appelle les “requêtes en base de donnée”). La subtilité avec les index, c’est que si on en met trop ou qu’on choisit mal les colonnes à indexer, on va réduire les performances au lieu de les améliorer (sur des projets complexes, on pourra faire appelle à des experts …).

§Une solution pour les gouverner toutes ?

§Hébergement Cloud

Si vous traitez ces problèmes au cas par cas, il y a de fortes chances que votre assistant IA vous recommande ici un successeur à Replit ou railways, comme une solution d’app runner Google ou AWS : ce sont des solutions “serverless”. Cela signifie que vous pouvez directement connecter votre dépôt git au service, qui gère pour vous l’hébergement et les mises à jours.

L’avantage d’un hébergement dans le Cloud, c’est que les opérateurs proposent également des solutions sur étagère pour le cache, la répartition de charge, la gestion des pics de trafic, les bases de donné, etc.

Dans ce registre, j’aimerais également vous parler de Clever Cloud. C’est une solution française partageant la même philosophie “Git push to deploy” qui rend la transition depuis Replit très fluide.

De plus, Clever Cloud n’est pas dépendant d’un unique fournisseur IaaS, mais adopte une approche multi-cloud pour offrir de la flexibilité et une meilleure sécurité des donnés.

Clever Cloud permet de se connecter avec son adresse e-mail et connecter son projet git en 3 clics. Comme AWS ou GCP, Clever Cloud propose également toutes les solutions sur étagère pour la mise en cache, la répartition de la charge, la gestion des pics de trafic, le stockage objet, etc. qui pourrons être associées à notre projet selon les besoins.

§Kubernetes

Kubernetes (ou K8s) est une solution d’orchestration de containers. Alors, ça fait plein de nouveaux mots en une phrase, mais en gros : les instances de votre service, de la base de donnée, du cache, etc. seront déployés dans des containers. Le container permet d’emballer une application, sa configuration et ses dépendances, de sorte à pouvoir facilement reproduire ce déploiement autant que nécessaire … Exactement ce qu’on veut faire pour “scaler” en fonction de la charge.

L’orchestration de container, c’est précisément la capacité de Kubernetes à opérer les instances de notre application, et les autres services dont on a besoin pour qu’elle fonctionne. En l’occurence, les services en question sont toutes les solutions qu’on a évoqué plus haut pour subvenir aux problèmes de notre application : cache, Load Balancer, gestion du contenu statique, etc.

Dans l’article que j’ai partagé récemment, j’ai parlé de Kubernetes Managé, qui permet de déléguer la gestion de Kubernetes lui-même à l’opérateur de Cloud … L’idée qui ressort au final, c’est qu’au lieu de gérer soi-même l’infrastructure de son service, on s’appuie progressivement sur des outils et solutions qui font le travail pour nous.

§Conclusion

Une solution comme Google Cloud Run ou AWS App Runner sont très pertinentes quand le trafic est haché (e.g. pics d’usage le samedi, personne la nuit, etc.) car les coûts varient en fonction de l’usage (voir gratuits grâce à des free tiers généreux). Leur usage est un peu plus technique, demandant par exemple de savoir utiliser des outils comme Docker.

Clever Cloud en revanche propose un forfait à la seconde : on paie tant que le service tourne, et le coût d’usage s’ajuste en fonction de la charge ; les factures sont donc plus prévisibles. Comme on a pu le voir, leur service est également plus accessible.

Les trois offres partagent néanmoins un avantage commun : tout les services disponibles sur étagère complètent l’hébergement de l’application elle-même. Quelque soit le modèle choisi, il sera toujours plus intéressant d’opter pour une offre où tout est intégré.

Kubernetes intervient clairement quand on arrive sur des architectures plus complexes, mais il permet à ce moment là de traiter de façon élégantes les nouveaux problèmes qui surviennent quand notre produit devient bien plus complexe.

Si tout les sujets abordés (de façon très superficielle) dans cet article vous intéresse, je me ferai un plaisir de les approfondir 🙂 En attendant, cet article peut faire office de point de départ pour des discussions avec votre IA favoris, ou bien de recherches plus poussées 😉