Belajar Terraform - Managed IaC Platforms (Terraform Cloud / Spacelift)

#Pendahuluan

Setelah di episode 13 sebelumnya kita membangun pipeline CI/CD sendiri — menulis workflow GitHub Actions dan GitLab CI untuk fmt, lint, security scan, plan, hingga apply dengan approval gate — pada episode kali ini kita akan membahas alternatif yang semakin populer di organisasi besar: managed IaC platforms seperti Terraform Cloud (sekarang bernama HCP Terraform), Spacelift, env0, dan Scalr.

Di episode 13, kalian mungkin menyadari bahwa membangun pipeline IaC yang benar membutuhkan banyak komponen: konfigurasi OIDC, workflow plan/apply terpisah, environment protection, artifact plan, hingga state backend dengan locking. Itu semua adalah pekerjaan infrastruktur yang harus dirawat oleh tim kalian sendiri. Pertanyaannya sekarang: apakah kita perlu membangun dan merawat semua itu, atau adakah yang bisa mengelolanya untuk kita?

Platform managed IaC menjawab pertanyaan itu dengan mengambil alih komponen-komponen tersebut menjadi layanan terkelola: runner eksekusi remote, integrasi VCS bawaan, state management dengan enkripsi & locking, registry modul privat, hingga policy enforcement. Mengapa topik ini penting di dunia nyata? Karena begitu sebuah organisasi memiliki banyak tim dan banyak stack Terraform, biaya memelihara pipeline self-managed menjadi lebih besar daripada biaya berlangganan platform — dan platform tersebut juga menambahkan safety net (RBAC, audit log, policy) yang sulit dibangun sendiri dengan kualitas yang sama.

#Pembahasan Utama

#Apa yang Dipecahkan Platform Managed IaC?

Mari kita jujur sebentar: segala sesuatu yang dibangun di episode 13 memang benar dan berfungsi. Namun jika kalian bekerja di organisasi dengan 10 tim yang masing-masing mengelola 5 stack infrastruktur, total ada 50 pipeline yang harus dirawat. Setiap pipeline butuh konfigurasi, versi, monitoring, dan orang yang bertanggung jawab. Di titik itu, tim platform engineering mulai bertanya: "mengapa kita membangun ulang roda yang sama 50 kali?"

Perbandingan tiga model eksekusi Terraform:

#Fitur Utama Platform Managed

Meski tiap platform punya keunikan, lima fitur berikut adalah tulang punggung yang dimiliki hampir semua platform managed IaC:

Masing-masing fitur ini pada dasarnya adalah sesuatu yang kita bangun manual di episode-episode sebelumnya, dikemas menjadi fitur bawaan yang terintegrasi. Itulah mengapa adopsi platform ini sering disebut sebagai "membeli waktu kembali" bagi tim platform.

#Perbandingan Platform Managed IaC

Berikut perbandingan empat platform utama yang perlu kalian kenal:

Empat platform ini bersaing di tiga sumbu utama: kedalaman ekosistem Terraform (HCP Terraform unggul karena dibuat vendor yang sama), fleksibilitas multi-tool (Spacelift dan env0 mendukung lebih dari sekadar Terraform), dan kontrol biaya enterprise (Scalr dan env0 menonjol). Tidak ada yang "paling baik" secara absolut — semuanya bergantung kebutuhan organisasi, yang akan kita bahas di bagian skenario adopsi.

#Alur Kerja VCS-Driven di HCP Terraform

Untuk memahami bagaimana platform ini bekerja, mari kita bedah alur kerja paling umum: VCS-driven workflow di HCP Terraform. Konsepnya sama di semua platform.

Begitu kalian menghubungkan repository (misal GitHub) ke workspace, setiap kejadian berikut akan memicu run:

1. Developer push commit / buka PR  → run "Plan" otomatis di remote runner
2. Plan selesai                     → hasil terposting di PR (status + diff)
3. Reviewer setujui PR              → PR di-merge ke main
4. Merge ke main                    → run "Plan" untuk main, lalu menunggu
5. Engineer klik "Confirm & Apply"  → run "Apply" dieksekusi di remote runner
6. State ter-update + audit log     → seluruh history tersimpan di platform

Setiap run memiliki stages yang bisa dilihat seperti pipeline mini:

#Konfigurasi cloud Block

Bagaimana Terraform tahu bahwa ia harus berjalan di platform, bukan di lokal? Jawabannya adalah blok cloud pada konfigurasi:

terraform {
  cloud {
    organization = "mycompany-infra"
 
    workspaces {
      project = "platform"
      name    = "prod-vpc"
    }
  }
}

Begitu blok ini ada, menjalankan terraform init akan mengubah perilaku Terraform:

