Netlify Ganti V8 Isolate dengan Firecracker MicroVM: Edge Functions 5x Lebih Cepat

Netlify mempublikasikan tulisan teknis pada September 2026 yang menjelaskan bagaimana mereka membangun ulang infrastruktur Edge Functions. Selama ini permintaan ke Edge Functions dikirim keluar ke layanan eksekusi terpisah. Sekarang semuanya berjalan di MicroVM Firecracker di dalam jaringan edge mereka sendiri, dan hasilnya sekitar lima kali lebih cepat pada nilai median.

Konteksnya penting karena skala yang dihadapi tidak kecil. Netlify menyebut sekitar satu miliar Edge Function berjalan di platform mereka setiap hari, mulai dari personalisasi halaman sampai routing berbasis cookie. Untuk menjalankan puluhan hingga ratusan ribu fungsi per detik, seluruh proses mulai dari menerima permintaan, merutekan, mengalokasikan kapasitas komputasi, sampai menjalankan kode pelanggan harus selesai dalam hitungan milidetik.

Yang membuat migrasi ini layak dibaca bukan hanya angka kecepatannya, tetapi pilihan arsitekturnya. Netlify meninggalkan V8 isolate, model yang selama bertahun-tahun jadi standar industri untuk menjalankan kode di edge, dan menggantinya dengan MicroVM. Alasan utamanya adalah isolasi.

Angka Sebelum dan Sesudah

Perbandingan yang paling jelas ada pada invokasi hangat, yaitu kondisi ketika fungsi sudah pernah dijalankan di node yang sama. Proses lengkapnya, mulai dari routing ke node komputasi, masuk ke MicroVM, menjalankan fungsi, sampai menghasilkan header respons, kini memakan waktu 5 sampai 6 milidetik pada median. Sebelumnya, angka yang sama berada di kisaran 25 sampai 40 milidetik.

Angka lain yang dilaporkan:

• Invokasi p99 menjadi 47,4 persen lebih cepat.
• Ketersediaan tercatat 99,998 persen.
• Pengiriman log Edge Function menjadi lima kali lebih cepat.

Invokasi dingin juga dijelaskan secara terbuka. Kondisi ini terjadi ketika permintaan masuk ke region yang belum pernah melihat fungsi tersebut, sehingga node harus mengambil image terkait sebelum bisa menjalankan apa pun. Menurut Netlify, ini terjadi pada sekitar 1,2 persen invokasi dan rata-rata memakan waktu sekitar 9 milidetik.

Yang tidak berubah adalah cara developer menulis fungsi. URL import, paket npm, modul bawaan Node, deklarasi di netlify.toml, dan pengembangan lokal semuanya tetap berjalan seperti sebelumnya. Tidak ada langkah migrasi, dan harganya disebut sama.

Alasan Meninggalkan V8 Isolate

Bagian yang paling menarik dari tulisan ini adalah alasan di balik keputusan tersebut. Netlify menyatakan bahwa isolasi V8, apa pun namanya, tidak memberikan tingkat pemisahan yang mereka inginkan. Dengan MicroVM, deploy yang berpotensi disusupi berjalan di VM terpisah. Bahkan bila kode itu berhasil keluar dari runtime-nya, ia tidak bisa merusak pelanggan lain atau lapisan komputasi itu sendiri.

Isolasi ini juga berlaku antar-deploy dari pelanggan yang sama. Dua deploy dengan kode berbeda atau variabel lingkungan berbeda dianggap sebagai dua service yang berbeda, dan keduanya tidak pernah berbagi MicroVM. Pemisahan ini muncul langsung dari cara service ID dihitung, yang kita bahas di bagian berikutnya.

Pertimbangan kedua adalah batas kemampuan. Netlify mencatat bahwa batas operasional yang selama ini berlaku, yaitu 50 milidetik CPU per permintaan, 512 MB memori, dan 20 MB kode terkompresi, berasal dari model eksekusi berbasis isolate. Dengan VM sungguhan yang memiliki sistem berkas sungguhan, sebagian besar alasan di balik batas itu hilang, dan mereka menyatakan punya ruang untuk meninjau ulang batas tersebut.

