Dari Mana Infrastruktur Berasal

Ketika sebuah tim mulai membangun aplikasi, pertanyaan pertama hampir selalu tentang kode: bahasa apa yang digunakan, bagaimana menyusun direktori, bagaimana menjalankannya di mesin lokal. Pertanyaan tentang infrastruktur biasanya datang belakangan, terkadang hanya ketika aplikasi perlu berjalan di tempat yang bisa diakses orang lain.

Di sinilah segalanya menjadi menarik. Infrastruktur tidak muncul dengan sendirinya. Server, database, jaringan, load balancer — semuanya perlu dibuat, dikonfigurasi, dan dihubungkan. Pendekatan paling sederhana adalah melakukannya secara manual: masuk ke dashboard cloud, klik tombol untuk membuat server, pilih spesifikasinya, tunggu hingga siap. Cara itu berfungsi baik untuk satu server. Tapi mulai bermasalah ketika Anda memiliki banyak server, ketika Anda membutuhkan lingkungan staging dan production, atau ketika sesuatu rusak dan Anda harus membangun ulang semuanya dari awal.

Masalahnya bukan hanya soal waktu. Ketika infrastruktur dibuat secara manual, tidak ada catatan yang dapat diandalkan tentang apa yang sebenarnya dibangun. Developer A mungkin membuat server dengan spesifikasi tertentu, sementara Developer B membuat server lain dengan pengaturan yang sedikit berbeda — mungkin karena lupa, mungkin karena antarmuka dashboard cloud berubah. Perbedaan kecil ini dapat menyebabkan bug yang sulit dilacak: aplikasi berjalan baik di staging tetapi gagal di production, meskipun kodenya identik.

Infrastruktur manual juga sulit untuk direproduksi. Jika tim membutuhkan lingkungan baru — misalnya, untuk pengujian QA atau demo klien — seluruh proses harus diulang dari awal. Setiap kali, ada risiko melewatkan satu langkah atau salah mengonfigurasi parameter. Semakin besar infrastruktur tumbuh, semakin lebar celah antara apa yang Anda maksudkan dan apa yang sebenarnya tercipta.

Memperlakukan Infrastruktur Seperti Kode

Pendekatan yang lebih baik adalah memperlakukan infrastruktur dengan cara yang sama seperti Anda memperlakukan kode aplikasi. Tulis dalam file teks yang bisa dibaca manusia, simpan file-file tersebut di repositori, dan kelola dengan proses yang sama seperti yang Anda gunakan untuk kode biasa. File-file ini mendefinisikan apa yang disebut desired state — kondisi ideal yang Anda inginkan untuk infrastruktur Anda, lengkap dengan spesifikasi server, ukuran disk, aturan firewall, dan koneksi database.

Dengan pendekatan ini, tidak ada yang harus mengingat langkah-langkah manual atau mengandalkan ingatan seseorang. Setiap definisi infrastruktur hidup dalam file yang dapat dilihat, ditinjau, dan diubah oleh siapa pun di tim. Perubahan pada infrastruktur melalui pipeline yang sama seperti perubahan kode: ditulis, ditinjau oleh rekan tim, dan diterapkan setelah disetujui.

Berikut adalah contoh definisi infrastruktur sederhana di Terraform:

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServer"
  }
}

Konsep ini disebut infrastructure as code, atau IaC. Idenya sederhana: infrastruktur bukanlah sesuatu yang Anda konfigurasi sekali lalu lupakan. Infrastruktur adalah sesuatu yang Anda definisikan, versikan, dan kelola sepanjang umur aplikasi Anda. Dengan cara ini, Anda dapat yakin bahwa lingkungan staging dan production identik, bahwa setiap perubahan dapat dilacak, dan bahwa Anda dapat membuat lingkungan baru kapan saja tanpa khawatir melewatkan langkah.

Mengapa Infrastruktur Manual Gagal dalam Skala Besar

Mari kita buat ini lebih konkret. Bayangkan tim Anda mengelola sepuluh server secara manual. Suatu hari, sebuah server crash. Anda perlu menggantinya. Anda login ke dashboard, buat server baru, dan mencoba mengingat pengaturan apa yang dimiliki server lama. Apakah tipe instancenya sama? Apakah aturan security group-nya sama? Apakah ukuran disk-nya sama? Anda mungkin berhasil, atau mungkin tidak. Dan bahkan jika berhasil, tidak ada cara untuk membuktikannya.

Sekarang bayangkan Anda perlu membuat lingkungan yang benar-benar baru — misalnya, untuk tim pengujian performa. Anda harus mengulangi setiap langkah manual dari awal. Jika infrastruktur Anda telah berkembang hingga mencakup database, load balancer, caching layer, dan message queue, proses manual menjadi daftar periksa yang memakan waktu berjam-jam dan rentan terhadap kesalahan manusia di setiap langkah.

