Belajar Firecracker - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Di episode 0 kita menyiapkan host, binary, dan image microVM. Kali ini kita berhenti sejenak dari terminal dan bertanya pertanyaan yang lebih mendasar: mengapa Firecracker ada? Apa masalah nyata yang membuat AWS rela menulis VMM dari nol, dan mengapa teknologi ini sekarang menggerakkan layanan serverless terbesar di dunia?

Memahami sejarah bukan sekadar trivia. Pilihan desain Firecracker — Rust, satu proses satu VM, API minimal, jailer — semuanya adalah jawaban atas masalah spesifik yang dialami AWS pada masanya. Jika kalian paham masalahnya, semua keputusan teknis di episode berikutnya akan terlihat masuk akal dengan sendirinya. Inilah episode yang membedakan operator yang sekadar menjalankan perintah dari engineer yang memahami sistem.

#Asal Usul: Dari EC2 ke Lambda

Cerita Firecracker dimulai dari kenyataan pahit di AWS Lambda. Lambda pada awalnya adalah layanan serverless yang menjalankan fungsi dalam wadah dengan isolasi berbasis VM multi-tenant — banyak fungsi pelanggan berbagi satu VM yang sama, dengan kernel yang sama. Pendekatan ini efisien, tapi menyisakan masalah fundamental: isolasi yang lemah antar pelanggan.

Jika satu fungsi pelanggan berhasil menembus isolasi proses dan namespace, kernel host akan terkompromi — dan semua fungsi lain di VM yang sama ikut terekspos. Untuk layanan yang dipakai oleh perusahaan perbankan dan kesehatan, model risiko seperti ini tidak bisa ditoleransi. AWS membutuhkan isolasi setara hardware untuk setiap workload, seperti EC2, tapi dengan biaya dan kecepatan seperti container.

Inilah paradoks yang memicu kelahiran Firecracker: isolasi EC2 yang mahal, kecepatan container yang murah. Solusinya tidak ada di pasaran — QEMU terlalu berat, dan container tidak cukup aman.

#Dari crosvm ke Firecracker

Jawaban AWS adalah membangun VMM baru. Tim AWS melihat bahwa Chromium OS, lewat proyek crosvm, sudah membangun VMM berbasis Rust yang berfokus pada keamanan dan kesederhanaan. crosvm membuktikan bahwa VMM bisa ditulis dengan bahasa yang aman dari segi memori — dan keamanan memori adalah persis masalah yang harus dipecahkan untuk isolasi multi-tenant.

Firecracker lahir sebagai fork dari crosvm, lalu diarahkan ulang secara agresif menuju satu tujuan: minimalisme untuk serverless. Fitur-fitur yang tidak dibutuhkan untuk workload fungsi — VGA, audio, GUI, USB — dibuang. Yang tersisa hanya yang esensial: boot kernel, block device, network, dan seperangkat virtio device yang dikurasi ketat.

Dua keputusan ini — memilih Rust dan berawal dari crosvm — adalah fondasi filosofis Firecracker:

• Rust: menjamin tidak ada bug keamanan memori (use-after-free, buffer overflow) di kode VMM. Bug semacam inilah yang selama bertahun-tahun menjadi sumber utama escape dari hypervisor.
• Minimalisme: semakin sedikit kode, semakin kecil attack surface, semakin cepat boot, dan semakin sedikit resource yang dipakai.

#Open Source dan Angka yang Mengubah Dunia

Firecracker diumumkan dan dirilis sebagai open source dengan lisensi Apache 2.0 pada akhir tahun 2018. Keputusan open source ini penting: komunitas di luar AWS — dari startup serverless, provider PaaS, hingga tim platform internal — bisa memakai dan mengembangkan teknologi yang sama dengan AWS. Sejak itu ekosistemnya tumbuh: firecracker-containerd, Flintlock, kata-containers, hingga berbagai implementasi sandbox AI agent.

