Cloud-native et serverless¶

L'infrastructure comme code, l'orchestration automatisee et les nouvelles frontieres de l'architecture.

Cloud-native : la définition CNCF¶

La CNCF (Cloud Native Computing Foundation) définit le cloud-native comme un ensemble de pratiques qui permettent aux organisations de construire et d'exécuter des applications scalables dans des environnements modernes et dynamiques — cloud public, prive ou hybride. Les technologies clés sont les conteneurs, les service meshes, les microservices, l'infrastructure immutable et les API declaratives.

Mais derriere la définition officielle, le cloud-native est avant tout un changement de mentalite. On ne deploie plus une application sur un serveur — on déclaré l'état desire du système et on laisse la plateforme s'en occuper. On ne prévoit plus la capacité — on laisse le système s'adapter automatiquement. On ne réparé plus les serveurs — on les remplacé.

Kubernetes et orchestration¶

Docker a résolu le problème de l'empaquetage. Kubernetes (K8s) a résolu le problème de l'orchestration : comment déployer, scaler, et gérer des centaines de conteneurs sur un cluster de machines.

Kubernetes, créé par Google et inspire de leur système interne Borg, est devenu le standard de facto pour l'orchestration de conteneurs. Il fournit :

• Scheduling : placer les conteneurs sur les nœuds du cluster en fonction des ressources disponibles
• Service discovery : chaque service a un nom DNS interne stable
• Load balancing : répartir le trafic entre les instances d'un service
• Self-healing : redémarrer automatiquement les conteneurs en échec
• Rolling updates : déployer progressivement une nouvelle version sans interruption
• Autoscaling : ajuster le nombre d'instances en fonction de la charge

# Exemple de deploiement Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-catalogue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-catalogue
  template:
    metadata:
      labels:
        app: api-catalogue
    spec:
      containers:
      - name: api-catalogue
        image: registry.exemple.com/catalogue:v2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 5

Ce manifest déclaré : "je veux 3 instances de mon service catalogue, version 2.1.0, avec au minimum 256Mi de mémoire et 250 millicores de CPU. Vérifié toutes les 10 secondes que le service est vivant, et toutes les 5 secondes qu'il est prêt à recevoir du trafic."

Kubernetes se charge du reste. Si une instance tombe, il en relance une. Si le nœud qui heberge une instance devient indisponible, Kubernetes replace l'instance sur un autre nœud. Si on change l'image vers v2.2.0, Kubernetes effectue un rolling update — il remplacé les instances une par une, en verifiant que chaque nouvelle instance est saine avant de remplacer la suivante.

Service mesh¶

Le service mesh est une couche d'infrastructure dédiée à la communication entre services. Il géré le trafic réseau (routage, load balancing, retry, circuit breaker), la sécurité (mTLS entre services, autorisation), et l'observabilité (métriques, traces) — sans que le code applicatif n'ait a s'en occuper.

graph TB
    subgraph "Service A Pod"
        A_APP["Application A"]
        A_PROXY["Sidecar Proxy<br/>(Envoy)"]
        A_APP --localhost--> A_PROXY
    end

    subgraph "Service B Pod"
        B_APP["Application B"]
        B_PROXY["Sidecar Proxy<br/>(Envoy)"]
        B_PROXY --localhost--> B_APP
    end

    subgraph "Control Plane"
        CP["Istiod / Linkerd Control Plane"]
    end

    A_PROXY --mTLS--> B_PROXY
    CP --config--> A_PROXY
    CP --config--> B_PROXY
    A_PROXY --telemetrie--> CP
    B_PROXY --telemetrie--> CP

Chaque service a un sidecar proxy (généralement Envoy) déployé a côté de lui. Tout le trafic entrant et sortant passe par ce proxy. Le control plane (Istio, Linkerd) configure les proxies et collecte la télémétrie.

Les deux principaux service meshes sont :

