CNCF et architecture microservices

La CNCF héberge aujourd’hui plus de 180 projets. Le landscape ressemble à une mosaïque illisible. Et côté architecture, le débat “microservices vs monolithe” fait encore couler de l’encre — souvent pour de mauvaises raisons. Ce cours coupe à travers le bruit : comment naviguer dans l’écosystème CNCF avec discernement, quand les microservices valent vraiment le coup, et quels patterns architecturaux utiliser en production. Pas de dogme, pas de “Netflix fait comme ça” — du pragmatisme pour des équipes réelles.

Le paysage CNCF : s’y retrouver sans se noyer

La Cloud Native Computing Foundation (CNCF) est la fondation qui héberge Kubernetes, Prometheus, Envoy, et des dizaines d’autres projets open-source. Son landscape (landscape.cncf.io) couvre toute la stack cloud-native : provisioning, runtime, orchestration, observabilité, service mesh, sécurité, stockage.

Le critère de choix numéro un, c’est le niveau de maturité :

• Sandbox — Projets expérimentaux, à surveiller mais pas pour la prod
• Incubating — Adoption croissante, utilisable en staging, quelques entreprises en prod
• Graduated — Validé en production par de nombreuses organisations. C’est le gold standard.

Les projets graduated sont tes valeurs sûres : Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd, Jaeger, Helm, ArgoCD, OPA, Falco, Istio… Si tu dois choisir entre un projet graduated et un outil propriétaire équivalent, le graduated offre la portabilité et la pérennité.

💡 Tip DevOps : Avant d’adopter un outil CNCF, vérifie trois choses : le nombre de contributeurs actifs (pas juste les stars GitHub), la fréquence des releases, et si des entreprises comparables à la tienne l’utilisent en prod. Un projet avec 10k stars mais 2 contributeurs est un risque.

Pour construire une stack cloud-native pragmatique, voici un choix solide par couche :

# Stack CNCF pragmatique 2026
provisioning:
  iac: Terraform / OpenTofu      # Graduated-equivalent
  k8s-native: Crossplane          # Incubating, montée en puissance

runtime:
  container: containerd            # Graduated, standard K8s
  orchestration: Kubernetes        # Graduated, incontournable

networking:
  ingress: Envoy / nginx-ingress  # Graduated / stable
  service-mesh: Istio / Linkerd   # Graduated / Graduated
  dns: CoreDNS                     # Graduated, intégré K8s

observability:
  metrics: Prometheus + Grafana    # Graduated + ecosystème
  tracing: Jaeger / Tempo          # Graduated / Grafana stack
  logging: Fluentd → Loki          # Graduated → Grafana stack

security:
  policy: OPA / Kyverno            # Graduated / CNCF
  runtime: Falco                   # Graduated
  secrets: External Secrets Op.    # Incubating

cicd:
  gitops: ArgoCD / Flux            # Graduated / Graduated
  packaging: Helm                  # Graduated

🧠 À retenir : Ne choisis pas un outil parce qu’il est sur le landscape CNCF. Choisis-le parce qu’il résout ton problème, dans ton contexte, avec ton équipe. Un outil graduated que personne dans l’équipe ne maîtrise n’est pas un meilleur choix qu’un outil plus simple que tout le monde connaît.

Microservices vs monolithe : une comparaison honnête

Le monolithe n’est pas un anti-pattern. Les microservices ne sont pas une silver bullet. La vraie question n’est pas “lequel est mieux ?” mais “lequel est adapté à mon contexte ?”.

Un monolithe est un seul processus déployable qui contient toute la logique métier. Les microservices sont des services indépendants, chacun avec sa base de données, déployables séparément.

Les vrais trade-offs :

• Complexité : le monolithe est simple à développer, déployer et debugger. Les microservices ajoutent la complexité réseau, la cohérence des données distribuées, et l’observabilité multi-services.
• Scaling : le monolithe scale en entier. Les microservices permettent de scaler uniquement le service sous charge.
• Autonomie des équipes : avec un monolithe, tout le monde touche au même code. Avec les microservices, chaque équipe possède son service de bout en bout.
• Résilience : un bug dans un module du monolithe peut crasher tout le système. En microservices, un service défaillant est isolé (si les circuit breakers sont en place).

# Monolithe — tout dans un seul processus
# Avantage : simple, performant (appels en mémoire)
class OrderService:
    def create_order(self, user_id, items):
        user = UserModule.get_user(user_id)       # Appel local
        payment = PaymentModule.charge(user, total) # Appel local
        stock = InventoryModule.reserve(items)      # Appel local
        return Order(user, items, payment, stock)

# Microservices — chaque module est un service réseau
# Avantage : indépendance, scaling ciblé
class OrderService:
    def create_order(self, user_id, items):
        user = requests.get(f"{USER_SVC}/users/{user_id}")    # HTTP
        payment = requests.post(f"{PAYMENT_SVC}/charge", ...)  # HTTP
        stock = requests.post(f"{INVENTORY_SVC}/reserve", ...) # HTTP
        # Que faire si payment réussit mais inventory échoue ? → Saga

⚠️ Attention : “Database per service” est non-négociable en microservices. Si deux services partagent la même base de données, tu n’as pas des microservices — tu as un monolithe distribué avec tous les inconvénients des deux architectures et les avantages d’aucune.

Quand migrer et le modular monolith

Les signaux qu’il est temps de découper :

