Guide : architecture cloud-native

Le cloud-native n'est pas « héberger dans le cloud ». C'est une approche de conception qui exploite les caractéristiques du cloud :





Élasticité — l'application s'adapte automatiquement à la charge


Résilience — elle résiste aux pannes partielles


Automatisation — déploiements, scaling, monitoring automatisés


Observabilité — comprendre ce qui se passe en production





Les piliers techniques





Conteneurs (Docker)


Orchestration (Kubernetes, ECS, Cloud Run)


Microservices ou monolithe modulaire


Infrastructure as Code


CI/CD automatisé


Observabilité (logs, métriques, traces)





Ces piliers sont indépendants : on peut adopter les conteneurs sans microservices, ou l'IaC sans conteneurs.

Le débat fait rage depuis 10 ans. La réponse pragmatique : commencer par un monolithe modulaire.


Pourquoi pas les microservices dès le début





Complexité opérationnelle élevée (déploiement, monitoring, debugging)


Coût d'infrastructure plus important


Nécessite des compétences DevOps pointues


Surdimensionné pour la majorité des projets





Le monolithe modulaire


Une seule application, mais organisée en modules clairement séparés avec des interfaces définies. Avantages :





Simplicité de déploiement et de débogage


Coût réduit


Possibilité d'extraire des modules en services plus tard





Quand passer aux microservices


Quand une équipe atteint 30 à 50 personnes, quand les besoins de scalabilité varient fortement entre composants, ou quand les cycles de release doivent être indépendants.

Conteneurs


Un conteneur embarque une application et ses dépendances. Il fonctionne de manière identique partout : poste de développement, serveur de test, cloud.


Orchestration


Gérer 5 conteneurs manuellement est possible. En gérer 200 ne l'est pas. Un orchestrateur :





Démarre et arrête les conteneurs


Répartit la charge entre eux


Redémarre en cas de panne


Gère les mises à jour sans interruption





Les options





Kubernetes — standard, puissant, complexe


ECS/Fargate (AWS) — plus simple, écosystème AWS


Cloud Run (GCP) — serverless, très simple


Azure Container Apps — équivalent Microsoft





Le choix dépend de votre écosystème cloud et de vos compétences. Kubernetes n'est pas toujours le bon choix.

Une application cloud-native doit résister aux pannes. Non pas « si » mais « quand ».


Les principes





Redondance — plusieurs instances de chaque composant


Isolation — la panne d'un service ne fait pas tomber les autres


Timeouts — toujours définir des délais d'attente


Retry — retenter les appels échoués, avec backoff exponentiel


Circuit breaker — arrêter d'appeler un service défaillant pour lui laisser le temps de récupérer


Graceful degradation — fonctionner en mode dégradé plutôt que tomber complètement





Tester la résilience


Injecter des pannes volontairement (chaos engineering) en environnement de test. Identifier les points fragiles avant qu'ils ne cassent en production.

Observabilité = comprendre ce qui se passe dans un système distribué. Trois piliers.


Logs


Événements horodatés. Structurés (JSON), pas en texte libre. Chaque log contient : timestamp, service, niveau, request ID, message.


Métriques


Valeurs agrégées dans le temps : latence, taux d'erreur, débit, saturation. Suivies dans des dashboards, avec alertes sur seuils.


Traces


Suivi d'une requête à travers tous les services qu'elle traverse. Indispensable pour diagnostiquer les lenteurs dans un système distribué.


Les outils





Open source — Prometheus, Grafana, Loki, Jaeger, Tempo


Commerciaux — Datadog, New Relic, Dynatrace


Cloud natifs — CloudWatch, Cloud Monitoring, Azure Monitor

Le cloud-native permet de déployer plusieurs fois par jour. Encore faut-il que ce soit sûr.


Le pipeline CI/CD





Push du code sur Git


Lint et tests unitaires


Build de l'image conteneur


Tests d'intégration


Déploiement en staging


Tests de bout en bout


Déploiement en production





Stratégies de déploiement





Rolling — remplacer progressivement les instances


Blue/green — deux environnements identiques, basculer d'un coup


Canary — déployer sur un petit pourcentage du trafic, surveiller, puis étendre





Retour arrière


Chaque déploiement doit avoir une procédure de rollback testée. Idéalement automatique si les métriques se dégradent.

☐ Application containerisée


☐ Orchestrateur choisi et configuré


☐ IaC pour toute l'infrastructure


☐ CI/CD automatisé


☐ Monitoring et alerting


☐ Logs structurés


☐ Traces distribuées


☐ Tests de résilience


☐ Stratégie de rollback


☐ Documentation d'architecture