• Istio : le plus complet, le plus complexe. Développé par Google, IBM et Lyft. Utilisé Envoy comme data plane.
• Linkerd : plus léger, plus simple à opérer. Développé par Buoyant. Son propre proxy Rust ultra-performant.

Serverless et FaaS¶

Le serverless pousse l'abstraction un cran plus loin : on ne géré plus ni serveurs, ni conteneurs, ni orchestration. On deploie des fonctions qui s'exécutent à la demande et on ne paie que pour le temps d'exécution réel.

# Exemple AWS Lambda
import json

def handler(event, context):
    """Traite une commande recue via API Gateway."""
    body = json.loads(event["body"])
    order_id = body["order_id"]
    amount = body["amount"]

    # Logique metier
    result = process_order(order_id, amount)

    return {
        "statusCode": 200,
        "body": json.dumps({
            "order_id": order_id,
            "status": "confirmed"
        })
    }

Le serverless est idéal pour les charges de travail sporadiques (webhooks, traitement d'images, cron jobs) ou les API a trafic variable. Il est moins adapté aux traitements longs, aux applications avec beaucoup d'état, ou aux cas où le cold start (temps de démarrage à froid, de 100ms a plusieurs secondes) est inacceptable.

Event-driven architecture¶

L'architecture evenementielle découplé les services en les faisant communiquer via des événements plutôt que par des appels directs. Un service publie un événement ("commande créée"), et les services interesses le consomment independamment ("envoyer email de confirmation", "mettre à jour le stock", "notifier le service livraison").

graph LR
    CMD["Service Commande"] --"CommandeCreee"--> BUS["Event Bus<br/>(Kafka / EventBridge)"]
    BUS --"CommandeCreee"--> STOCK["Service Stock"]
    BUS --"CommandeCreee"--> NOTIF["Service Notification"]
    BUS --"CommandeCreee"--> FACTURE["Service Facturation"]
    STOCK --"StockMisAJour"--> BUS
    FACTURE --"FactureEmise"--> BUS

L'avantage principal est le découplage temporel et spatial. Le service commande ne connait pas les services consommateurs. Il ne les appelle pas directement. Il publie un fait ("une commande a été créée") et continue son exécution. Les consommateurs traitent l'événement a leur rythme.

Le coût de ce découplage est la cohérence eventuelle : les données ne sont pas immédiatement coherentes entre les services. Il faut accepter qu'il y ait un délai (généralement de quelques millisecondes a quelques secondes) entre la création de la commande et la mise à jour du stock. Pour la plupart des cas d'usage métier, ce délai est acceptable.

GitOps et FinOps¶

GitOps¶

GitOps applique les pratiques de développement logiciel (versioning, pull requests, revue de code) à la gestion de l'infrastructure. L'état desire de l'infrastructure est déclaré dans un repository Git. Un opérateur (ArgoCD, Flux) surveille le repository et reconcilie automatiquement l'état réel du cluster avec l'état déclaré.

Le workflow GitOps :

1. Le développeur modifie un manifest Kubernetes dans Git
2. La pull request est revue et approuvee
3. Le merge déclenche la reconciliation
4. L'opérateur applique les changements au cluster
5. En cas de problème, un git revert annule le changement

FinOps¶

FinOps est la pratique de gestion financiere du cloud. Le cloud rend les coûts variables et granulaires — au lieu d'un investissement initial fixe, on paie à l'heure, au Go, à la requête. Sans suivi, les coûts explosent.

FinOps repose sur trois piliers :

• Informer : rendre les coûts visibles par équipe, par service, par environnement
• Optimiser : identifier les ressources surdimensionnees, les instances inutilisees, les opportunités de reserved instances
• Opérer : intégrer les coûts dans les décisions d'architecture et de développement

Edge computing¶

L'edge computing rapproche le calcul des utilisateurs en déployant des nœuds de traitement en périphérie du réseau — dans les points de présence des CDN, les antennes 5G, ou les sites industriels.

L'intérêt est double : réduire la latence (un serveur a 10ms au lieu de 100ms) et réduire la bande passante (traiter les données localement au lieu de tout envoyer dans le cloud). Les cas d'usage typiques sont le streaming video (transcodage au plus pres), l'IoT industriel (traitement temps réel des capteurs) et les applications interactives (jeux, réalité augmentee).

Les plateformes edge modernes (Cloudflare Workers, AWS Lambda@Edge, Deno Deploy) permettent de déployer du code JavaScript ou WebAssembly sur des centaines de points de présence dans le monde. Le paradigme est le même que le serverless — du code sans serveur — mais avec une contrainte de localisation géographique.

État de l'art 2025¶

L'architecture cloud-native continue d'évoluer. Les tendances majeures en 2025 :

Platform engineering. Les équipes de plateforme construisent des "golden paths" — des chemins paves qui permettent aux développeurs de déployer en production sans maîtriser Kubernetes, Terraform ou les 200 services AWS. Le but est de réduire la charge cognitive.

WebAssembly (Wasm). Wasm sort du navigateur pour devenir un format d'exécution portable côté serveur. Plus léger que les conteneurs, plus sécurisé grâce à son sandboxing natif. Des runtimes comme Wasmtime et WasmEdge permettent d'exécuter du Wasm partout — edge, serverless, plugins.

AI-native infrastructure. Les workloads d'intelligence artificielle (entrainement, inference) imposent de nouvelles contraintes : GPU sharing, model serving, vector databases. Des outils comme vLLM, Ray et KubeFlow emergent pour orchestrer ces charges de travail spécifiques.

Sustainability. L'empreinte carbone du cloud devient un critère d'architecture. Les fournisseurs publient des outils de mesure (AWS Carbon Footprint, Google Cloud Carbon Sense) et les architectes commencent à intégrer l'impact environnemental dans leurs décisions.

Leçons de l'histoire¶

graph LR
    A["Mainframe<br/>centralise"] --"Besoin d'interface riche"--> B["Client-serveur"]
    B --"Besoin d'interoperabilite"--> C["Objets distribues"]
    C --"Trop complexe"--> D["SOA / Web Services"]
    D --"ESB monolithique"--> E["Microservices"]
    E --"Complexite operationnelle"--> F["Cloud-native"]
    F --"Charge cognitive"--> G["Platform engineering"]

Chaque génération d'architecture résout les problèmes de la précédente et en crée de nouveaux. C'est une constante de l'histoire de l'informatique :

• Le mainframe etait fiable et simple à opérer, mais rigide et ferme
• Le client-serveur a apporte l'interface graphique et la decentralisation, mais un cauchemar de déploiement
• Les objets distribués ont promis l'interopérabilité transparente, mais etaient trop complexes et ne passaient pas les firewalls
• SOA a structure l'intégration d'entreprise, mais l'ESB est devenu un nouveau monolithe
• Les microservices ont donne l'autonomie aux équipes, mais la complexité opérationnelle a explose
• Le cloud-native a automatise l'infrastructure, mais la charge cognitive sur les développeurs est devenue ecrasante

La leçon n'est pas que chaque approche est mauvaise — c'est que chaque approche est adaptée a un contexte. Un mainframe est encore le bon choix pour les transactions bancaires massives. Un monolithe est encore le bon choix pour une startup de 5 personnes. Les microservices sont le bon choix quand l'organisation et la charge l'exigent.

Le piege est de choisir une architecture parce qu'elle est à la mode plutôt que parce qu'elle répond au problème. On ne devrait jamais commencer par la solution — on devrait commencer par le problème, puis choisir la génération d'architecture qui le résout le mieux, avec le moins de complexité accidentelle possible.

Chapitre suivant : Cadrer — du besoin métier aux décisions structurantes.