Angka-angka yang menyertai Firecracker bukan hiperbola marketing:

• ~125 ms waktu boot microVM dari nol.
• < 5 MiB overhead memori per microVM (di atas memori guest).
• 15 triliun invokasi Lambda per bulan berjalan di atas Firecracker.

Bandingkan dengan QEMU tradisional: boot beberapa detik dan overhead ratusan MiB. Perbedaan orde magnitudo inilah yang memungkinkan Lambda beroperasi dengan skala dan biaya yang kita kenal sekarang — dan yang memungkinkan pola scale-to-zero di mana VM bisa dimatikan total saat tidak dipakai lalu dihidupkan kembali dalam milidetik.

#Mengapa Firecracker? Empat Jawaban

Setelah memahami sejarah, mari rumuskan mengapa Firecracker dipilih untuk membangun platform serverless:

1. Boot cepat (~125 ms) — cold start menjadi hampir tak terasa. Untuk FaaS, waktu tunggu boot adalah biaya langsung yang dirasakan pengguna.
2. Overhead kecil (< 5 MiB) — ribuan microVM bisa hidup dalam satu host tanpa boros memori. Ini memungkinkan densitas tinggi dan biaya per workload rendah.
3. Isolasi hardware via KVM — setiap workload berjalan dengan isolasi setara EC2, bukan sekadar namespace. Multi-tenant jadi aman meski workload-nya untrusted.
4. Attack surface minimal — API tunggal yang dikurasi, device terbatas, dan seccomp default. Lebih sedikit fitur berarti lebih sedikit cara untuk menembus.

Empat pilar ini adalah alasan yang sama yang dipakai E2B, Fly.io, Daytona, dan provider serverless lain saat memilih Firecracker untuk sandbox mereka. Semuanya butuh hal yang sama: isolasi kuat dengan biaya startup yang hampir nol.

#Konteks Lebih Luas: Posisi Firecracker di Ekosistem

Untuk memahami posisi Firecracker, kita perlu membedakannya dari teknologi yang sering disamakan dengannya:

• QEMU: VM tradisional, kaya fitur, mahal. Firecracker membuang fitur demi kecepatan dan keamanan.
• Container (Docker): berbagi kernel host, ringan tapi isolasinya lemah. Firecracker mengisolasi di level hardware.
• Kata Containers: membungkus microVM sebagai runtime OCI — Firecracker adalah salah satu VMM yang bisa dipakai di baliknya.
• Cloud Hypervisor: VMM Rust yang lebih kaya fitur (hotplug, dukungan cloud penuh). Firecracker tetap minimalis untuk serverless.

Kesimpulannya: Firecracker mengisi ceruk spesifik — workload ephemeral yang harus boot cepat, padat, dan terisolasi kuat. Bukan untuk menggantikan QEMU di semua tempat, tapi untuk membuka kategori sistem yang sebelumnya mustahil dibangun dengan biaya yang masuk akal.

#Penutup

Inti yang harus dibawa pulang:

• Firecracker lahir dari masalah isolasi multi-tenant Lambda yang tidak bisa diselesaikan container.
• Akarnya di crosvm Chromium OS; AWS menulisnya dalam Rust untuk keamanan memori.
• Minimalisme adalah strategi: buang fitur, kurangi attack surface, percepat boot.
• Boot ~125 ms dan overhead < 5 MiB adalah angka yang mengubah ekonomi serverless.
• Open source (Apache 2.0, 2018) menjadikannya fondasi seluruh ekosistem microVM.
• 15 triliun invokasi Lambda per bulan berjalan di atas Firecracker.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Firecracker — satu proses untuk satu microVM, perbandingan VMM Rust melawan QEMU, keluarga device virtio (net, block, vsock, balloon, entropy), rate limiter, jailer, dan metadata service MMDS. Setelah episode ini, kalian akan melihat dengan mata kepala sendiri bagaimana desain yang lahir dari masalah nyata diterjemahkan menjadi kode.