Netlify troca V8 isolates por microVMs Firecracker e deixa Edge Functions 5x mais rápidas

A infraestrutura que roda cerca de 1 bilhão de invocações por dia na Netlify deixou de depender de isolates V8 hospedados fora da rede própria e passou a rodar em microVMs Firecracker, construídas com a Unikraft, dentro da própria borda.

A Netlify reconstruiu, ao longo dos últimos meses, toda a infraestrutura de execução das suas Edge Functions. A empresa detalhou a mudança em post técnico no blog oficial: o motor que processa cerca de 1 bilhão de invocações por dia (casos como a personalização de páginas da Sunweb ou o roteamento por cookie da Loto-Québec) deixou de usar isolates V8 hospedados fora da rede da Netlify e passou a rodar em microVMs Firecracker, dentro da própria rede de borda. O trabalho foi feito em parceria com a Unikraft, que também publicou sua versão da história.

O que muda debaixo do capô

Antes, cada requisição que batia numa edge function saía da rede da Netlify, ia até um serviço de execução hospedado, rodava o código e voltava. Isso significa viagem pela internet pública a cada invocação. Agora, a requisição é roteada para um nó de computação dentro da própria rede, que aciona uma microVM Firecracker (a mesma tecnologia usada pela AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → Lambda) para rodar o código do cliente.

O ciclo de vida dessa microVM (boot, snapshot, restauração e escala a zero) é produto da Unikraft, parceira de infraestrutura da Netlify no projeto. Cada função roda na sua própria microVM, e cada combinação de deploy e variáveis de ambiente vira um serviço isolado, identificado por um hash. Duas versões do mesmo site nunca dividem a mesma microVM.

Os números por trás do "5x"

Os ganhos de latência aparecem sobretudo na invocação a quente, quando a microVM já existe e só precisa processar a requisição:

Invocações a frio, quando a região ainda não tem as imagens da função em cache, acontecem em cerca de 1,2% dos casos e levam em média 9 ms. A própria microVM é criada em menos de 1 milissegundo e inicia em cerca de 2 ms no p99, porque sobe um Linux enxuto em vez de um sistema operacional completo.

Como a requisição percorre a rede

O fluxo descrito pela Netlify segue uma sequência fixa a cada chamada:

1. A requisição chega ao nó de borda mais próximo do cliente, que termina a conexão TLS e confere se a rota bate com alguma edge function do deploy.
2. O nó de borda escreve uma especificação da máquina: as imagens de runtime, plataforma e função, mais limites de CPU, memória e conexões.
3. Um algoritmo de rendezvous hashing escolhe o nó de computação para aquele serviço, sempre o mesmo nó para o mesmo serviço, o que mantém código e cache já aquecidos.
4. O nó de computação aciona (ou cria) a microVM Firecracker correspondente e devolve a resposta pela própria rede da Netlify, sem sair para a internet pública.

Os arquivos da função são montados como uma imagem EROFS não comprimida e mapeados em memória, então a microVM só lê os trechos do pacote que realmente usa. Quando a função fica ociosa, as microVMs escalam a zero em vez de ficar esperando; na próxima chamada, uma nova instância sobe a partir do snapshot já salvo.

Isolamento como efeito colateral (e motivação real)

A Netlify é direta sobre um ponto: isolates V8, por mais que o nome sugira isolamento, não garantem o mesmo nível de contenção que uma máquina virtual real. Um deploy comprometido roda em sua própria microVM e, mesmo que escape do runtime, não alcança outros clientes nem a própria camada de computação da Netlify.

Esse detalhe importa para quem avalia plataformas de edge computing: a escolha da Netlify por microVMs é uma divergência arquitetural explícita em relação ao modelo de isolates que a própria empresa usava antes, feita justamente para reduzir a superfície de risco entre tenants que dividem a mesma infraestrutura de borda.

O que já está disponível sem mexer em nada

Segundo a Netlify, a mudança é transparente para quem já usa Edge Functions: imports por URL, pacotes npm, módulos nativos do Node, declarações em netlify.toml e o fluxo de desenvolvimento local continuam funcionando exatamente como antes. Não há passo de migração, e o preço não mudou.

Para quem decide se vale a pena mover lógica de aplicação para a borda (roteamento, personalização, autenticação, checagem de cookies) esse é o dado prático: o mesmo custo agora entrega uma latência de mediana entre 5 e 6 ms em vez de 25 a 40 ms, o que muda o cálculo de onde vale colocar código que antes ficaria só no backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → central.

O que essa base nova destrava

A Netlify lista três frentes que a nova infraestrutura torna viáveis:

• Suporte a pacotes npm saindo do beta: hoje funcionam com ressalvas em binários nativos e leitura de arquivos em runtime, limitações que existiam por causa do modelo de isolates.
• Revisão dos limites de operação: os atuais 50 ms de CPU por requisição, 512 MB de memória e 20 MB de código comprimido vêm justamente do modelo baseado em isolate, e a empresa sinaliza que pretende reavaliá-los.
• Computação dentro da própria rede: qualquer recurso que dependa de controlar o caminho de rede, em vez de alcançar um serviço terceiro pela internet pública, passa a ser possível de construir.

Nenhum desses três pontos veio junto com o anúncio: são possibilidades abertas pela nova arquitetura, não recursos já entregues. A Netlify não deu prazo para elas, e o próprio post trata a migração como uma base para trabalho futuro, não como um capítulo fechado.

O que fica em aberto

A empresa não detalhou como o modelo de microVMs se comporta sob picos extremos de tráfego de um único cliente além de mencionar que, acima de certo limiar, a afinidade de um serviço com um nó específico é relaxada para espalhar a carga. Também não há dado público sobre como o novo modelo de precificação (se algum) acompanharia limites de CPU e memória mais altos, caso a revisão anunciada de fato aconteça. Para quem roda edge functions em produção na Vercel, no Cloudflare ou na própria Netlify, o ponto de atenção prático é acompanhar se essa folga em limites e pacotes vira mudança concreta de contrato nos próximos meses.

Fonte: Hacker News