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

1. Push du code sur Git
2. Lint et tests unitaires
3. Build de l'image conteneur
4. Tests d'intégration
5. Déploiement en staging
6. Tests de bout en bout
7. 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