• L’équipe dépasse 8-10 développeurs sur le même repo
• Les builds dépassent 30 minutes
• Les merge conflicts sont quotidiens
• Un bug dans le module X casse systématiquement le module Y
• Tu as besoin de scaler un seul composant (ex : le service de recherche)

Les signaux que c’est trop tôt :

• “Netflix fait des microservices” (toi tu n’es pas Netflix)
• L’équipe fait moins de 5 personnes
• Le domaine métier n’est pas encore stable
• Tu n’as ni observabilité ni CI/CD automatisé

Le modular monolith est souvent la meilleure étape intermédiaire : un seul déploiement, mais des modules bien découplés avec des interfaces claires et des schémas DB séparés. Chaque module est prêt à être extrait en service le jour où c’est nécessaire — le pattern Strangler Fig.

🔥 Cas réel : Shopify, qui gère des milliards de dollars de transactions, fonctionne sur un monolithe Ruby on Rails modulaire — pas sur des microservices. Ils ont investi massivement dans le découpage en modules (composants) avec des frontières claires, plutôt que dans la distribution réseau. Preuve que le monolithe modulaire n’est pas un compromis : c’est un choix d’architecture délibéré.

Les patterns essentiels en microservices

Quand tu passes aux microservices, ces patterns ne sont pas optionnels — ils sont la différence entre une architecture qui tient en prod et un cauchemar distribué.

API Gateway — Le point d’entrée unique pour tous les clients. Il gère le routing, l’authentification, le rate limiting, la transformation des requêtes et le circuit breaking. Kong et Envoy sont les choix CNCF de référence. Sans API Gateway, chaque client doit connaître l’adresse de chaque service.

Service Mesh — L’infrastructure réseau transparente entre tes services. Un sidecar proxy (Envoy) est injecté dans chaque pod et gère le mTLS, les retries, les timeouts, le circuit breaking et la collecte de métriques — sans toucher au code applicatif. Istio et Linkerd sont les deux options graduated.

# Istio — VirtualService pour le traffic management
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
            subset: v2
          weight: 90
        - destination:
            host: order-service
            subset: v1
          weight: 10
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: 5xx,reset,connect-failure

Event-Driven Architecture — Au lieu d’appels REST synchrones entre services (couplage fort, cascade de pannes), les services communiquent via des événements sur un broker (Kafka, NATS). Le service Order publie un événement OrderCreated, et les services Payment, Inventory et Notification le consomment indépendamment.

{
  "eventType": "OrderCreated",
  "eventId": "evt-abc123",
  "timestamp": "2026-03-20T14:30:00Z",
  "data": {
    "orderId": "ord-789",
    "userId": "usr-456",
    "items": [{"sku": "WIDGET-01", "qty": 2}],
    "total": 49.99
  }
}

Saga Pattern — Comment gérer les transactions distribuées sans transaction ACID globale ? Chaque service exécute sa transaction locale et publie un événement. Si une étape échoue, les étapes précédentes publient des événements de compensation (annulation). C’est complexe — préfère les transactions locales quand possible.

Circuit Breaker — Quand un service downstream est en panne, le circuit breaker coupe les appels après N échecs (état OPEN), renvoie une réponse de fallback, et teste périodiquement si le service est revenu (état HALF-OPEN). Ça évite la cascade de pannes qui fait tomber toute l’architecture.

💡 Tip DevOps : Commence par l’API Gateway et l’Event-Driven. Le Service Mesh peut attendre que tu aies 10+ services. Le Saga Pattern peut attendre que tu aies un vrai besoin de transactions distribuées. La complexité se gère en couches, pas d’un coup.

Bonnes pratiques et pièges à éviter

Ce qui marche en entreprise :

• Monolith first → modular monolith → microservices quand la douleur est réelle
• Chaque service a sa propre base de données, son propre repo, son propre pipeline CI/CD
• L’observabilité (traces distribuées, métriques, logs corrélés) est en place avant le découpage
• Les contrats d’API sont versionés et testés (contract testing avec Pact)
• Les événements ont un schéma validé (Schema Registry avec Avro/Protobuf)

Les pièges classiques :

• Des microservices sans observabilité = du debugging en aveugle dans un système distribué
• Des microservices sans CI/CD automatisé = N pipelines manuels au lieu d’un seul
• Des services “micro” de 50 lignes qui ne font que proxy un autre service — c’est des nano-services, pas des microservices
• Partager une base de données entre services “temporairement” — il n’y a rien de plus permanent qu’une solution temporaire

🔥 Cas réel : Une startup SaaS B2B a découpé son monolithe en 23 microservices avec une équipe de 6 développeurs. Résultat : chaque développeur maintenait 4 services, le temps de déploiement a triplé, et les incidents en prod ont augmenté de 400%. Après 8 mois, ils sont revenus à un monolithe modulaire avec 3 modules bien découpés. Le throughput de l’équipe a doublé.

Résumé

Le paysage CNCF s’organise par niveaux de maturité — les projets graduated sont tes valeurs sûres pour la production. La question “microservices vs monolithe” n’a pas de réponse universelle : elle dépend de la taille de l’équipe, de la maturité de l’infrastructure et de la stabilité du domaine métier. Le modular monolith est souvent le meilleur point de départ. Quand les microservices deviennent nécessaires, les patterns API Gateway, Service Mesh, Event-Driven, Saga et Circuit Breaker sont les briques fondamentales. La règle d’or : n’ajoute de la complexité distribuée que quand la douleur du monolithe dépasse la complexité des microservices — et jamais avant d’avoir l’observabilité et le CI/CD en place.