Biaya sebenarnya bukanlah waktu yang dihabiskan untuk mengklik tombol. Melainkan ketidakpastian. Ketika sesuatu salah di production, Anda tidak bisa dengan cepat menjawab pertanyaan seperti: "Apa yang berubah di infrastruktur?" atau "Apakah lingkungan ini dikonfigurasi persis seperti staging?" Tanpa infrastructure as code, pertanyaan-pertanyaan itu sulit dijawab dengan percaya diri.

Workflow Terraform Dimulai di Sini

Di sinilah workflow Terraform dimulai. Sebelum menjalankan perintah apa pun, tim menulis definisi infrastruktur dalam file konfigurasi. File-file ini menjadi sumber kebenaran — bukan dashboard cloud, bukan catatan pribadi, bukan ingatan seseorang.

Workflow-nya mengikuti siklus sederhana:

  1. Write — Definisikan infrastruktur Anda dalam file konfigurasi. Deskripsikan server, jaringan, database, dan sumber daya lain yang Anda butuhkan.

  2. Plan — Minta Terraform untuk menunjukkan apa yang akan berubah sebelum Anda menerapkannya. Ini memberi Anda kesempatan untuk meninjau dan menangkap kesalahan.

  3. Apply — Jalankan perubahan. Terraform membandingkan konfigurasi Anda dengan keadaan infrastruktur saat ini dan hanya membuat perubahan yang diperlukan untuk mencapai desired state.

Siklus ini mencerminkan cara Anda bekerja dengan kode aplikasi. Anda menulis kode, meninjaunya, lalu men-deploy-nya. Perbedaannya adalah bahwa alih-alih men-deploy logika aplikasi, Anda men-deploy definisi infrastruktur. Dan seperti kode aplikasi, definisi-definisi ini hidup di version control, melalui code review, dan diuji sebelum mencapai production.

Apa yang Diubah oleh Infrastructure as Code

Ketika Anda mengadopsi infrastructure as code, beberapa hal berubah dalam cara tim Anda beroperasi:

Auditabilitas menjadi otomatis. Setiap perubahan pada infrastruktur tercatat di riwayat version control Anda. Anda dapat melihat siapa yang mengubah apa, kapan, dan mengapa. Jika masalah production muncul, Anda dapat memeriksa apakah perubahan infrastruktur bertepatan dengan masalah tersebut.

Konsistensi menjadi dapat dicapai. File konfigurasi yang sama dapat membuat lingkungan yang identik untuk development, staging, dan production. Perbedaan antar lingkungan menjadi disengaja dan terdokumentasi, bukan tidak sengaja.

Pemulihan menjadi dapat diulang. Jika sebuah lingkungan rusak atau perlu dibangun ulang, Anda tidak perlu mengingat langkah-langkah manual. Anda menjalankan file konfigurasi yang sama, dan infrastruktur dibuat ulang persis seperti yang didefinisikan.

Kolaborasi menjadi mungkin. Definisi infrastruktur dapat ditinjau seperti kode. Anggota tim junior dapat belajar dengan membaca konfigurasi yang ada. Anggota tim senior dapat menangkap kesalahan sebelum mencapai production.

Titik Awal yang Praktis

Jika Anda baru mengenal infrastructure as code, berikut adalah daftar periksa sederhana untuk memulai:

  • Pilih satu bagian kecil dari infrastruktur yang saat ini Anda kelola secara manual — mungkin satu server atau satu instance database.
  • Tulis konfigurasinya di Terraform atau alat IaC pilihan Anda.
  • Jalankan plan untuk melihat apa yang akan diubah oleh Terraform.
  • Terapkan konfigurasi dan verifikasi bahwa hasilnya sesuai dengan yang Anda harapkan.
  • Commit file konfigurasi ke repositori Anda.
  • Hapus resource manual dan buat ulang hanya menggunakan file konfigurasi Anda.

Latihan ini membuktikan kepada diri sendiri dan tim Anda bahwa pendekatan ini berhasil. Setelah Anda melakukannya sekali, Anda akan mulai melihat bagian lain dari infrastruktur Anda yang harus dikelola dengan cara yang sama.

Kesimpulan

Infrastruktur tidak muncul secara ajaib, dan tidak boleh dikelola dengan ingatan. Menulis infrastruktur sebagai kode mengubah proses manual yang rawan kesalahan menjadi workflow yang dapat diulang, ditinjau, dan diaudit. Workflow Terraform — write, plan, apply — hanyalah implementasi praktis dari ide ini. Sebelum Anda menjalankan perintah apa pun, mulailah dengan mendefinisikan apa yang Anda inginkan. Definisi itu, yang disimpan di version control, menjadi satu-satunya sumber kebenaran untuk infrastruktur Anda. Segala sesuatu lainnya mengikuti dari sana.