Pertimbangan ketiga adalah kontrol atas jalur jaringan. Ketika komputasi berjalan di jaringan sendiri, apa pun yang bergantung pada pengendalian jalur jaringan bisa dibangun tanpa harus menjangkau pihak ketiga lewat internet.

Perjalanan Satu Permintaan

Sebelum permintaan bergerak ke mana pun, edge node menulis spesifikasi untuk mesin yang akan menjalankan fungsi tersebut. Spesifikasi ini menyebut tiga image: runtime, image platform milik Netlify, dan image Edge Function milik pelanggan. Ia juga menetapkan batas CPU, memori, dan koneksi.

Spesifikasi itu ikut menempel pada setiap permintaan. Hash-nya bersama informasi spesifik situs dihitung menjadi sebuah service ID. Dari sinilah isolasi antar-deploy muncul, karena kode atau variabel lingkungan yang berbeda menghasilkan service yang berbeda. Service ID juga menjadi kunci untuk memutuskan node mana yang menjalankan fungsi tersebut.

Setiap region punya sekelompok node komputasi. Edge node memilih salah satunya memakai rendezvous hashing, sehingga service yang sama selalu mendarat di node yang sama. Konsistensi ini yang membuat MicroVM tetap hangat dan kodenya sudah ada di disk serta cache. Menurut Netlify, menyebar permintaan secara merata justru akan menaikkan jumlah cold start.

Tetapi pendekatan itu punya kelemahan yang mereka akui terbuka. Menempelkan seluruh permintaan satu fungsi ke satu node adalah jalur cepat, sekaligus cara membentuk titik panas. Fungsi yang sangat sibuk bisa berebut sumber daya dengan service lain di mesin yang sama. Karena itu Netlify melonggarkan stickiness di atas ambang tertentu, menyebar service ke sebagian node agar lonjakan trafik dari satu pelanggan tidak mengganggu service lain yang kebetulan ter-hash ke node yang sama.

Terakhir, node yang terpilih menarik kode fungsinya. Node yang pernah melayani fungsi itu sudah menyimpannya. Node yang baru pertama kali melihatnya mengambil sekali lalu menyimpannya di cache, sehingga hanya permintaan pertama yang menanggung biaya itu.

Cara MicroVM Dinyalakan

Setiap fungsi berjalan di MicroVM Firecracker miliknya sendiri. MicroVM ini dibuat dalam waktu kurang dari satu milidetik dan mulai berjalan sekitar 2 milidetik pada p99, karena VM tersebut menjalankan lingkungan Linux yang dipangkas, bukan sistem operasi penuh.

Berkas-berkas Edge Function dipasang sebagai image EROFS yang tidak dikompresi, lalu di-memory-map. Efeknya, VM hanya membaca bagian bundle yang benar-benar dipakai, bukan memuat seluruhnya. Detail kecil seperti ini yang menjelaskan kenapa angka cold start bisa tetap rendah meski kode yang dijalankan cukup besar.

Bagian yang paling menarik adalah mekanisme snapshot. Ketika MicroVM selesai boot dan server JavaScript mulai mendengarkan di sebuah port, Netlify mengambil snapshot dari MicroVM itu. Saat fungsi tidak dipanggil, MicroVM-nya mengecil ke nol alih-alih menganggur. Pemanggilan berikutnya memulai MicroVM baru dari snapshot tersebut. Karena snapshot juga di-memory-map, VM bisa mulai mengeksekusi tanpa menunggu seluruh isi snapshot dibaca kembali ke memori.

Siklus hidup VM, yaitu boot, snapshot, restore, dan scale to zero, dikerjakan oleh produk Unikraft. Netlify menyatakan bekerja erat dengan tim Unikraft sepanjang migrasi untuk memastikan mekanisme ini tahan terhadap volume permintaan dan pola trafik mereka. Node komputasinya sendiri dibangun dari base image yang dipublikasikan Unikraft, ditambah sekumpulan paket.

Hal-Hal Operasional yang Sering Terlewat

Bagian ini yang biasanya tidak muncul di pengumuman produk, tetapi justru paling berguna bagi tim yang membangun infrastruktur serupa. Netlify menulis bahwa setelah beberapa tahun beroperasi, mereka sudah menemui berbagai masalah di skala besar, mulai dari kehabisan port di virtual switch sampai masalah DNS. Mereka menyebut cukup terkejut karena ternyata tidak selalu DNS.

