Best Practice Terraform untuk Infrastruktur yang Bertumbuh

TL;DR

• Terraform skala besar lebih banyak berbicara tentang state boundary, reviewability, dan workflow daripada tentang sintaks HCL.
• Module yang opinionated biasanya lebih berguna daripada module yang mencoba mengekspose semua opsi provider.
• Control plane Terraform adalah remote state dan jalur apply; keduanya harus diperlakukan sebagai aset produksi.

Pendahuluan

Terraform terasa sederhana ketika hanya mengelola satu VPC dan sedikit resource. Kompleksitas sesungguhnya baru terlihat saat organisasi mulai menambah account, region, environment, serta tim pemilik service. Pada titik itu, masalah terbesar bukan lagi cara menulis HCL, tetapi cara menjaga perubahan infrastruktur tetap aman, dapat dipahami, dan mudah dioperasikan.

Banyak codebase Terraform menjadi menakutkan bukan karena providernya buruk, melainkan karena batas state tidak jelas, module terlalu generik, workflow apply tidak disiplin, dan drift dibiarkan menumpuk sampai setiap plan terasa seperti ancaman.

Problem di Production

Ketika estate tumbuh, codebase Terraform yang semula sederhana mulai memunculkan lock contention, plan yang terlalu besar, dan drift yang sulit dibaca. Pada titik itu, masalahnya bukan provider tertentu, tetapi absennya boundary operasional yang masuk akal.

Mental Model

Gunakan mental model blast radius per state. Satu root module atau satu state seharusnya merepresentasikan scope perubahan yang masih dapat dipahami reviewer manusia. Jika satu plan bisa mengubah terlalu banyak domain sekaligus, desain state-nya kemungkinan sudah salah.

Konsep Utama

State adalah batas blast radius

Keputusan arsitektural terpenting di Terraform biasanya bukan pemilihan module, melainkan pembagian state. Satu state file besar memang praktis di awal, tetapi cepat berubah menjadi bottleneck:

• lock sering bentrok
• output plan terlalu besar untuk direview
• perubahan kecil membawa risiko ke banyak resource
• ownership antar-tim menjadi kabur

State sebaiknya mengikuti batas operasional seperti account, environment, region, platform layer, atau domain aplikasi tertentu.

Module harus mengenkapsulasi standar

Module yang baik bukan module yang punya paling banyak variable. Module yang baik adalah module yang mengemas standar organisasi: tagging, logging, IAM baseline, encryption, naming, dan pola resource yang benar-benar didukung. Jika semua opsi provider diekspos, hasilnya adalah abstraksi yang sulit dipahami.

Reviewability lebih penting daripada sintaks yang rapi

Terraform berubah lewat diff. Jika diff tidak bisa dibaca reviewer manusia, organisasi sebenarnya sedang berjudi terhadap efek samping yang tidak dipahami. Karena itu, ukuran state, struktur root module, dan kebersihan workflow review jauh lebih penting daripada trik HCL yang canggih.

Dari sudut operasi

Secara operasional, kualitas Terraform terlihat dari seberapa mudah tim meninjau perubahan, mengunci state secara aman, dan menelusuri siapa yang menjalankan apply. HCL yang indah tidak banyak berarti jika workflow apply tidak bisa diaudit.

Arsitektur / Cara Kerja

Pendekatan yang umum dan sehat adalah memisahkan lapisan infrastruktur menjadi:

1. baseline organisasi atau account
2. networking dan security foundation
3. shared platform seperti cluster atau observability
4. resource spesifik aplikasi

Workflow delivery yang baik biasanya seperti ini:

1. fmt, validate, dan linter berjalan di pull request
2. CI membuat plan yang sempit untuk state terkait
3. reviewer memeriksa diff dan konteks perubahan
4. policy-as-code memblok pola berisiko
5. apply dijalankan dari automation context, bukan laptop lokal

Remote state backend juga harus diperlakukan sebagai control plane. Ia menyimpan metadata penting, mengontrol proses mutasi infrastruktur, dan membutuhkan enkripsi, locking, audit trail, serta permission yang sempit.

Decision point yang sering menentukan hasil

