Immutable Infrastructure

Immutable Infrastructure est un pattern où les serveurs/containers/VMs ne sont jamais modifiés après leur déploiement — toute modification (patch, config change, application update) déclenche le remplacement par une nouvelle instance buildée from scratch depuis un image template. Concept popularisé par Chad Fowler 2013.

Opposé : mutable infrastructure traditionnel — SSH dans servers, edit configs, apply patches, install packages over time. Résultat : configuration drift (servers "identiques" deviennent subtly différents), snowflake servers difficiles à reproduire, debugging cauchemardesque, incertitude sur l'état réel des prods.

Immutable benefits : (1) reproducibility — same image deployed multiple times, predictable behavior ; (2) rollback simple — redeploy previous image ; (3) eliminates configuration drift ; (4) simpler troubleshooting (image version = exact state) ; (5) better security (frequent rebuilds with latest patches, less attack surface time) ; (6) enables Blue/Green and Canary deployments cleanly ; (7) auto-scaling deterministic.

Implémentation : (1) Container images Docker — immutable filesystem, redeploy nouvelle image au lieu de docker exec ; (2) AMI (Amazon Machine Images) — build via Packer, redeploy via ASG ; (3) GCE images, Azure managed images ; (4) Kubernetes Pods — toujours remplacés, jamais modifiés ; (5) Cloud-init userdata only for bootstrap, not for ongoing config.

Trade-offs : (1) coût build pipelines plus complexe ; (2) inadapté pour stateful workloads needing local persistent state (sauf via separate persistent volumes) ; (3) faster deploys nécessaires pour patches urgents. Compétences DOP-C02, AZ-400, CKA.