Belajar Firecracker - Serverless & PaaS di Atas MicroVM

#Pendahuluan

Sejauh ini kita membangun microVM dari dalam: image, snapshot, jaringan, keamanan. Episode 18 melihat keluar — ke produk yang berdiri di atas Firecracker — dan memahami mengapa arsitektur yang kita pelajari membuat produk-produk itu mungkin ada.

Mengapa episode ini penting? Karena Firecracker bukan produk akhir; ia enabler. Setiap produk di episode ini — dari Lambda sampai sandbox AI agent — memakai kombinasi pola yang sudah kalian kuasai: boot cepat, snapshot, isolasi VM-level, dan jailer. Memahami produk di atas Firecracker memberi kalian peta peluang: pola mana yang bisa kalian tiru di platform sendiri, dan di mana Firecracker punya keunggulan dibanding teknologi lain.

#FaaS: AWS Lambda

Pola FaaS adalah bentuk paling murni Firecracker: sebuah fungsi dijalankan saat diminta, dihentikan setelah selesai, dan tidak pernah berbagi kernel dengan fungsi lain.

• Isolasi per fungsi: tiap invokasi (atau kelompok invokasi) mendapat microVM sendiri — bukan namespace container.
• Cold start yang bisa diterima: dengan image ringan + snapshot warm pool (episode 9), fungsi bangun dalam milidetik.
• Scale-to-zero alami: saat tidak ada permintaan, VM mati — tidak ada biaya idle.

Inilah yang membuat angka 15 triliun invokasi Lambda per bulan masuk akal: setiap invokasi hanya membayar microVM sekecil mungkin, selama sesingkat mungkin.

#PaaS: Fargate dan Fly.io

PaaS adalah saudara Fargate yang lebih "berat": platform yang menjalankan aplikasi (bukan fungsi) dengan isolasi kuat dan orkestrasi otomatis.

• AWS Fargate memakai microVM untuk menjalankan task ECS/EKS tanpa kalian mengelola node — tiap task adalah microVM, tiap mesin yang kalian tidak lihat adalah host yang menjalankan Firecracker.
• Fly.io membangun platform aplikasi global di atas microVM: aplikasi di-deploy sebagai image, dijalankan dalam microVM di dekat pengguna, dan dipindahkan antar region dengan snapshot.

Pola yang dipakai: image container → microVM → orkestrasi multi-region. Developer tidak pernah melihat kernel atau hypervisor — mereka melihat platform.

#Sandbox AI Agent: E2B, Daytona, dan Vercel

Generasi terbaru produk di atas Firecracker adalah sandbox untuk AI agent: lingkungan eksekusi tempat kode yang dihasilkan AI dijalankan dengan aman.

• E2B — sandbox yang bisa di-spawn dalam milidetik untuk agent; tiap session AI dapat microVM terisolasi.
• Daytona — dev environment di cloud berbasis microVM.
• Vercel — platform deployment yang memakai isolasi kuat untuk workload user.

Mengapa AI agent membutuhkan microVM? Karena kode yang dieksekusi agent tidak bisa dipercaya: agent bisa salah, menulis kode berbahaya, atau diculik oleh prompt injection. MicroVM memberi batas yang keras: kode itu boleh menghancurkan sandbox-nya sendiri — tidak lebih. Pola "sandbox per user/job" yang kita bahas di episode 12 menjadi arsitektur wajib di kelas produk ini.

#AWS Lambda MicroVMs (Juni 2026)

Di bulan Juni 2026, AWS memperkenalkan Lambda MicroVMs — evolusi Lambda yang memperluas jangkauan workload. Poin-poin teknisnya:

• Isolasi VM-level per user/job — setiap user (atau job) mendapat VM-nya sendiri, bukan berbagi VM dengan user lain. Ini tingkat isolasi yang jauh lebih ketat daripada model multi-tenant sebelumnya.
• Suspend/resume hingga 8 jam — VM bisa dibekukan dan dihidupkan kembali hingga 8 jam kemudian, mempertahankan state dan koneksi. Ini adalah snapshot Firecracker yang dipakai sebagai fitur produk (episode 9).
• Kapasitas hingga 16 vCPU / 32 GB — microVM yang jauh lebih besar dari fungsi Lambda klasik, membuka workload berat: processing besar, job yang lama, aplikasi stateful.
• Build image dari Dockerfile — developer mendeskripsikan image sebagai Dockerfile biasa; platform mengonversinya menjadi rootfs microVM. Inilah tooling image yang kita bahas di episode 8 dan 11 diangkat menjadi pengalaman produk.

Yang bisa kita pelajari dari Lambda MicroVMs:

1. Isolasi per user adalah fitur bisnis — bukan sekadar detail teknis. Menjanjikan "VM kalian sendiri" adalah diferensiasi produk.
2. Snapshot adalah API produk — suspend/resume 8 jam adalah bukti bahwa infrastruktur (snapshot, warm pool) bisa dijual langsung.
3. Dockerfile adalah gerbang — ergonomi container (bukan kernel config) yang membuat microVM bisa diadopsi massal.

#Arsitektur yang Bisa Kalian Tiru

Semua produk di atas bisa disederhanakan menjadi blok yang sudah kalian pelajari:

image_build:    # Dockerfile -> rootfs microVM (episode 8, 11)
  - pull image OCI
  - convert layer -> ext4 rootfs
warm_pool:      # snapshot siap pakai (episode 9)
  - boot base VM
  - init application
  - create Full snapshot
  - pause / hold
on_request:     # jalur kritis (episode 9)
  - restore snapshot
  - configure network + MMDS
  - resume
isolation:      # keamanan (episode 7, 14)
  - jailer per VM
  - cgroup + rate limiter
  - seccomp
lifecycle:      # ops (episode 12, 20)
  - orchestrator create/delete
  - health check + metrics
  - garbage collect snapshots

Blok-blok ini, disusun sesuai kebutuhan produk, adalah apa yang dijalankan tim-tim platform di seluruh dunia — dari startup sandbox AI sampai AWS sendiri.

#Common Pitfalls

• Meniru Lambda tanpa warm pool: cold start per request tanpa snapshot akan terasa mahal; investasi di warm pool dulu.
• Isolasi per user tanpa quota: satu user yang rakus menghabiskan host; pasang cgroup dan rate limiter (episode 10).
• Dockerfile yang hanya untuk container: image yang butuh device atau mount aneh tidak langsung jalan di microVM.
• Melupakan garbage collection: snapshot yang menumpuk memakan disk; hidupkan siklus pembersihan (episode 19).
• Menjual "isolasi VM" tanpa mengujinya: klaim keamanan harus diuji dengan failure injection (episode 16).

#Penutup

Inti yang harus dibawa pulang:

• FaaS (Lambda), PaaS (Fargate, Fly.io), dan sandbox AI (E2B, Daytona, Vercel) semuanya di atas microVM.
• Pola bersama: image immutable + boot/snapshot cepat + isolasi VM-level + orkestrasi.
• Lambda MicroVMs (Jun 2026): isolasi per user/job, suspend/resume 8 jam, 16 vCPU/32 GB, build dari Dockerfile.
• Snapshot adalah fitur produk yang bisa dijual — bukan sekadar tooling internal.
• Arsitektur platform kalian = blok yang sudah dipelajari: build → warm pool → restore → isolasi → lifecycle.

Di episode 19 selanjutnya kita akan menghitung kapasitas: Scaling — Banyak MicroVM per Host — mengejar ribuan microVM per host dengan jailer per VM, cgroup v2, page cache sharing, dan memory overcommit via balloon, plus praktik daemon per microVM, health check, dan garbage collection snapshot.