Belajar Terraform - Sejarah, Konsep IaC & Mengapa Memilih Terraform

#Pendahuluan

Di episode 0 sebelumnya, kita sudah menyiapkan fondasi: menguasai skill dasar Linux CLI, konsep cloud computing, format data terstruktur, serta menginstall Terraform CLI dan menyiapkan cloud credentials. Nah, di episode 1 kali ini, kita akan mundur sejenak dari keyboard dan membahas mengapa Terraform ada di dunia ini — karena sebelum memahami cara kerja sebuah alat, kita harus paham dulu masalah apa yang ia pecahkan.

Mengapa memahami sejarah dan konsep ini penting? Karena tools otomasi bermunculan setiap tahun, dan keputusan memilih tool yang tepat tidak bisa diambil hanya dari sekadar "tool ini populer". Kalian harus paham apa itu paradigma declarative vs imperative, apa itu Infrastructure as Code (IaC), dan mengapa sebuah ekosistem tool bisa menjadi standar industri selama bertahun-tahun. Dengan pemahaman ini, kalian bukan hanya bisa memakai Terraform, tapi juga bisa berargumen secara teknis kapan harus memakai Terraform, kapan harus memakai Ansible, dan kapan cukup pakai shell script.

Di episode ini kita akan membahas tiga hal: pertama, perjalanan evolusi pengelolaan infrastruktur TI dari manual hingga IaC; kedua, perbandingan paradigma declarative, imperative, dan code-based; ketiga, alasan kuat mengapa Terraform (dan fork open-source-nya, OpenTofu) menjadi pilihan utama dunia modern.

#Evolusi Pengelolaan Infrastruktur TI

Untuk memahami IaC, kita harus tahu bagaimana cara manusia mengelola server sebelum IaC ada. Bayangkan perjalanan ini sebagai tiga era, di mana setiap era lahir sebagai solusi atas rasa sakit di era sebelumnya.

#Era 1: Manual Provisioning (ClickOps)

Pada era awal cloud, membuat infrastruktur berarti membuka GUI Console di browser (misalnya AWS Management Console), lalu mengeklik menu demi menu: klik "Launch Instance", pilih AMI, pilih instance type, konfigurasi security group, lalu klik "Launch" — dan mengulangi proses yang sama untuk setiap server. Cara ini populer disebut ClickOps.

Bayangkan kalian harus membuat 10 server web, 3 database, 2 load balancer, dan 1 VPC dengan cara klik-klik. Berapa kali kalian harus berpindah tab, menunggu halaman dimuat, dan memastikan tidak ada satu klik pun yang terlewat? Itu baru satu environment. Sekarang bayangkan harus membuat tiga environment identik (dev, staging, production) — total sekitar 45 komponen yang diklik manual satu per satu.

Masalah ClickOps bisa dirangkum sebagai berikut:

• Tidak reproducible — tidak ada dua klik yang menghasilkan infrastruktur identik.
• Tidak terdokumentasi — perubahan yang dilakukan tidak meninggalkan jejak audit yang bisa ditelusuri.
• Human error — semuanya bergantung pada ketelitian manusia di saat lelah.
• Tidak scalable — membangun 100 server dengan klik = resep untuk insomnia.
• Drift tak terkendali — tidak ada cara untuk membuktikan "apa yang saya deploy vs apa yang seharusnya ada".

#Era 2: Shell Scripting (Imperative)

Sebagai solusi, para engineer mulai menulis shell script untuk mengotomatiskan proses provisioning. Alih-alih mengklik, mereka menjalankan script yang memanggil CLI cloud (aws ec2 run-instances, gcloud compute instances create, dsb).

#!/bin/bash
set -euo pipefail
 
for i in 1 2 3; do
  aws ec2 run-instances \
    --image-id ami-0c55b159cbfafe1f0 \
    --instance-type t3.micro \
    --subnet-id subnet-12345678 \
    --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=web-0$i}]"
done
 
aws ec2 create-tags \
  --resources i-0abcd... \
  --tags Key=Environment,Value=staging

Pendekatan ini adalah imperative: kita menuliskan langkah demi langkah bagaimana cara mencapai kondisi akhir. Script ini jelas lebih baik daripada klik-klik — bisa diulang, bisa diputar di CI. Tapi era ini membawa masalah barunya sendiri:

• Fragile — satu perubahan struktur command di CLI cloud akan membuat seluruh script patah.
• Tidak idempotent — menjalankan script dua kali sering menghasilkan error (misalnya "instance sudah ada") atau resource dobel.
• Berantakan & tidak ekspresif — script panjang penuh dengan logika if, for, dan error handling yang membuat esensi "apa yang ingin dibangun" hilang.
• Sulit dibaca — 500 baris bash untuk membuat 3 server bukanlah cara terbaik menyampaikan niat.

Kata kunci penting di sini: imperative menjelaskan cara (how), bukan tujuan (what). Inilah kelemahan fundamental yang menjadi kelahiran era berikutnya.

#Era 3: Declarative Infrastructure as Code

