Cloud et microservices¶

L'infrastructure devient programmable, les services deviennent autonomes — et la complexité change de nature.

Cloud computing : la revolution de l'infrastructure¶

Avant le cloud, déployer une application en production imposait un parcours prévisible : acheter des serveurs, les installer dans un datacenter, configurer le réseau, installer le système d'exploitation, déployer l'application. Ce processus prenait des semaines, voire des mois. Et il fallait dimensionner pour la charge maximale prévue — payer en permanence pour des ressources utilisées a 10% du temps en moyenne.

Le cloud computing a inverse cette equation. Au lieu d'acheter du matériel, on loue de la capacité à la demande. Au lieu de dimensionner pour le pic, on augmente et réduit les ressources en temps réel. Au lieu de gérer un datacenter, on délégué l'infrastructure a un fournisseur specialise.

Amazon Web Services a lance EC2 en 2006, transformant une nécessité interne (gérer l'infrastructure du site de e-commerce) en un produit. Google et Microsoft ont suivi avec Google Cloud Platform et Azure. En moins de dix ans, le cloud est devenu le mode de déploiement par défaut pour les nouvelles applications.

Les modèles de service¶

Le cloud se decline en plusieurs niveaux d'abstraction :

graph TB
    subgraph "On-premise"
        OP_APP["Application"]
        OP_DATA["Donnees"]
        OP_RT["Runtime"]
        OP_MW["Middleware"]
        OP_OS["OS"]
        OP_VIRT["Virtualisation"]
        OP_SRV["Serveurs"]
        OP_STOCK["Stockage"]
        OP_NET["Reseau"]
    end

    subgraph "IaaS"
        I_APP["Application"]
        I_DATA["Donnees"]
        I_RT["Runtime"]
        I_MW["Middleware"]
        I_OS["OS"]
        I_CLOUD["Cloud Provider gere ↓"]
    end

    subgraph "PaaS"
        P_APP["Application"]
        P_DATA["Donnees"]
        P_CLOUD["Cloud Provider gere ↓"]
    end

    subgraph "SaaS"
        S_CLOUD["Cloud Provider gere tout"]
    end

Shared responsibility model¶

Le modèle de responsabilité partagee est un concept fondamental du cloud. Le fournisseur est responsable de la sécurité du cloud (infrastructure physique, réseau, hyperviseur). Le client est responsable de la sécurité dans le cloud (configuration des accès, chiffrement des données, mise à jour des applications).

The Twelve-Factor App¶

En 2012, les ingénieurs de Heroku ont formalisé les douze facteurs d'une application cloud-native. Ces principes, nes de l'observation de milliers d'applications déployées sur Heroku, restent une référence.

Ces facteurs ne sont pas des contraintes arbitraires. Chacun résout un problème spécifique du déploiement en cloud. Par exemple, le facteur 6 (processus sans état) permet de scaler horizontalement : si aucun processus ne garde d'état en mémoire, on peut en ajouter ou en supprimer sans perdre de données.

Conteneurs et Docker¶

Docker, lance en 2013, a democratise la conteneurisation. Un conteneur encapsule une application avec toutes ses dépendances dans une image portable et reproductible. Contrairement a une machine virtuelle, un conteneur partage le noyau du système hôte — il est plus léger, démarré en secondes, et consomme moins de ressources.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ ./src/
EXPOSE 8080
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8080"]

Le Dockerfile ci-dessus définit une image reproductible : même base Python, mêmes dépendances, même code. Que l'on build cette image sur le portable du développeur ou sur le serveur CI, le résultat est identique. Le fameux "ca marche sur ma machine" disparait.

Docker a résolu le problème du déploiement qui empoisonnait l'informatique depuis l'ere client-serveur. Plus besoin de scripts d'installation complexes, de gestion de versions de librairies, de configuration spécifique à chaque environnement. On build une image, on la pousse dans un registre, on la deploie partout.

Microservices¶

Les microservices sont un style architectural ou l'application est decomposee en services petits, autonomes, deployables independamment. Chaque service est responsable d'une capacité métier, possédé sa propre base de données, et communique avec les autres via des API légères (HTTP/REST, gRPC, messaging).

Les pionniers¶

Netflix et Amazon sont les pionniers des microservices, pas par choix ideologique mais par nécessité.

Amazon, au début des années 2000, avait un monolithe dont le déploiement prenait des heures et dont les pannes etaient cascadantes. Jeff Bezos a impose le fameux "API mandate" en 2002 : toute communication entre équipes devait passer par des API de service. Les équipes devaient concevoir leurs interfaces comme si elles etaient exposees a des développeurs externes. Cette décision, brutale à l'epoque, a pose les bases de l'architecture microservices — et accessoirement, d'AWS.

Netflix a migré vers les microservices après une panne majeure de sa base de données en 2008. L'entreprise a investi massivement dans des outils de résilience (Hystrix, Zuul, Eureka, Ribbon) qu'elle a ensuite open-source, creant l'écosystème Netflix OSS qui a influence toute une génération d'architectes.

Decomposition par domaine¶

La decomposition en microservices suit idealement les frontieres du domaine métier, pas les couches techniques. On ne crée pas un service "base de données" et un service "interface" — on crée un service "catalogue", un service "commande", un service "paiement".

graph TB
    subgraph "Monolithe"
        M_UI["Interface utilisateur"]
        M_BL["Logique metier<br/>(catalogue + commande + paiement)"]
        M_DB[("Base de donnees<br/>unique")]
        M_UI --> M_BL
        M_BL --> M_DB
    end

    subgraph "Microservices"
        GW["API Gateway"]

        subgraph "Service Catalogue"
            S1["API Catalogue"]
            DB1[("BDD Catalogue")]
            S1 --> DB1
        end

        subgraph "Service Commande"
            S2["API Commande"]
            DB2[("BDD Commande")]
            S2 --> DB2
        end

        subgraph "Service Paiement"
            S3["API Paiement"]
            DB3[("BDD Paiement")]
            S3 --> DB3
        end

        GW --> S1
        GW --> S2
        GW --> S3
        S2 --appel API--> S1
        S2 --appel API--> S3
    end

Caractéristiques des microservices¶

La complexité déplacée¶

Les microservices ne reduisent pas la complexité — ils la deplacent du code vers l'infrastructure. Un monolithe a un déploiement simple, un debugging simple (stack trace unique), des transactions simples (ACID). Les microservices introduisent :

• La latence réseau entre chaque appel de service
• La cohérence eventuelle au lieu des transactions ACID
• Le debugging distribué qui nécessité du tracing (Jaeger, Zipkin)
• Le déploiement orchestre de dizaines ou centaines de services
• La gestion des pannes partielles — un service sur vingt peut être en panne

Quand les microservices sont justifies¶

Les microservices ne sont pas une fin en soi. Ils se justifient quand :

• Plusieurs équipes travaillent sur le même système et se bloquent mutuellement
• Les cycles de déploiement sont trop longs parce que tout doit être déployé ensemble
• Les contraintes de scalabilité différent entre les composants (le catalogue est lu 1000 fois plus que les commandes)
• L'organisation est structurée en équipes autonomes alignees sur des domaines métier

Si on est une équipe de cinq développeurs qui travaillent sur une seule application, les microservices sont un surcout sans benefice. La complexité opérationnelle (monitoring, tracing, déploiement, réseau) dépassé largement le gain en autonomie.

La loi de Conway en action¶

La loi de Conway stipule que les systèmes refletent la structure de communication des organisations qui les produisent. Les microservices rendent cette loi explicite : chaque service correspond à une équipe, chaque frontiere de service correspond à une frontiere organisationnelle.

L'inverse est egalement vrai — c'est la "manœuvre inverse de Conway". On peut reorganiser les équipes pour obtenir l'architecture souhaitee. Si on veut des services autonomes, on crée des équipes autonomes alignees sur les domaines métier.

Netflix, Amazon et Spotify ont structure leurs organisations pour que la loi de Conway travaille en leur faveur. Les "squads" de Spotify, les "two-pizza teams" d'Amazon, les équipes de domaine de Netflix — ce sont des structures organisationnelles conçues pour produire des architectures distribuées.

Chapitre suivant : Cloud-native et serverless — l'infrastructure comme code, l'orchestration automatisee et les nouvelles frontieres.