Best Practice Terraform untuk Infrastruktur yang Bertumbuh

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.

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.

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.

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.

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.

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.