5x 更快的 Edge Functions：从 V8 isolates 到 Firecracker MicroVMs
Netlify 从外部托管的 V8 isolates 转向基于 Firecracker 的 MicroVM 的边缘部署，被用来宣称中位性能约提升 5 倍，但许多观察者指出，这种提升大概率主要来自于消除了额外的网络跳转，而不是隔离技术本身。讨论集中在 V8 isolates、容器和 microVM 的权衡：isolates 具有更好的密度和启动速度，但安全边界更弱；microVM 提供更强的内核级隔离，但复杂度和开销更高。更广泛的话题包括：对于不同工作负载来说，何种隔离程度才算“足够”，与 Cloudflare Workers 和 AWS Lambda 的对比，以及把类似 Firecracker 的沙箱能力带给普通开发者的新工具。
性能主张以及提速来自哪里
- 几位评论者认为，5 倍提升主要来自于消除了到第三方“托管执行服务”的网络跳转，而不是单纯因为从 V8 isolates 切换到 Firecracker。
- 旧方案：请求会离开 Netlify 的网络，发送到另一家提供商（看起来是 Deno），然后再返回。
- 新方案：microVM 运行在 Netlify 自己的边缘网络内，因此延迟主要由本地路由决定。
- 有人认为标题有点误导，因为它把收益描述为“isolates vs microVMs”，而不是“远程执行 vs 网络内执行”。
V8 isolates vs microVMs：安全性与隔离
- 有人描述 isolates 是共享进程、地址空间、内存分配器和内核的，因此它们的隔离性比 microVM 更弱。
- V8 的 JIT 复杂性以及历史漏洞引发了对 sandbox 逃逸的担忧；有人指出，V8 团队并不把 isolates 当作强安全边界。
- MicroVM 提供独立的内核和硬件虚拟化，但仍然比给每个租户一台专用机器更弱。
- 有人认为，isolate 对许多非安全关键或同一客户的工作负载来说已经“足够好”，而且资源利用率更高。
- 也有人坚持认为，内核级隔离更可取，并指出 Chrome 本身也不会只信任 isolates。
- 对 microVM 做快照会带来 RNG/UUID/crypto 方面的担忧；Firecracker 有文档化的缓解措施，但在类似系统中出错也有先例。
与 Cloudflare Workers 和 AWS Lambda 的比较
- 评论者对 Netlify 之前基于 isolate 的系统竟有 25–40 ms 的开销感到困惑，而 Cloudflare Workers（同样使用 V8 isolates）快得多；有人把主要原因归结为网络拓扑差异。
- Netlify 报告的约 15 ms 热启动 / 约 25 ms 冷启动，与慢得多的 Lambda 冷启动形成对比；人们把原因归咎于 Lambda 的“企业级附加项”，而不是 Firecracker 本身。
MicroVM、容器与工具链
- 关于 Firecracker 是否会“取代 Docker”存在争论：总体共识偏向不会，因为容器共享内核、资源效率更高，不过 microVM 在更强隔离方面更有吸引力。
- 讨论中提到了 Unikraft、SlicerVM 和 smolvm 这类 microVM 项目；它们因性能和安全性受到称赞，但也因定价、UX 或相较 Firecracker 的安全姿态受到批评。
边缘运行时、JavaScript 与标准
- 有人质疑在以毫秒计数时为什么要用 JavaScript；也有人回应，V8 在启动方面经过高度优化。
- 有人请求 Netlify Edge Functions 支持类似 Fetch 的标准接口（Fetchable），以提升跨运行时的可移植性。