Scalabilité, microservices et cloud

Objectifs

À la fin de cette leçon, vous saurez :

• distinguer montée verticale et horizontale et leurs contraintes ;
• comprendre ce que les microservices changent réellement ;
• situer Kubernetes et le cloud par rapport à Docker.

🔗 Pour vous rafraîchir la mémoire : JWT et jetons auto-porteurs

Scalabilité : deux directions

VERTICALE : un serveur plus gros        HORIZONTALE : plusieurs serveurs
simple, limite matérielle                 complexe, quasi illimité
                                          → load balancer obligatoire

Passer à l'horizontale révèle les états cachés :

Problème	Solution
sessions en mémoire d'un serveur	sessions partagées (Redis/base) ou JWT
fichiers locaux d'une instance	stockage partagé/object storage
tâches planifiées dupliquées	verrou distribué ou worker dédié
cache par instance incohérent	cache centralisé

Règle de conception qui prépare l'horizontalité : aucun état dans le processus applicatif. Une API 100 % sans état se réplique sans réflexion — c'est la raison profonde des choix vus au chapitre authentification.

Réplication PostgreSQL

primary ── WAL stream ──→ replica(s)
   écritures                lectures (rapports, requêtes lourdes)

La réplication apporte lecture répartie ET haute disponibilité (promotion du replica si le primary tombe). Elle n'apporte PAS le scale-out des écritures : un seul primary accepte les INSERT/UPDATE — c'est la contrainte structurelle de toute base relationnelle.

Microservices : le vrai bilan

MONOLITHE MODULAIRE          MICROSERVICES
un déploiement               N déploiements
une base                     N bases (cohérence distribuée !)
appels de fonctions          appels réseau (latence, pannes)
transactions locales         sagas/compensations
débogage local               observabilité distribuée

Les microservices résolvent : équipes autonomes, déploiements indépendants, scaling ciblé. Ils introduisent : cohérence éventuelle, latence réseau partout, opérations multipliées. La position du programme est nette : un microservice n'est pas automatiquement supérieur — on découpe quand les frontières métier et les besoins d'équipe l'exigent, depuis un monolithe bien modularisé. Votre Devmind actuel EST la bonne architecture pour sa taille.

Kubernetes et cloud en une carte

Kubernetes orchestre des conteneurs à l'échelle :

pod (1+ conteneurs) ← deployment (N replicas, rolling update)
service = IP stable devant les pods     ingress = entrée HTTP/TLS
configmap/secret = configuration        persistent volume = disques

Chaque concept a son équivalent Docker Compose que vous connaissez — K8s ajoute : auto-réparation (redémarre ce qui meurt), autoscaling, déploiements progressifs. Coût réel : complexité opérationnelle majeure ; inutile avant plusieurs services et une équipe dédiée.

Le cloud, lui, loue ces briques managées :

VM ≈ votre serveur          RDS ≈ PostgreSQL managé (+backups, réplicas)
S3 ≈ object storage         DNS/LB/IAM managés

Le passage au cloud ne change pas vos compétences : il change QUI opère chaque couche. Le schéma final du cursus reste exactement le vôtre :

Utilisateur → navigateur → DNS → TCP → TLS → HTTP → proxy → conteneurs
→ NestJS controller → service → repository → driver → PostgreSQL → disque

Les trois cases encore floues de la carte

Load balancer. Dès deux instances derrière un même nom de domaine, un répartiteur choisit qui reçoit chaque requête. Ses deux fonctions vitales : la répartition (round-robin, moindre charge…) et les health checks (sortir de la rotation l'instance qui ne répond plus). Le piège à connaître : les sticky sessions (coller un utilisateur à une instance) réintroduisent l'état qu'on venait d'éliminer — avec un load balancer devant plusieurs instances saines et sans état, n'importe laquelle répond correctement, et perdre une instance ne déconnecte personne.

Scheduler Kubernetes. Dans la carte K8s, une pièce manque : qui décide SUR QUEL nœud tourne chaque pod ? Le scheduler. À chaque pod à lancer, il lit ses demandes (CPU, mémoire), l'état des nœuds et les contraintes (zones, affinités), puis attribue le pod. Vous ne l'écrivez jamais : vous déclarez « ce pod veut 256 Mo », il place — et replacera après une panne de nœud.

IAM et réseau cloud. Chez un cloud provider, vos réflexes Linux se transposent en API : IAM gère des identités de service avec permissions minimales (votre application a un compte, pas une clé universelle dans un .env) et les réseaux virtuels posent des règles de flux entre services — l'équivalent de vos users/groupes et firewall du chapitre 43, déclarés et versionnables. Le principe moindre privilège survit intact au changement de décor.

Exercice

1. Listez trois états cachés de votre todo vanilla et leur solution horizontale.
2. Quel signal justifierait de découper un module en service séparé ?
3. Pourquoi K8s est-il surqualifié pour Devmind aujourd'hui ?

Résumé

• Verticale simple/bornée ; horizontale exige zéro état applicatif.
• Microservices = compromis organisationnel, pas une fin.
• K8s/cloud = mêmes concepts, échelle et opérateur différents.