5x mais rápidas Edge Functions: de V8 isolates para Firecracker MicroVMs
A mudança da Netlify de V8 isolates hospedados externamente para MicroVMs baseadas em Firecracker na edge está sendo usada para alegar cerca de 5x de melhoria na performance mediana, mas muitos observadores notam que a maior parte do ganho provavelmente vem da eliminação de saltos adicionais de rede, e não da tecnologia de isolamento em si. A conversa gira em torno de trade-offs entre V8 isolates, containers e microVMs: isolates oferecem melhor densidade e tempos de inicialização menores, mas fronteiras de segurança mais fracas, enquanto microVMs fornecem isolamento mais forte em nível de kernel, ao custo de mais complexidade e overhead. Temas mais amplos incluem o quanto de isolamento é “suficiente” para diferentes workloads, comparações com Cloudflare Workers e AWS Lambda, e ferramentas emergentes que levam sandboxing no estilo Firecracker a desenvolvedores do dia a dia.
Reivindicações de desempenho e de onde vem a aceleração
- Vários comentaristas argumentam que a melhoria de 5x vem בעיקרamente de eliminar um salto de rede para um “serviço de execução hospedado” de terceiros, e não da troca de V8 isolates → Firecracker em si.
- Configuração antiga: as requisições saíam da rede da Netlify para outro provedor (aparentemente Deno) e depois voltavam.
- Nova configuração: as microVMs rodam dentro da própria rede de edge da Netlify, então a latência é dominada pelo roteamento local.
- Alguns veem o título como um pouco enganoso porque ele enquadra o ganho como “isolates vs microVMs” em vez de “execução remota vs execução na rede”.
V8 isolates vs microVMs: segurança e isolamento
- Isolates são descritos como compartilhando processo, espaço de endereçamento, alocador de memória e kernel; eles são considerados um isolamento mais fraco do que microVMs.
- A complexidade do JIT do V8 e bugs históricos levantam preocupações sobre escapes de sandbox; alguns observam que a equipe do V8 não trata isolates como uma fronteira de segurança forte.
- MicroVMs fornecem kernels separados e virtualização de hardware, mas ainda são mais fracas do que dar a cada locatário uma máquina dedicada.
- Alguns argumentam que isolates são “bons o suficiente” para muitas cargas de trabalho não críticas em termos de segurança ou do mesmo cliente e oferecem melhor utilização de recursos.
- Outros insistem que o isolamento em nível de kernel é preferível e observam que o próprio Chrome não confia apenas em isolates.
- O snapshotting de microVMs levanta preocupações com RNG/UUID/cripto; o Firecracker tem mitigações documentadas, mas há precedentes de isso dar errado em sistemas semelhantes.
Comparações com Cloudflare Workers e AWS Lambda
- Comentadores estranham que o sistema anterior da Netlify baseado em isolates tivesse sobrecarga de 25–40 ms enquanto o Cloudflare Workers (também com V8 isolates) é muito mais rápido; diferenças na topologia de rede são citadas como a principal razão.
- Os cerca de 15 ms em quente / 25 ms em frio reportados pela Netlify são contrastados com cold starts muito mais lentos do Lambda; as pessoas culpam os “extras enterprise” do Lambda, e não o Firecracker em si.
MicroVMs, containers e ferramentas
- Há debate sobre se o Firecracker vai “substituir o Docker”: o consenso pende para não, porque containers compartilham um kernel e são mais eficientes em recursos, embora microVMs sejam atraentes por oferecerem isolamento mais forte.
- Projetos de microVM como Unikraft, SlicerVM e smolvm são discutidos; eles são elogiados por desempenho e segurança, mas também criticados por preço, UX ou postura de segurança em comparação ao Firecracker.
Edge runtimes, JavaScript e padrões
- Alguns questionam o uso de JavaScript quando se contam milissegundos; outros respondem que o V8 é altamente otimizado para inicialização.
- É feita uma solicitação para que as Netlify Edge Functions suportem uma interface padrão parecida com Fetch (Fetchable) para melhorar a portabilidade entre runtimes.