Funciones Edge 5x más rápidas: de islas V8 a Firecracker MicroVMs
El paso de Netlify de islas V8 alojadas externamente a MicroVMs basadas en Firecracker en el edge se está usando para reclamar aproximadamente un rendimiento mediano 5x más rápido, pero muchos observadores señalan que la mayor parte de la mejora probablemente proviene de eliminar saltos de red adicionales y no de la tecnología de aislamiento en sí. La conversación se centra en las compensaciones entre islas V8, contenedores y microVMs: las islas ofrecen mejor densidad y tiempos de arranque, pero límites de seguridad más débiles, mientras que las microVMs proporcionan un aislamiento más fuerte a nivel de kernel a costa de más complejidad y sobrecarga. Otros temas amplios incluyen cuánto aislamiento es “suficiente” para distintas cargas de trabajo, comparaciones con Cloudflare Workers y AWS Lambda, y herramientas emergentes que llevan el sandboxing al estilo Firecracker a desarrolladores cotidianos.
Reclamaciones de rendimiento y de dónde viene la mejora
- Varios comentaristas sostienen que la mejora de 5x proviene sobre todo de eliminar un salto de red hacia un “servicio de ejecución alojado” de terceros, no tanto del cambio de islas V8 → Firecracker per se.
- Configuración anterior: las solicitudes salían de la red de Netlify hacia otro proveedor (aparentemente Deno) y luego regresaban.
- La nueva configuración: las microVMs se ejecutan dentro de la propia red perimetral de Netlify, así que la latencia queda dominada por el enrutamiento local.
- Algunos consideran que el título es ligeramente engañoso porque presenta la ganancia como “islas vs microVMs” en lugar de “ejecución remota vs dentro de la red”.
Islas V8 vs microVMs: seguridad y aislamiento
- Se describe que las islas comparten proceso, espacio de direcciones, asignador de memoria y kernel; se consideran un aislamiento más débil que las microVMs.
- La complejidad del JIT de V8 y errores históricos plantean preocupaciones sobre escapes del sandbox; algunos señalan que el equipo de V8 no trata las islas como un límite de seguridad fuerte.
- Las microVMs proporcionan kernels separados y virtualización por hardware, pero siguen siendo más débiles que dar a cada inquilino una máquina dedicada.
- Algunos argumentan que las islas son “suficientes” para muchas cargas de trabajo no críticas para la seguridad o del mismo cliente y ofrecen mejor utilización de recursos.
- Otros insisten en que el aislamiento a nivel de kernel es preferible y señalan que Chrome en sí no confía solo en las islas.
- El snapshotting de microVMs plantea preocupaciones sobre RNG/UUID/crypto; Firecracker tiene mitigaciones documentadas, pero existe precedente de hacerlo mal en sistemas similares.
Comparaciones con Cloudflare Workers y AWS Lambda
- A varios comentaristas les desconcertó que el sistema previo de Netlify basado en islas tuviera una sobrecarga de 25–40 ms mientras que Cloudflare Workers (también con islas V8) es mucho más rápido; se citan las diferencias de topología de red como la razón principal.
- Los ~15 ms en caliente / ~25 ms en frío que reporta Netlify se contrastan con los arranques en frío mucho más lentos de Lambda; la gente culpa a los “extras empresariales” de Lambda más que a Firecracker en sí.
MicroVMs, contenedores y herramientas
- Hay debate sobre si Firecracker “reemplazará a Docker”: el consenso tiende a que no, porque los contenedores comparten kernel y son más eficientes en recursos, aunque las microVMs resultan atractivas por su aislamiento más fuerte.
- Se discuten proyectos de microVM como Unikraft, SlicerVM y smolvm; se elogian por rendimiento y seguridad, pero también se critican por precio, UX o postura de seguridad frente a Firecracker.
Runtimes edge, JavaScript y estándares
- Algunos cuestionan usar JavaScript cuando se cuentan milisegundos; otros responden que V8 está altamente optimizado para el arranque.
- Se pide que Netlify Edge Functions admita una interfaz estándar similar a Fetch (Fetchable) para mejorar la portabilidad entre runtimes.