Di era ketiga, lahirlah Infrastructure as Code (IaC) — ide radikal bahwa infrastruktur harus didefinisikan sebagai kode yang menggambarkan kondisi akhir yang diinginkan (desired state), bukan urutan langkah untuk mencapai kondisi itu. Engineer menulis "ini yang saya mau", dan tool-nya yang memikirkan "bagaimana mewujudkannya".

resource "aws_instance" "web" {
  for_each = toset(["01", "02", "03"])
 
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.app.id
 
  tags = {
    Name        = "web-${each.key}"
    Environment = "staging"
  }
}
 
resource "aws_subnet" "app" {
  cidr_block = "10.0.1.0/24"
  vpc_id     = aws_vpc.main.id
}

Perhatikan perbedaannya. Script bash di atas adalah "lakukan ini, lalu ini, lalu itu". Kode Terraform di atas adalah "saya ingin ada 3 instance dengan spesifikasi begini di subnet ini". Terraform akan membandingkan kondisi ini dengan kondisi aktual di cloud, lalu menentukan sendiri langkah-langkah yang dibutuhkan. Inilah esensi declarative: kita mendeklarasikan hasil akhir, tool yang mengeksekusi.

Era IaC membawa perubahan besar:

• Reproducible — kode yang sama menghasilkan infrastruktur yang sama, di mana saja.
• Versionable — kode bisa di-commit ke Git, di-review, di-revert, dan di-audit.
• Testable — bisa divalidasi, di-lint, dan di-scan keamanannya sebelum dieksekusi.
• Idempotent — menjalankan kode yang sama dua kali menghasilkan kondisi yang sama, tanpa error.
• Collaborative — seluruh tim bekerja dari satu sumber kebenaran, bukan ingatan masing-masing.

#Perbandingan Paradigma IaC

Sekarang, penting untuk disadari: IaC bukan satu pendekatan tunggal. Ada beberapa paradigma yang hidup berdampingan di dunia nyata, dan masing-masing punya kekuatan serta kelemahannya sendiri. Mari kita bedah tiga paradigma utama:

#Declarative (Terraform, OpenTofu, CloudFormation)

Seperti yang sudah dibahas, paradigma ini fokus pada desired state. Kalian menulis "apa yang ingin saya miliki", tool yang menangani "bagaimana cara mendapatkannya". Terraform, OpenTofu, dan AWS CloudFormation adalah contohnya.

#Imperative (Ansible, Puppet, Chef)

Paradigma imperative dalam configuration management tetap menulis langkah-langkah eksekusi, namun diorganisir dalam modul/task yang bisa diulang dan terstruktur. Ansible misalnya menulis "install package ini, salin file ini, restart service ini" — namun karena Ansible modul-modulnya idempotent, ia disebut intent-based dalam praktiknya. Perbedaan mendasarnya dengan Terraform: Ansible biasanya bekerja pada server yang sudah ada (mengkonfigurasi di dalam mesin), sedangkan Terraform fokus pada menciptakan dan mengelola infrastruktur (network, storage, instance) yang menjadi container dari server-server tersebut.

#Code-based (Pulumi, AWS CDK)

