Como executamos VMs Firecracker dentro da EC2 e iniciamos navegadores em menos de 1 s

Artigo original ↗ Discussão no Hacker News ↗

Foco geral

  • A discussão se concentra menos na mecânica do artigo (já conhecida) e mais em:
    • Por que VMs Firecracker em vez de contêineres/Lambda.
    • Truques de tempo de inicialização e estratégias de escala.
    • Compensações de segurança/isolamento.
    • Implicações éticas de navegadores “furtivos” e evasão de bots.

Firecracker, virtualização aninhada e escolhas de EC2

  • Alguns observam que a própria EC2 é uma VM; o Firecracker aqui roda como uma VM dentro de VM por meio de virtualização aninhada.
  • Apenas certas famílias de instâncias EC2 atualmente suportam virtualização aninhada; a oferta é limitada e alguns relatam estabilidade pior do que em metal.
  • Outros destacam que instâncias metal têm melhor desempenho, mas demoram mais para iniciar/parar.
  • Vários comentários enfatizam o isolamento mais forte do Firecracker em comparação com contêineres, especialmente para cargas de trabalho de navegador não confiáveis e CVEs frequentes de escape de contêineres.

Contêineres vs microVMs para navegadores

  • Vários participantes perguntam por que não usar apenas Docker/contêineres.
  • Argumentos contra contêineres:
    • Não são considerados um limite de segurança forte; compartilham o kernel do host.
    • Inicialização mais lenta e uso de recursos mais pesado em comparação com snapshots do Firecracker.
  • Contrapontos:
    • Escapes do Docker são “muito difíceis” segundo alguns; há discordância sobre quão fraco é realmente o limite.
    • Para algumas cargas, Chromium em contêineres ou em subprocessos simples é viável, só que mais difícil de escalar e proteger.

Desempenho, snapshots, warm pools

  • A inicialização da VM Firecracker (20 ms) é rápida; a inicialização do navegador (300 ms) domina.
  • O snapshot do estado pós-SO, pré-Chromium é usado para reduzir a inicialização; trabalhos futuros visam criar snapshot com o Chromium já inicializado, mirando ~50 ms de ponta a ponta.
  • Debate sobre “warm pools” de navegadores já em execução:
    • Defensores: simples, latência quase zero se o dimensionamento do pool for adequado.
    • Opositores: capacidade ociosa é cara, difícil de ajustar para muitas combinações de recursos; snapshots podem superar warm pools em custo e velocidade.

Motor do navegador, GPU e Android

  • O Chromium foi mantido principalmente por “stealth” e anti-detecção; alternativas como o Lightpanda são vistas como mais fáceis de identificar por fingerprint.
  • Passagem de GPU não está disponível no Firecracker; as cargas dependem de CPU e rasterização por software, o que é considerado aceitável para a maior parte da automação.
  • VMs de navegador Android são relatadas como muito pesadas, lentas para iniciar e mais difíceis de escalar; atualmente não estão prontas para produção para esse caso de uso.

Ética e impacto da automação furtiva

  • Um grande subfio debate se contornar medidas anti-bot é ético:
    • Críticos: serviços como este aumentam o tráfego de bots, impulsionam CAPTCHAs/tecnologias anti-bot mais severos, externalizam custos para os operadores dos sites e muitas vezes dependem de proxies residenciais com consentimento questionável.
    • Defensores: distinguem entre scraping em massa abusivo e automação leve e orientada por propósito (monitoramento de preços, acompanhamento de ingressos, verificação de links, arquivamento, ferramentas de privacidade, detecção de falsificações, automação de SaaS legada).
    • Alguns argumentam que violações de ToS ≠ comportamento inerentemente antiético; contexto e intenção importam.
    • Outros veem isso como direito aos recursos de terceiros “porque você quer isso”.
  • Foram levantadas preocupações de que a escalada da corrida armamentista bot/anti-bot torna a web mais hostil para humanos, mas alguns usuários afirmam que a automação agora é necessária porque muitos sites se tornaram tão desagradáveis de usar.

Abordagens alternativas e comparações de custo

  • Alguns executam Chromium em imagens de contêiner do AWS Lambda, citando arquitetura mais simples e escala automática; a desvantagem são cold starts e limites de 15 minutos.
  • Para jobs curtos de captura de tela, o Lambda cobrado por milissegundo é relatado como mais barato; para automação de maior duração, o faturamento por minuto de VMs pode vencer.
  • Outras alternativas mencionadas: produtos no estilo Cloudflare Workers, sandboxes no estilo Shellbox, Kubernetes + Kata, ou apenas processos com o próprio sandbox do Chrome.
  • Visão de que EC2 (junto com Firecracker) é “mais escalável do que a sua carteira”, enquanto outros observam o custo de oportunidade da capacidade ociosa e o valor da precificação spot/preemptible.

Segurança e ecossistema web mais amplo

  • Ênfase repetida de que contêineres não são amplamente tratados como fronteiras fortes de segurança, enquanto microVMs são.
  • Alguns veem o tráfego de bots como um custo antigo de operar qualquer serviço público; outros argumentam que a escala e o impacto pioraram significativamente.
  • O fio traz frustração mais ampla com práticas da web antiusuário (rastreamento, anúncios, CAPTCHAs) e a mudança crescente para IA e automação como uma interface mais agradável para conteúdo da web.