• State tidak lagi disimpan lokal — Terraform mengambil state dari workspace prod-vpc di cloud.
• terraform plan dan terraform apply yang dijalankan dari CLI akan men-delegate eksekusi ke remote runner di platform.
• terraform plan bahkan bisa dipicu dari laptop tanpa kredensial cloud sama sekali — hasilnya dikirim balik sebagai log.

$ terraform init
 
Initializing HCP Terraform...
 
Initializing provider plugins...
- Finding latest version of hashicorp/aws...
 
Successfully configured the backend "cloud"! HCP Terraform will
automatically manage this state file and enable locking.

#Policy Enforcement: Jaring Pengaman Terakhir

Salah satu fitur yang paling berharga dari platform managed adalah policy enforcement — penerapan Policy as Code yang akan kita bahas mendalam di episode 16. Bayangkan alurnya:

# (contoh sederhana, bahasa policy disederhanakan)
policy "no_public_s3" {
  source = <<-EOF
    deny[msg] {
      resource := terraform.resources[s3_bucket]
      resource.config.acl == "public-read"
      msg := "S3 bucket tidak boleh public-read"
    }
  EOF
}

Saat sebuah run menghasilkan resource yang melanggar policy, platform akan memblokir apply secara otomatis — sebelum perubahan mencapai cloud. Ini adalah lapisan keamanan yang biasanya paling mahal untuk dibangun sendiri dengan kualitas tinggi, karena policy dievaluasi di setiap run tanpa bisa di-skip oleh engineer.

#Skenario Adopsi Nyata

Supaya tidak abstrak, mari kita lihat satu skenario adopsi yang realistis.

Studi kasus: PT Maju Teknologi, 8 tim, 40 stack Terraform.

1. Kondisi awal. Setiap tim punya repo dan pipeline GitHub Actions sendiri-sendiri. Ada 3 insiden dalam setahun karena developer melakukan apply dari laptop, dan 2 stack rusak karena state bentrok. Tim platform menghabiskan ~30% waktu merawat pipeline, bukan menulis infrastruktur.
2. Keputusan. Setelah mengevaluasi, mereka memilih HCP Terraform karena sudah 100% Terraform (tanpa migrasi sintaks), policy Sentinel bisa di-share antar tim, dan integrasi Vault untuk secrets sudah bawaan.
3. Migrasi. Semua backend "s3" diganti dengan blok cloud (menyisakan hanya beberapa untuk data yang ter-regulasi). 40 stack dimigrasikan ke 40 workspace terorganisir dalam project per tim. Pipeline GitHub Actions dipangkas — yang tersisa hanya bootstrap dan task non-Terraform.
4. Hasil. Tidak ada lagi apply dari laptop (perlu login SSO ke platform). Policy pusat memblokir S3 publik dan resource tanpa tag di semua tim. Audit log terpusat memenuhi kebutuhan compliance. Tim platform beralih dari "merawat pipeline" ke "menulis policy & memperbaiki arsitektur".

#Kapan Harus Pakai Platform Managed? (Kelebihan & Pertimbangan)

Agar keputusan kalian matang, mari rangkum kelebihan dan hal yang perlu dipertimbangkan:

#Kesalahan Umum (Common Pitfalls) Platform Managed

#Penutup

Pada episode 14 ini kita telah membahas bagaimana managed IaC platforms — HCP Terraform, Spacelift, env0, dan Scalr — mengambil alih komponen-komponen yang kita bangun manual di episode 13: remote execution, integrasi VCS, state management terkelola, private module registry, dan policy enforcement. Kita juga melihat bahwa alur VCS-driven di platform ini sebenarnya adalah implementasi siap pakai dari prinsip "tidak ada apply dari laptop" dengan approval gate, yang sebelumnya harus kita susun sendiri dalam workflow YAML.

Poin kunci yang perlu kalian bawa pulang:

• Platform managed adalah lapisan pengelola di atas Terraform, bukan penggantinya.
• Lima fitur utama: remote runner, VCS integration, state managed, private module registry, policy enforcement.
• Blok cloud memindahkan state dan eksekusi ke platform; pahami implikasinya terhadap keamanan data.
• Policy engine (Sentinel/OPA) adalah runtime guard yang melengkapi static scan seperti Checkov.
• Adopsi paling masuk akal saat organisasi punya banyak tim & stack, di mana biaya memelihara pipeline melebihi biaya langganan.

Di episode 15 selanjutnya, kita akan menyelami topik yang selama beberapa episode terakhir terus menyinggung — Secret Management & State Security — membahas mengapa state file menyimpan rahasia dalam plaintext, bagaimana mengamankannya dengan enkripsi & IAM, dan bagaimana mengambil secrets dari HashiCorp Vault, AWS Secrets Manager, atau SOPS dengan sensitive = true. Pastikan tetap semangat!