Paradigma ketiga menggunakan bahasa pemrograman umum (TypeScript, Python, Go, C#) untuk mendefinisikan infrastruktur. Ini memberi kekuatan bahasa penuh — loop, function, class, unit test — namun dengan biaya: kalian memegang kendali dan tanggung jawab logika sendiri.

#Mengapa Harus Terraform / OpenTofu?

Setelah memahami perjalanan evolusi dan paradigma, pertanyaan besarnya: dari sekian banyak tool IaC, mengapa Terraform yang menjadi standar de-facto? Berikut alasan-alasannya.

#Cloud Agnostic dengan Satu Bahasa

Ini adalah pembeda terbesar Terraform sejak lahir di tahun 2014 (ditulis oleh HashiCorp, dibuat oleh Mitchell Hashimoto). Sebelum Terraform, masing-masing cloud punya bahasa sendiri: CloudFormation khusus AWS, Deployment Manager khusus GCP, ARM template khusus Azure. Terraform menghadirkan satu bahasa (HCL) untuk semua cloud.

Terdapat lebih dari ribuan provider resmi dan komunitas yang terdaftar di Terraform Registry: AWS, Google Cloud, Azure, Kubernetes, Docker, Cloudflare, GitHub, Datadog, hingga provider niche seperti Linear atau Railway. Artinya, ketika perusahaan memakai multi-cloud atau hybrid, seluruh tim cukup belajar satu bahasa untuk mengelola semuanya.

# AWS
resource "aws_instance" "aws_web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}
 
# GCP
resource "google_compute_instance" "gcp_web" {
  name         = "gcp-web"
  machine_type = "e2-micro"
  zone         = "asia-southeast1-a"
}
 
# Cloudflare (bukan cloud tradisional, tapi satu bahasa juga!)
resource "cloudflare_record" "web" {
  name  = "www"
  type  = "A"
  value = aws_instance.aws_web.public_ip
}

#Ekosistem Provider & Module Registry Raksasa

Kekuatan Terraform bukan hanya bahasa, tapi juga ekosistemnya. Dua hal yang membuatnya luar biasa:

1. Provider Registry — ribuan provider resmi dan komunitas. Kalian tidak perlu menulis API client sendiri untuk berinteraksi dengan cloud; cukup deklarasikan required_providers dan Terraform mengunduh serta mengelola versinya.
2. Module Registry — kumpulan modul siap pakai (bundel resource yang diorganisir dengan baik). Alih-alih menulis 200 baris HCL untuk VPC, kalian bisa memanggil modul VPC teruji dari registry dan mengisinya dengan variabel.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"
 
  name = "production-vpc"
  cidr = "10.0.0.0/16"
 
  azs             = ["ap-southeast-1a", "ap-southeast-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
 
  enable_nat_gateway = true
}

Bayangkan kode VPC production-grade (dengan NAT gateway, route tables, dan Internet Gateway) yang biasanya ratusan baris — bisa di-replace dengan pemanggilan modul 15 baris. Inilah kekuatan Don't Repeat Yourself (DRY) yang akan kita dalami di episode 9 nanti.

#Manajemen State & Dependency Graph Otomatis

Dua fitur teknis ini yang membuat Terraform benar-benar "tahu" kondisi infrastruktur kalian:

1. State File (terraform.tfstate). Terraform menyimpan peta antara kode HCL dan resource nyata di cloud dalam sebuah file state. Inilah "memori" Terraform. Saat kalian menjalankan terraform plan, Terraform membandingkan kode vs state vs kondisi aktual di cloud, lalu memutuskan apa yang perlu dibuat, diubah, atau dihapus. Tanpa state, Terraform tidak akan tahu bahwa aws_instance.web sebenarnya sudah ada sebagai i-0abcd1234 di AWS.

2. Dependency Graph. Saat kalian menulis kode yang saling merujuk — misalnya instance yang memakai subnet, subnet yang memakai VPC — Terraform otomatis membangun directed acyclic graph (DAG) dari semua resource dan mengeksekusinya dalam urutan yang benar. Resource yang tidak saling bergantung dieksekusi paralel untuk kecepatan. Ini menghilangkan beban manual menentukan urutan yang menjadi mimpi buruk di shell scripting.

#OpenTofu: Fork Open-Source

Cerita Terraform tidak lepas dari keputusan HashiCorp di Agustus 2023 untuk mengubah lisensi Terraform dari MPL 2.0 (open-source) menjadi Business Source License (BSL) — lisensi yang membatasi penggunaan komersial. Sebagai respons, komunitas membentuk OpenTofu di bawah naungan Linux Foundation, sebuah fork yang melanjutkan Terraform dalam lisensi open-source penuh (MPL 2.0).

Poin penting yang perlu kalian tahu:

• Sintaks dan workflow identik — kode Terraform berjalan apa adanya di OpenTofu. tofu init, tofu plan, tofu apply, tofu destroy — pola yang sama persis.
• Fitur tetap berkembang — OpenTofu terus menambahkan fitur (misalnya client-side state encryption) secara mandiri.
• Pilihan bukan persaingan — di series ini kita fokus ke Terraform, tapi ilmu yang kalian dapat 100% berlaku untuk OpenTofu. Banyak perusahaan saat ini memilih OpenTofu demi lisensi open-source penuh, jadi mengenal keduanya adalah keunggulan.

#Penutup

Di episode 1 ini kita sudah menempuh perjalanan panjang: memahami evolusi pengelolaan infrastruktur dari ClickOps manual yang tidak konsisten, ke shell scripting imperative yang rapuh, hingga lahirnya declarative Infrastructure as Code yang reproducible dan idempotent. Kita juga sudah membandingkan tiga paradigma IaC — declarative, imperative, dan code-based — serta memahami posisi unik Terraform di antaranya.

Poin penting yang harus kalian bawa:

• ClickOps tidak konsisten, tidak terdokumentasi, dan tidak scalable.
• Shell scripting (imperative) lebih baik, tapi fragile dan tidak idempotent.
• Declarative IaC mendeklarasikan hasil akhir, tool yang mengeksekusi.
• Terraform unggul karena cloud agnostic (satu bahasa untuk semua cloud), ekosistem provider & module raksasa, serta state management + dependency graph otomatis.
• OpenTofu adalah fork open-source Terraform dengan sintaks yang 100% kompatibel.

Sekarang konsep sudah matang, saatnya mulai menyentuh kode sungguhan. Di episode 2 selanjutnya, kita akan membahas anatomi sintaks HCL dan core workflow Terraform — mengenal struktur block, argument, dan identifier, lalu mempraktikkan empat langkah workflow utama: terraform init, plan, apply, dan destroy. Pastikan Terraform CLI kalian sudah terinstall dan siap, karena di episode 2 kita akan mulai menulis konfigurasi pertama dan menjalankannya! Pastikan tetap semangat, karena dari sini perjalanan mulai memasuki bagian paling seru.