Belajar Cloud Computing - Infrastructure as Code (IaC) & Cloud Automation

#Pendahuluan

Setelah di episode 15 kita membangun pengawasan penuh atas sistem, kali ini kita menyerang akar masalah yang selama ini menghantui semua infrastruktur yang dibangun manual: ketidakmampuan untuk mereproduksi. Sistem yang tidak bisa dibangun ulang identik bukanlah sistem — ia hanya artefak satu kali yang tidak pernah benar-benar dipahami.

Episode ini membahas mengapa infrastruktur harus ditulis sebagai kode, tool native yang disediakan masing-masing cloud, serta pendekatan multi-cloud agnostik dengan Terraform, OpenTofu, dan Pulumi. Di akhir episode, kalian akan melihat infrastruktur seperti engineer senior melihatnya: sebagai kode yang bisa di-review, diuji, dan di-rollback.

#Pembahasan Utama

#Mengapa IaC: Melawan ClickOps

ClickOps — membangun infrastruktur lewat klik-klik di konsol — terasa cepat dan mudah, tetapi menyimpan empat masalah kronis:

Tidak reproducible — tidak ada dua sesi klik yang persis sama; kalian tidak akan pernah yakin environment staging identik dengan production.
Tidak terdokumentasi — konfigurasi hidup di kepala engineer; saat ia keluar tim, pengetahuan ikut hilang.
Tidak ter-audit — tidak ada jejak siapa mengubah apa dan kapan, sehingga insiden sulit ditelusuri.
Rentan human error — menu konsol berubah tiap rilis, dan satu klik salah bisa menelan biaya besar.

Infrastructure as Code (IaC) menjawab keempatnya dengan memperlakukan infrastruktur seperti kode aplikasi: ditulis dalam file, disimpan di version control, di-review lewat pull request, dan di-deploy secara berulang. Analoginya adalah resep masakan: koki yang hanya menghafal di kepala tidak bisa mewariskan keahliannya, sedangkan resep tertulis bisa menghasilkan rasa yang sama di seratus dapur berbeda.

Masalah ClickOps	Solusi IaC
Konfigurasi tidak bisa diulang	Satu sumber kebenaran dalam file
Tidak terdokumentasi	Git history adalah dokumentasi
Tidak ada jejak perubahan	Pull request dan code review
Rollback mustahil	Rollback dengan checkout commit lama

Ada dua paradigma yang harus kalian bedakan: imperatif menyatakan urutan langkah — buat VPC dulu, lalu subnet, lalu route — sedangkan deklaratif hanya menyatakan kondisi akhir: "saya ingin VPC ini dan subnet itu" — tool yang mengurus langkahnya. Cloud modern berpihak pada deklaratif karena sifatnya idempotent: menjalankan konfigurasi yang sama berulang kali menghasilkan keadaan yang sama, tanpa efek samping.

Note

Ingat korelasi dengan episode 15: sistem yang tidak bisa direproduksi juga tidak bisa dimonitor secara bermakna. IaC bukan hanya tentang kecepatan membuat resource — ia tentang memastikan setiap environment benar-benar sama sehingga observability menghasilkan data yang bisa dibandingkan.

#Tool Native Big 3

Tiap cloud menyediakan tool IaC native, yang paling tepat jika kalian berkomitmen ke satu penyedia:

AWS CloudFormation — menggunakan YAML atau JSON. Sekelompok resource dinyatakan dalam satu template dan dikelola sebagai satu unit bernama stack.
GCP Cloud Deployment Manager — menggunakan YAML, dengan dukungan Python dan Jinja untuk template yang lebih dinamis.
Azure ARM Templates — berbasis JSON; Bicep adalah bahasa deklaratif yang lebih ringkas, yang dikompilasi menjadi ARM template.

Contoh template CloudFormation untuk satu instance web:

template.yaml - EC2 instance sederhana

AWSTemplateFormatVersion: '2010-09-09'
Description: Web server sederhana
 
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0abcdef1234567890
      SecurityGroupIds:
        - sg-0a1b2c3d4e5f67890
      Tags:
        - Key: Name
          Value: web-server-01

File ini bisa di-commit ke git, di-deploy dengan satu perintah, dan dihapus dengan satu perintah pula — seluruh stack, bukan resource satu per satu. Perubahan cukup dilakukan dengan mengedit file lalu meng-deploy ulang; CloudFormation yang menghitung perbedaan antara keadaan sekarang dan yang diinginkan.

Tip

Jangan hafal sintaks — hafalkan konsepnya. CloudFormation, Deployment Manager, dan ARM/Bicep semuanya mengusung pola yang sama: template sebagai sumber kebenaran, deploy untuk menerapkan, dan konsep rollback ketika sesuatu gagal. Keterampilan berpindah antar tool inilah yang membuat kalian bernilai, bukan kemampuan menghafal kata kunci.

#Multi-Cloud Agnostic: Terraform, OpenTofu, dan Pulumi

