☁️ Cloud Native
12-Factors, Microservices & Agnosticité
🔥 Mise en situation : La Baleine Échouée
Une entreprise historique décide de migrer son immense application (un Monolithe de 15 Go contenant le site web, les paiements, la compta et le support) sur Amazon AWS. Ils prennent simplement le fichier, le copient sur un serveur virtuel "dans le cloud", et crient victoire.
Le jour du Black Friday, le trafic est multiplié par 100. Le serveur est saturé. L'orchestrateur essaie de cloner l'application pour répartir la charge (Auto-Scaling), mais démarrer un mastodonte de 15 Go prend 20 minutes... Le temps qu'il démarre, les clients sont partis. L'entreprise est sur le cloud, mais n'est pas Cloud Native. Elle n'a ni l'élasticité ni l'agilité requises.
⚠️ Rappel : La CNCF (Cloud Native Computing Foundation)
Née sous l'égide de la Linux Foundation, la CNCF est l'organisme qui dicte les standards du Cloud Native.
Son but ? Éviter le "Vendor Lock-in" (être prisonnier d'un fournisseur cloud comme AWS ou Google). La CNCF certifie des logiciels open-source (comme Kubernetes, Prometheus, ArgoCD). Si vous construisez votre infrastructure avec ces briques certifiées, vous avez la garantie de pouvoir déménager de Google Cloud vers AWS ou Azure en quelques jours, sans devoir réécrire tout votre code.
🚦 Analogie : Location d'Appartement vs Hôtel
Développer une application traditionnelle sur serveur privé, c'est concevoir un appartement : on y installe ses propres meubles (dépendances physiques), et déménager est complexe.
Développer Cloud Native, c'est vivre l'application comme un client d'hôtel : on arrive avec juste sa valise (le conteneur), on branche ses appareils dans des prises standard (variables d'environnement), et on peut changer de chambre ou d'hôtel (AWS, GCP, Azure) instantanément sans rien modifier de nos affaires.
📖 Qu'est-ce que le Cloud Native ?
Créé et promu par la CNCF (Cloud Native Computing Foundation), le terme "Cloud Native" désigne une approche de conception logicielle pensée *dès le départ* pour tirer pleinement parti du modèle du Cloud Computing (élasticité, scalabilité, résilience).
💡 Le saviez-vous ? La philosophie Cloud Native
Le Cloud Native n'est pas lié à un fournisseur cloud spécifique comme AWS ou Google Cloud. C'est une philosophie de design. Une application "Cloud Native" classique doit pouvoir être détruite et recréée instantanément à l'identique sur n'importe quel autre serveur sans perte de données. C'est la fin du serveur domestique ("Pet") qu'on dorlote, place aux serveurs jetables ("Cattle").
Ce modèle repose sur 4 piliers technologiques interdépendants :
Conteneurs
Applications isolées et portables (Docker).
Microservices
Architecture découpée en briques indépendantes.
APIs Déclaratives
Communication via REST, gRPC ou Event-Driven.
CI/CD Dynamique
Infrastructure immuable gérée par du code (IaC).
🏭 A. Les 12-Factor Apps : La Bible Cloud Native
Élaborée par les ingénieurs de Heroku, la méthodologie "12-Factor App" est le manifeste ultime, une liste de 12 bonnes pratiques strictes pour créer des applications web ou SaaS (Software as a Service) résilientes et scalables. Toute application se disant "Cloud Native" devrait valider ces 12 points.
⚠️ Rappel Pédagogique : L'état naturel du Cloud, c'est l'amnésie (Stateless)
L'un des concepts les plus durs à assimiler pour les développeurs traditionnels est le facteur n°6 (Stateless Processes). Dans le cloud, votre application tourne dans un conteneur qui peut s'éteindre brutalement pour être redémarré sur un autre serveur. Si vous enregistrez un fichier d'upload utilisateur directement sur le disque dur interne de votre application, il sera perdu lors du redémarrage.
Règle d'or : L'application ne doit RIEN garder en mémoire locale. Tout doit être sous-traité : la base de données (pour la data vitale), S3 (pour les fichiers uploadés), Redis (pour les sessions utilisateurs). L'application en elle-même est un cerveau sans mémoire ("Stateless").
- 1. Codebase : Un seul dépôt Git, de multiples déploiements (Dev, Staging, Prod).
- 2. Dependencies : Déclarez explicitement toutes les dépendances (package.json, requirements.txt). Pas d'outils globaux cachés sur l'OS !
- 3. Config : Toute la configuration (mots de passe, URLs) doit être stockée dans les Variables d'Environnement, jamais dans le code.
- 4. Backing Services : Traitez les bases de données (MySQL, Redis, S3) comme des ressources attachées (on peut les remplacer par de l'URL swapping).
- 5. Build, Release, Run : Séparez strictement la compilation (Build), l'intégration de la config (Release), et l'exécution (Run).
- 6. Processes : L'application doit être Stateless. Toute donnée persistante doit l'être dans un service tiers (BDD, S3).
- 7. Port binding : L'app exporte elle-même son service via HTTP sur un port (pas besoin de config Apache/Nginx externe géré au niveau de l'app).
- 8. Concurrency : Scalez en lançant plusieurs instances du processus (horizontale), pas en augmentant la taille d'une instance (verticale).
- 9. Disposability : Démarrage rapide et arrêt gracieux (SIGTERM). Les conteneurs peuvent mourir à tout moment sans perte de données.
- 10. Dev/Prod Parity : Gardez Dev, Staging et Prod aussi similaires que possible. Terminé le "ça marche sur ma machine mais pas en prod".
- 11. Logs : Traitez les logs comme des flux d'événements (stdout). Ne gérez pas le routage/stockage dans le code de l'app.
- 12. Admin processes : Lancez les tâches d'admin/migration de DB comme des processus uniques (one-off) dans le même environnement.
🏗️ B. Monolithe vs Microservices
🏛️ Le Monolithe
L'application classique.
- ✅ Facile à développer et déployer (au début).
- ✅ Latence réseau nulle (tout communique en mémoire RAM).
- ❌ Une petite erreur dans le module "Facturation" crashe tout le site.
- ❌ Scalabilité inefficace : on doit tout dupliquer même si seule la base de donnée "Recherche" est saturée.
🧩 Microservices
L'approche Cloud Native.
- ✅ Tolérance aux pannes : La facturation crashe ? Le reste du site continue de fonctionner.
- ✅ Scalabilité granulaire : On multiplie juste l'API de paiement lors des pics.
- ✅ Agilité : Chaque équipe utilise sa propre stack technique (NodeJS, Python, Go).
- ❌ Complexité réseau exponentielle (Tracing distribué obligatoire !).
💡 Le saviez-vous ? La Loi de Conway
"Les organisations qui conçoivent des systèmes sont contraintes de produire des designs qui sont des copies des structures de communication de ces organisations." (Melvin Conway, 1967).
En clair : Si votre entreprise est organisée avec une gigantesque "Team Backend", une gigantesque "Team Frontend" et une "Team Ops", vous allez fatalement développer un gros Monolithe difficile à déployer.
Pour réussir l'adoption des microservices, Amazon et Netflix ont révolutionné leur management en créant des "Two-Pizza Teams" : de petites équipes multidisciplinaires (1 Dev UI, 2 Devs Backend, 1 Ops, 1 QA) entièrement propriétaires et responsables d'un unique microservice (ex: le module de paiement).
💡 Concept Fondamental : GitOps
Dans l'écosystème Cloud Native, avoir un pipeline CI/CD traditionnel ne suffit plus, la nouvelle norme est le GitOps.
L'idée est de faire de Git l'unique source de vérité pour l'infrastructure ET le code. Plutôt qu'un script (Github Actions) qui "pousse" les changements vers Kubernetes, un agent intelligent à l'intérieur du cluster (comme ArgoCD ou Flux) observe en permanence le dépôt Git. Dès que vous modifiez un fichier YAML sur Git, l'agent "tire" le changement et reconfigure le cluster automatiquement.
Magie : Si un administrateur tente de modifier un paramètre manuellement sur le serveur en production, l'agent GitOps va détecter cette anomalie (drift) et l'écraser immédiatement pour forcer le retour à l'état décrit publiquement sur Git !
⚠️ Rappel Stratégique : Cloud Native vs Cloud Agnostic
Cloud Native = "Ouvrir" toutes les portes du cloud. Vous utilisez intensément les services gérés d'AWS (Lambda, SQS, DynamoDB) pour un TTM (Time To Market) fulgurant. Inconvénient : le Vendor Lock-in (vous êtes coincés chez AWS).
Cloud Agnostic (ou Vendor Neutral) = Ne compter QUE sur des standards open-source (Kubernetes, Kafka, PostgreSQL). Vous pouvez migrer d'AWS à GCP ou On-Premise en un clic. Inconvénient : C'est très complexe et cher à configurer soi-même ! Souvent, le coût d'une migration théorique est inférieur au coût d'être agnostique pendant 10 ans.
Concepts Clés Serverless
Le Serverless est la pointe du Cloud Native : les serveurs existent, mais vous ne les gérez plus du tout. Vous ne payez que le temps CPU réellement consommé à la milliseconde près (Fonctions Serverless comme AWS Lambda, Google Cloud Functions). Pas de traffic = Pas de coût.