5x तेज़ Edge Functions: V8 isolates से Firecracker MicroVMs तक
Netlify का externally hosted V8 isolates से edge पर Firecracker-based MicroVMs की ओर जाना लगभग 5x तेज़ median performance का दावा करने के लिए इस्तेमाल किया जा रहा है, लेकिन कई पर्यवेक्षक नोट करते हैं कि अधिकांश लाभ संभवतः अतिरिक्त network hops हटाने से आता है, न कि isolation technology से। बातचीत V8 isolates, containers, और microVMs के trade-offs के इर्द-गिर्द घूमती है: isolates बेहतर density और startup times देते हैं लेकिन security boundaries कमजोर होती हैं, जबकि microVMs अधिक मजबूत kernel-level isolation देते हैं, लेकिन अधिक complexity और overhead के साथ। व्यापक themes में यह सवाल शामिल है कि अलग-अलग workloads के लिए isolation “कितना पर्याप्त” है, Cloudflare Workers और AWS Lambda से तुलना, और ऐसे उभरते tools जो Firecracker-style sandboxing को सामान्य developers के लिए लाते हैं।
प्रदर्शन संबंधी दावे और गति में बढ़ोतरी कहाँ से आती है
- कई टिप्पणीकारों का तर्क है कि 5x सुधार का बड़ा हिस्सा V8 isolates → Firecracker पर स्विच करने से नहीं, बल्कि किसी तीसरे पक्ष की “hosted execution service” तक जाने वाली नेटवर्क हॉप को हटाने से आता है।
- पुराना सेटअप: अनुरोध Netlify के नेटवर्क से बाहर किसी अन्य प्रदाता (संभवतः Deno) तक जाते थे और फिर वापस आते थे।
- नया सेटअप: microVMs Netlify के अपने edge नेटवर्क के भीतर चलते हैं, इसलिए latency स्थानीय routing से अधिक प्रभावित होती है।
- कुछ लोग शीर्षक को थोड़ा भ्रामक मानते हैं क्योंकि यह लाभ को “isolates बनाम microVMs” की तरह प्रस्तुत करता है, बजाय “remote बनाम in-network execution” के।
V8 isolates बनाम microVMs: सुरक्षा और isolation
- isolates को process, address space, memory allocator, और kernel साझा करने वाला बताया गया है; उन्हें microVMs की तुलना में कमजोर isolation माना जाता है।
- V8 की JIT जटिलता और ऐतिहासिक bugs sandbox escapes को लेकर चिंताएँ बढ़ाते हैं; कुछ लोग नोट करते हैं कि V8 टीम isolates को मजबूत security boundary नहीं मानती।
- MicroVMs अलग kernels और hardware virtualization प्रदान करते हैं, लेकिन फिर भी हर tenant को dedicated machine देने से कमजोर हैं।
- कुछ लोगों का तर्क है कि isolates कई non-security-critical या same-customer workloads के लिए “काफी अच्छे” हैं और बेहतर resource utilization देते हैं।
- अन्य लोग kernel-level isolation को बेहतर मानते हैं और ध्यान दिलाते हैं कि Chrome स्वयं केवल isolates पर भरोसा नहीं करता।
- MicroVMs का snapshotting RNG/UUID/crypto संबंधी चिंताएँ उठाता है; Firecracker में इसके लिए documented mitigations हैं, लेकिन समान systems में इसे गलत करने के उदाहरण मौजूद हैं।
Cloudflare Workers और AWS Lambda से तुलना
- टिप्पणीकारों को यह देखकर हैरानी हुई कि Netlify का पिछला isolate-based system 25–40 ms overhead देता था, जबकि Cloudflare Workers (जो V8 isolates ही हैं) बहुत तेज़ हैं; मुख्य कारण के रूप में network topology के अंतर बताए गए हैं।
- Netlify के बताए गए ~15 ms warm / ~25 ms cold को AWS Lambda के कहीं धीमे cold starts से तुलना की गई; लोग Lambda के “enterprisey extras” को Firecracker से अधिक दोष देते हैं।
MicroVMs, containers, और tooling
- इस पर बहस हुई कि क्या Firecracker “Docker को replace” करेगा: आम राय है कि नहीं, क्योंकि containers एक kernel साझा करते हैं और अधिक resource-efficient होते हैं, हालांकि microVMs मजबूत isolation के कारण आकर्षक हैं।
- Unikraft, SlicerVM, और smolvm जैसे microVM projects पर चर्चा हुई; इन्हें performance और security के लिए सराहा गया, लेकिन pricing, UX, या Firecracker की तुलना में security posture के लिए आलोचना भी मिली।
Edge runtimes, JavaScript, और standards
- कुछ लोगों ने milliseconds गिनते समय JavaScript के उपयोग पर सवाल उठाया; जवाब में कहा गया कि V8 startup के लिए अत्यधिक optimized है।
- Netlify Edge Functions के लिए Fetch-like standard interface (Fetchable) सपोर्ट की मांग की गई, ताकि runtimes के बीच portability बेहतर हो सके।