Pada iterasi ini, mereka memastikan node komputasi menjalankan resolver DNS lokal. Mereka juga memperluas metrik yang dikumpulkan, termasuk waktu boot, waktu sampai port pertama terbuka, dan waktu sampai kode pengguna mulai berjalan. Selain itu ada beberapa circuit breaker yang memastikan node bisa dialihkan dan dihentikan dengan cepat ketika bermasalah.

Untuk rollout, mereka merancang dua hal sekaligus: pengalaman pengguna dan ketahanan peluncuran. Node komputasi dibangun terpisah dari edge node agar edge node tetap ringan dan cepat, memungkinkan pemakaian tipe instans berbeda, serta penskalaan independen. Sebuah control plane melacak node mana yang ada dan sehat, dan edge node melakukan polling ke daftar itu.

Control plane yang sama juga menggerakkan deploy. Armada baru dinyalakan berdampingan dengan armada yang sedang berjalan, diskalakan sampai setara, dan baru mengambil alih trafik setelah terbukti sehat. Pola ini memungkinkan perubahan digulirkan cepat, tetapi juga ditarik kembali dengan cepat bila bermasalah.

Yang Jadi Mungkin Setelah Ini

Netlify menyebut tiga hal yang jadi lebih mudah dikerjakan setelah komputasi dikendalikan sendiri.

Pertama, dukungan paket npm keluar dari beta. Saat ini paket npm sudah berjalan di Edge Functions, tetapi masih dalam beta dengan sejumlah catatan seputar binary native dan impor berkas saat runtime. VM sungguhan dengan sistem berkas sungguhan menghilangkan sebagian besar alasan di balik catatan tersebut.

Kedua, batas operasional bisa ditinjau ulang. Angka 50 milidetik CPU, 512 MB memori, dan 20 MB kode terkompresi berasal dari model eksekusi berbasis isolate. Dengan model baru, batas itu tidak lagi menjadi konsekuensi arsitektur.

Ketiga, komputasi kini berada di dalam jaringan Netlify sendiri. Apa pun yang bergantung pada pengendalian jalur jaringan, alih-alih menjangkau pihak ketiga lewat internet, kini bisa dibangun di dalam.

Pelajaran untuk Tim DevOps

Migrasi ini memberi beberapa pelajaran yang berlaku umum, bukan hanya untuk platform besar.

Pertama, isolasi bukan detail keamanan yang bisa ditunda. V8 isolate sudah bertahun-tahun dianggap cukup, tetapi ketika model ancaman berubah, pilihan arsitektur yang lebih kuat bisa jadi keharusan, bukan kemewahan.

Kedua, konsistensi routing dan penghindaran titik panas adalah dua hal yang saling tarik-menarik. Solusi yang diambil Netlify, yaitu stickiness dengan pelonggaran di atas ambang tertentu, adalah pola yang bisa ditiru tim mana pun yang menjalankan beban kerja di banyak node.

Ketiga, snapshot dan memory mapping adalah cara paling praktis menekan cold start tanpa mengorbankan ukuran kode. Ini teknik yang bisa diadopsi bahkan pada skala yang jauh lebih kecil.

Keempat, pengukuran yang rinci itu wajib. Metrik seperti waktu boot, waktu sampai port terbuka, dan waktu sampai kode pengguna jalan jauh lebih berguna untuk diagnosis dibanding satu angka latensi agregat.

Kelima, deploy yang aman berarti armada baru berdampingan dengan yang lama sampai terbukti sehat. Pola ini lebih lambat dari penggantian langsung, tetapi memberi jalur mundur yang nyata ketika ada masalah.

Untuk tim di Indonesia yang memakai edge function atau serverless, tulisan ini berguna sebagai referensi arsitektur. Tidak semua orang perlu membangun platform komputasi sendiri, tetapi memahami mengapa sebuah platform memilih VM di atas isolate membantu mengambil keputusan yang lebih tepat saat memilih penyedia, terutama untuk beban kerja yang menuntut isolasi lebih kuat atau paket native.

Sumber resmi: tulisan Netlify, "5x faster Edge Functions: How we replaced v8 isolates with Firecracker MicroVMs", September 2026.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.