Infrastruktur Manual #

Sebelum bisa menghargai apa yang Terraform tawarkan, kamu perlu memahami rasa sakitnya dulu. Infrastruktur manual — klik di console, jalankan perintah satu per satu, catat di dokumen Word — bukan hanya lambat. Ia menciptakan masalah sistemik yang baru terasa dampaknya ketika sesuatu sudah rusak di production. Artikel ini membahas masalah-masalah tersebut secara konkret agar kamu bisa melihat dengan jelas mengapa Infrastructure as Code bukan sekadar tren, tapi kebutuhan.

Apa yang Dimaksud Infrastruktur Manual #

Infrastruktur manual adalah pendekatan di mana tim infrastructure membuat dan mengkonfigurasi resource cloud secara langsung — melalui web console, CLI ad-hoc, atau script yang tidak terdokumentasi dengan baik.

CARA KERJA INFRASTRUKTUR MANUAL:

Developer/DevOps
      │
      ▼
  Login ke AWS Console
      │
      ├─ Klik "Launch Instance"
      ├─ Pilih AMI, instance type, subnet
      ├─ Buat security group secara manual
      ├─ Assign Elastic IP
      └─ Konfigurasi selesai (tapi tidak tercatat di mana pun)

Masalah: Tidak ada yang tahu persis langkah apa yang dilakukan
         kecuali orang yang mengkliknya saat itu.

Ini terasa cepat dan mudah di awal. Masalahnya muncul seiring waktu.

Masalah 1 — Tidak Bisa Direproduksi #

Konfigurasi yang dibuat secara manual hampir mustahil direproduksi secara identik. Manusia lupa langkah, melewati opsi default yang ternyata penting, atau menggunakan versi yang berbeda.

SKENARIO NYATA:

Production environment:
  - EC2 t3.medium, security group: port 80, 443, 22
  - RDS PostgreSQL 14.3, Multi-AZ enabled
  - ElastiCache Redis 7.0, cluster mode disabled
  - Dibuat 8 bulan lalu oleh engineer yang sudah resign

Staging environment (dibuat bulan lalu):
  - EC2 t3.small (salah pilih)
  - RDS PostgreSQL 14.8 (versi berbeda)
  - ElastiCache Redis 6.2 (versi lama karena lupa cek)
  - Multi-AZ disabled (terlewat)

Hasil: Bug yang muncul di production tidak bisa direproduksi
       di staging karena environment-nya berbeda.

Masalah 2 — Tidak Ada Audit Trail #

Di lingkungan manual, hampir tidak mungkin menjawab pertanyaan sederhana seperti: “Siapa yang mengubah security group ini? Kapan? Kenapa?”

PERTANYAAN YANG TIDAK BISA DIJAWAB:

□ Siapa yang menambahkan port 3306 ke security group production?
□ Kapan instance type diubah dari t3.small ke t3.large?
□ Kenapa subnet ini berbeda dari yang lain?
□ Apakah perubahan ini sudah di-review oleh senior engineer?
□ Apa yang berubah antara deployment minggu lalu dan sekarang?

Tanpa version control untuk infrastruktur,
semua pertanyaan di atas hanya bisa dijawab dengan
"tidak tahu" atau "tanya ke orang yang bikin".

Masalah 3 — Disaster Recovery yang Lambat #

Ketika sesuatu rusak parah — data center down, resource terhapus tidak sengaja, konfigurasi korup — tim yang mengandalkan infrastruktur manual harus rebuild dari ingatan dan dokumentasi yang tidak lengkap.

SKENARIO DISASTER RECOVERY:

Tanpa IaC:
  Hour 1-2:  Cari dokumentasi (mungkin tidak up-to-date)
  Hour 3-4:  Buat resource satu per satu dari ingatan
  Hour 5-6:  Debug kenapa ada yang tidak jalan
  Hour 7-8:  Coba ingat konfigurasi spesifik yang hilang
  Hour 9+:   Mungkin baru bisa production lagi

Dengan Terraform:
  Hour 1:    terraform apply
  Hour 2:    Production kembali normal
             (dengan konfigurasi yang dijamin identik)

Masalah 4 — Drift yang Tidak Terdeteksi #

Drift terjadi ketika kondisi infrastruktur aktual berbeda dari yang seharusnya. Di lingkungan manual, drift hampir tidak mungkin dideteksi secara sistematis.

CONTOH DRIFT:

Dokumentasi says:
  security_group: allow port 443 only

Realita di AWS Console:
  security_group: allow port 443, 8080, 3000
                  (ada yang buka port tambahan untuk debug
                   dan lupa ditutup kembali)

Dampak: Security hole yang tidak disadari selama berbulan-bulan.

Mengapa Script Bash Bukan Solusi #

Banyak tim mencoba mengganti klik manual dengan script bash. Ini lebih baik dari tidak ada apa-apa, tapi masih jauh dari cukup.

# ANTI-PATTERN: Script bash untuk membuat infrastruktur
#!/bin/bash

# Masalah 1: Tidak idempoten — jalankan dua kali, dapat error
aws ec2 create-security-group \
  --group-name "web-sg" \
  --description "Web security group"

# Masalah 2: Tidak tahu state saat ini
# Bagaimana script ini tahu apakah security group sudah ada?
# Tidak tahu — akan error jika dijalankan ulang

# Masalah 3: Error handling yang rapuh
aws ec2 authorize-security-group-ingress \
  --group-name "web-sg" \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0
# Bagaimana jika rule ini sudah ada? Error.
# Bagaimana jika group-nya belum selesai dibuat? Error.

# BENAR: Terraform menangani semua kasus ini secara otomatis
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Web security group"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
# Idempoten: jalankan 100 kali, hasilnya tetap sama
# State-aware: Terraform tahu apa yang sudah ada
# Error handling: ditangani oleh Terraform dan provider

Ringkasan #

Infrastruktur manual tidak bisa direproduksi — environment yang dibuat secara manual hampir tidak pernah benar-benar identik satu sama lain.
Tidak ada audit trail — perubahan yang dibuat lewat console tidak meninggalkan jejak yang bisa di-review atau di-rollback.
Disaster recovery lambat — rebuild dari ingatan dan dokumentasi usang bisa memakan waktu berjam-jam atau berhari-hari.
Drift tidak terdeteksi — perubahan kecil yang dilakukan di console tidak pernah tercatat dan lama-lama menumpuk jadi masalah besar.
Script bash bukan solusi — tidak idempoten, tidak state-aware, dan error handling-nya rapuh.
Infrastructure as Code menyelesaikan semua ini — konfigurasi yang bisa di-version control, di-review, dan dijalankan secara konsisten di semua environment.

← Sebelumnya: Apa itu Terraform? Berikutnya: Tool Imperative →