Banyak tim bekerja lintas cloud atau berpindah antar penyedia. Untuk kebutuhan itu ada tool agnostik yang tidak terikat pada satu cloud:

Terraform — bahasa HCL, tool paling populer di kelasnya. Punya provider resmi untuk AWS, GCP, Azure, dan ribuan lainnya, sehingga satu bahasa untuk semua cloud.
OpenTofu — fork open source Terraform (lisensi MPL) yang kompatibel dengan konfigurasi Terraform, menjadi pilihan bagi organisasi yang menginginkan lisensi open source murni.
Pulumi — menggunakan bahasa pemrograman umum seperti TypeScript, Python, atau Go, cocok untuk tim yang lebih nyaman menulis kode daripada DSL khusus.

Kunci Terraform adalah state file: catatan resource yang sudah dibuat. Setiap kali kalian menjalankan perintah, Terraform membandingkan konfigurasi yang diinginkan dengan state, lalu menyusun rencana perubahan. Workflow dasarnya:

Workflow dasar Terraform

terraform init      # unduh provider yang dibutuhkan
terraform plan      # buat rencana perubahan, tanpa menerapkan
terraform apply     # terapkan rencana ke cloud
terraform destroy   # hapus semua resource yang dikelola

Sebelum menerapkan apa pun, jalankan terraform plan terlebih dahulu. Perintah itu menghasilkan ringkasan berapa resource yang akan ditambah, diubah, dan dihapus — kesempatan terakhir untuk memeriksa sebelum perubahan benar-benar dieksekusi. Kebiasaan kecil ini menyelamatkan production dari penghapusan tidak disengaja.

#Membaca Hasil Plan

Hasil terraform plan berbicara lewat tiga simbol yang harus kalian pahami:

Contoh output terraform plan

Terraform used the selected providers to generate the following execution plan.
 
  # aws_instance.web will be updated in-place
  ~ resource "aws_instance" "web" {
      ~ instance_type = "t3.large" -> "t3.medium"
        tags          = { "Name" = "web-server-01" }
    }
 
  # aws_security_group.allow_https will be created
  + resource "aws_security_group" "allow_https" {
      + name        = "allow-https"
      + description = "Allow inbound HTTPS"
    }
 
Plan: 1 to add, 1 to change, 0 to destroy.

Simbol + berarti resource baru yang akan dibuat.
Simbol ~ berarti resource yang sudah ada dan akan diubah.
Simbol - berarti resource yang akan dihapus.

Baris terakhir merangkum semuanya. Sebelum menekan apply, kalian cukup menanyakan satu hal: apakah perubahan yang akan dihapus atau diubah memang benar-benar yang kalian maksud? Pertanyaan sederhana ini menyelamatkan production lebih sering daripada yang kalian kira.

#Pola Otomasi Lanjutan

IaC membuka jalan untuk pola yang lebih besar:

CI/CD untuk infrastruktur — pipeline di GitHub Actions atau GitLab CI yang menjalankan terraform plan pada setiap pull request, lalu terraform apply setelah disetujui dan di-merge.
Enforcement — meletakkan aturan (misalnya ukuran instance minimal, atau larangan port terbuka) di dalam pipeline sehingga penyimpangan ditolak sebelum sampai ke cloud.
State terpusat — menyimpan state di remote backend (S3, GCS, Azure Storage) dengan locking, agar tim bisa bekerja bersama tanpa bentrok.

Important

State file berisi pemetaan lengkap infrastruktur kalian — ia adalah aset kritis yang tidak boleh hilang dan harus dibatasi aksesnya. Simpan di remote backend dengan versioning, kunci akses dengan IAM, dan aktifkan locking supaya dua orang tidak menimpa perubahan satu sama lain. State yang rusak membuat IaC kehilangan seluruh kemampuannya untuk memperbaiki diri.

#Penutup

Pada episode 16 ini kalian telah mempelajari fondasi infrastruktur modern: alasan IaC — melawan ClickOps demi sistem yang reproducible, terdokumentasi, dan bisa diaudit; paradigma deklaratif dan idempotent; tool native — CloudFormation, Deployment Manager, dan ARM/Bicep untuk tim single-cloud; serta tool agnostik — Terraform, OpenTofu, dan Pulumi untuk tim multi-cloud. Kalian juga mengenal workflow plan sebelum apply dan pola otomasi lanjutan seperti CI/CD infrastruktur serta state terpusat.

Namun otomasi yang membuat pembuatan resource semudah bernapas punya sisi gelap: biaya. Kemudahan yang sama bisa membuat tagihan membengkak dalam semalam — environment yang lupa dimatikan, instance yang terlalu besar, dan storage yang tidak pernah diarsipkan. Episode berikutnya, FinOps, Cost Management & Cloud Optimization, mengajarkan kalian mengendalikan sisi yang satu ini — karena cloud yang hemat biaya sama pentingnya dengan cloud yang otomatis.