Immutable Infrastructure #

Di infrastruktur tradisional, server adalah sesuatu yang dirawat — di-patch, di-update, dikonfigurasi ulang, dan dipertahankan sepanjang hidupnya. Di immutable infrastructure, server adalah sesuatu yang diganti — ketika perubahan diperlukan, kamu tidak mengubah yang sudah ada, tapi membuat yang baru dan membuang yang lama. Pergeseran cara berpikir ini terdengar sederhana, tapi memiliki implikasi yang sangat dalam untuk konsistensi, keamanan, dan kemudahan operasional.

Mutable vs Immutable #

Perbedaan mendasar antara keduanya adalah apa yang terjadi ketika perubahan diperlukan.

Mutable Infrastructure (model tradisional):

  Server prod dibuat → dikonfigurasi → berjalan → di-patch → diupdate
       │                                              │
       └──────────────── dirawat terus ───────────────┘

  Jika ada bug di konfigurasi atau perlu update:
  → SSH ke server → jalankan perintah → ubah konfigurasi
  → Server terus berjalan, tapi state-nya berubah

  Masalah yang muncul:
  ✗ "Configuration drift" — server prod berbeda dengan staging
    karena patch yang berbeda, update yang berbeda waktu
  ✗ "Snowflake server" — server dengan konfigurasi unik yang
    tidak bisa direproduksi dengan mudah
  ✗ Tidak ada audit trail yang jelas tentang apa yang berubah dan kapan

Immutable Infrastructure:

  Server prod dibuat (versi 1.0) → berjalan
  Ketika ada perubahan:
  → Buat server baru (versi 1.1) dari image yang baru
  → Route trafik ke server baru
  → Terminate server lama

  Server tidak pernah dimodifikasi setelah dibuat
  "Replace, don't patch"

Masalah yang Dipecahkan #

Immutable infrastructure lahir dari masalah nyata yang membuat operasional infrastruktur menjadi tidak dapat diprediksi.

Configuration Drift #

Skenario Configuration Drift:

  Januari: Server A, B, C di-deploy dari image yang sama (v1.0)
  Februari: Security patch diapply ke A dan B, C terlewat
  Maret: Library update manual di B untuk debug sebuah issue
  April: Config nginx diubah di A karena ada incident

  Kondisi di bulan April:
  Server A: v1.0 base + Feb patch + April nginx change
  Server B: v1.0 base + Feb patch + March library update
  Server C: v1.0 base (tanpa patch apapun!)

  Problem:
  → Ketiga server seharusnya identik tapi tidak
  → Bug yang muncul di satu server sulit direproduksi di yang lain
  → Security posture berbeda antar server

  Dengan Immutable:
  → Semua server selalu dari image yang sama
  → Update = build image baru → deploy image baru → terminate lama
  → Tidak ada drift karena tidak ada modifikasi manual

Snowflake Server #

"Snowflake server" adalah server yang sangat unik dan
tidak bisa direproduksi dengan mudah.

Tanda-tanda kamu punya snowflake server:
  ✗ "Jangan restart server itu, kita tidak tahu apa yang akan terjadi"
  ✗ "Hanya Pak Budi yang tahu cara konfigurasi server itu"
  ✗ "Server itu ada file konfigurasi yang tidak ada di source control"
  ✗ Tim takut untuk mengubah apapun di server tersebut

Immutable infrastructure mencegah snowflake server:
  Semua konfigurasi ada di code (Infrastructure as Code)
  Server baru bisa direproduksi kapan saja dari code yang sama

Cara Kerja Immutable Infrastructure #

Ada dua cara umum mengimplementasikan immutable infrastructure: golden image dan container.

Golden Image #

Alur Golden Image:

  1. Mulai dari base image (OS minimal)
       │
       ▼
  2. Konfigurasi via skrip atau tool (Packer, Ansible)
     Install aplikasi, konfigurasi OS, setup monitoring agent
       │
       ▼
  3. Build dan simpan sebagai "golden image" (AMI, VM template)
       │
       ▼
  4. Deploy instance dari golden image ini
       │
       ▼
  5. Instance berjalan, TIDAK ada modifikasi manual setelah ini

  Ketika update diperlukan:
  → Ulangi dari langkah 1 dengan perubahan baru
  → Build golden image v2
  → Deploy instance baru dari v2
  → Terminate instance v1

  Keuntungan:
  ✓ Bisa di-rollback: deploy instance dari image versi sebelumnya
  ✓ Konsisten: semua instance dari image yang sama pasti identik
  ✓ Audit: riwayat image = riwayat perubahan infrastruktur