Arsitektur Terraform yang sehat biasanya memisahkan foundation, platform, dan application layer ke state berbeda. Remote backend, provider version, dan promotion workflow kemudian menjadi jalur mutasi yang jelas dan dapat dikontrol.

Practical Implementation

Mulai dari kontrol paling sempit yang bisa langsung memberi nilai operasional. Fokusnya bukan membuat desain paling lengkap, tetapi membuat satu jalur implementasi yang dapat direview, diuji, dan dipulihkan.

terraform {
  backend "s3" {
    bucket         = "terraform-state-prod"
    key            = "networking/ap-southeast-1/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
  }
}

Studi Kasus / Masalah Nyata

Satu monolith state untuk semua resource

Kasus ini sangat sering terjadi. Awalnya nyaman karena semua output ada di satu tempat. Beberapa bulan kemudian, tim jaringan, keamanan, dan aplikasi saling menunggu lock yang sama. Plan menjadi panjang dan penuh noise. Resource penting bisa terhapus tanpa disengaja karena reviewer kesulitan memilah perubahan yang relevan.

Drift baru terasa saat change window penting

Drift sering dibiarkan karena sistem masih jalan. Masalah muncul ketika perubahan mendesak harus diterapkan. Plan tiba-tiba menunjukkan puluhan perubahan tak terduga akibat modifikasi manual lama, perubahan default provider, atau resource yang diubah di luar Terraform. Pada titik ini apply menjadi berisiko tinggi.

Trade-offs

• State kecil lebih mudah direview, tetapi menambah koordinasi output dan dependency antar-layer.
• Module opinionated mengurangi entropy, tetapi menurunkan fleksibilitas tim aplikasi.
• Apply hanya dari CI lebih aman, tetapi kadang terasa lambat untuk eksperimen cepat.

Best Practices

Pin versi Terraform dan provider

Commit lockfile provider dan kelola upgrade secara sadar. Tooling drift sama berbahayanya dengan runtime drift.

Buat module yang opinionated

Paksa baseline organisasi seperti encryption, logging, tagging wajib, dan retention. Jangan biarkan semua service team memutuskan ulang hal dasar.

Apply hanya dari jalur otomatis

Produksi sebaiknya tidak bergantung pada sesi laptop engineer. Automation memberi konsistensi environment, identity, dan audit trail.

Gunakan policy untuk kesalahan yang berulang

Policy efektif untuk kelas risiko yang sering lolos review:

• bucket publik
• IAM terlalu luas
• resource sensitif tanpa encryption
• logging dimatikan
• region terlarang

Siapkan proses refactor state

Codebase besar pasti butuh import, moved block, migration, atau replacement terkontrol. Jika tim tidak punya pola yang jelas, refactor akan selalu terasa menakutkan.

Guardrail tambahan yang layak dipasang

• State kecil lebih mudah direview, tetapi menambah koordinasi output dan dependency antar-layer.
• Module opinionated mengurangi entropy, tetapi menurunkan fleksibilitas tim aplikasi.
• Apply hanya dari CI lebih aman, tetapi kadang terasa lambat untuk eksperimen cepat.

Failure Modes

• Monolith state menciptakan plan besar, lock contention, dan ownership yang kabur.
• Drift dibiarkan terlalu lama hingga change window penting dipenuhi perubahan tak terduga.
• Provider atau Terraform version berubah tanpa kontrol dan mengubah perilaku plan.

Kesalahan Umum

• menyimpan seluruh estate di satu state
• membuat module seperti framework serbaguna
• menjalankan apply produksi dari laptop
• memberi akses backend terlalu luas
• mengabaikan drift sampai setiap plan terlihat menyeramkan
• mengandalkan review manusia tanpa policy untuk pola risiko berulang

Kesimpulan

Terraform menjadi kuat ketika batas operasionalnya jelas. State harus mengikuti failure domain, module harus mengemas standar, workflow harus mengutamakan reviewability, dan apply harus berjalan di jalur yang bisa diaudit. Dengan pola itu, Terraform tetap berguna saat estate infrastruktur tumbuh besar dan kompleks.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.