Container #

Container adalah implementasi immutable infrastructure yang paling umum saat ini:

  Image container bersifat immutable:
    → Setelah di-build, image tidak berubah
    → Container yang berjalan tidak di-modifikasi (idealnya)
    → Update = build image baru → deploy container baru → stop yang lama

  Dockerfile mendefinisikan image secara deklaratif:
  
  # Image v1.0
  FROM python:3.11-slim
  COPY requirements.txt .
  RUN pip install -r requirements.txt
  COPY app/ ./app/
  CMD ["python", "app/main.py"]

  # Image v1.1 (update library)
  FROM python:3.11-slim
  COPY requirements.txt .      # requirements.txt sudah diupdate
  RUN pip install -r requirements.txt
  COPY app/ ./app/
  CMD ["python", "app/main.py"]

  Image v1.0 tidak diubah — image v1.1 dibuat baru
  Rollback = jalankan container dari image v1.0

Implementasi Praktis dengan IaC #

Immutable infrastructure bekerja paling baik ketika dikombinasikan dengan Infrastructure as Code.

Alur Deployment Immutable:

  Developer push kode ke repository
       │
       ▼
  CI/CD Pipeline:
    → Build aplikasi
    → Run tests
    → Build container image / golden image
    → Tag image dengan versi (git commit hash)
    → Push ke image registry
       │
       ▼
  Deployment:
    → Terraform / deployment tool buat resource baru
      dari image versi terbaru
    → Health check memastikan resource baru sehat
    → Traffic dialihkan ke resource baru
    → Resource lama di-terminate

  Semua konfigurasi ada di kode:
    ✓ Image specification (Dockerfile / Packer template)
    ✓ Infrastructure definition (Terraform)
    ✓ Deployment process (CI/CD pipeline)
    → Tidak ada "pengetahuan tersembunyi" di kepala engineer

Trade-off yang Harus Dipahami #

Keuntungan Immutable:
  ✓ Tidak ada configuration drift
  ✓ Rollback mudah — deploy versi image sebelumnya
  ✓ Environment yang identik (dev = staging = prod dari image yang sama)
  ✓ Audit trail yang jelas — setiap versi image terdokumentasi
  ✓ Keamanan lebih baik — tidak ada SSH persistent, tidak ada
    modifikasi yang tidak terlacak

Tantangan Immutable:
  ✗ Deployment lebih lambat — butuh build image baru untuk setiap perubahan
      Mitigasi: optimasi layer caching di Docker, parallel build
  
  ✗ Storage untuk menyimpan image versi lama
      Mitigasi: retention policy untuk image yang sudah tua
  
  ✗ Debug lebih sulit — tidak bisa SSH dan lihat kondisi real-time
      Mitigasi: observability yang baik (logging, metrics, tracing)
      adalah wajib di immutable infrastructure
  
  ✗ Tidak cocok untuk stateful data
      Immutable untuk compute layer, tapi database tetap stateful
      Data harus di persistent volume atau managed service

Ringkasan #

Immutable berarti replace, bukan patch — server tidak dimodifikasi setelah dibuat; perubahan berarti membuat yang baru dan membuang yang lama.
Configuration drift adalah masalah nyata — server yang dirawat secara manual tidak bisa dijamin identik satu sama lain seiring waktu.
Container adalah implementasi immutable yang paling umum — image immutable, deploy container baru untuk update, rollback dengan deploy image lama.
IaC adalah pasangan wajib immutable infrastructure — semua konfigurasi harus ada di kode, tidak ada pengetahuan yang tersimpan di kepala engineer atau di server yang berjalan.
Observability menjadi lebih penting — tanpa SSH persistent, satu-satunya cara mengetahui kondisi sistem adalah melalui logs, metrics, dan traces.
Immutable untuk compute, stateful untuk data — persistent volume dan managed database tetap stateful; yang immutable adalah application dan infrastructure layer.

← Sebelumnya: Horizontal vs Vertical Scaling Berikutnya: Event-Driven Architecture →