Fly.io para deploys Node.js: serverless sem cold start

Uso o Fly.io há quase dois anos para subir protótipos de aplicações Node.js, e o resumo é este: escrevo um Dockerfile, faço o deploy e o serviço roda sem cold start. Depois de passar por Lambda, Cloud Run, CF Pages, CF Workers, Netlify, Vercel, Heroku e DigitalOcean, é para o Fly.io que eu sempre volto, porque ele entrega o melhor do serverless sem esconder a infraestrutura de quem está colocando código em produção.

Controle da infraestrutura sem abrir mão do serverless

O que me fez ficar é o equilíbrio entre serverless e controle. A maioria dos provedores tenta abstrair a infraestrutura demais, e quando algo quebra você fica sem saber onde olhar. No Fly.io eu escrevo um Dockerfile e faço o deploy, e o resto é comigo: o container que roda é exatamente o que eu montei. Isso muda o jogo quando estou testando um protótipo Node.js que precisa de uma biblioteca de sistema específica ou de uma variável de ambiente que não se encaixa no modelo engessado de uma função.

Já rodei esse mesmo tipo de aplicação em Lambda, no Cloud Run do GCP, em CF Pages, CF Workers, Netlify, Vercel, Heroku e DigitalOcean, e nunca fiquei totalmente satisfeito com nenhum deles. O Vercel tem a melhor experiência de desenvolvimento na minha opinião, e mesmo assim eu continuava voltando para o Fly.io. A diferença é que aqui não existe mágica escondida e nem frescura: o que você escreve no Dockerfile é o que sobe, e o que sobe é o que você consegue inspecionar depois. Para quem já se queimou com abstração demais, isso é alívio.

Cold start não aparece nas aplicações Node.js

A velocidade é o ponto que mais me impressiona e eu não consigo enfatizar isso o suficiente. Não tem cold start. Nas funções serverless tradicionais, aquela primeira requisição depois de um período ocioso sempre vinha com atraso, e em protótipo de cliente isso aparece na hora, na frente de quem está avaliando a entrega. No Fly.io a aplicação responde rápido desde a primeira chamada, do jeito que eu esperava que o serverless funcionasse desde o começo.

Também não tem aquela sensação de estar brigando com limites invisíveis de execução. Como o container está sempre de pé, o comportamento é previsível, e eu consigo explicar para quem está do outro lado por que a latência é aquela e não outra. Para o tipo de trabalho que faço, subir protótipo de aplicação Node.js para validar uma ideia rápido, essa previsibilidade vale mais do que qualquer painel bonito ou fluxo de configuração cheio de etapas. O deploy é curto e o retorno é imediato.

Monitoramento simples, sem página 500 sem log

O monitoramento é simples e resolve. Com o CF Workers eu perdi a conta de quantas vezes recebi a página 500 do Cloudflare sem nenhum log aparecendo, tendo que abrir chamado no suporte para tentar entender o que tinha acontecido. No Fly.io o log está ali, o deploy mostra o que subiu, e quando algo falha eu consigo investigar sozinho em vez de depender de um atendimento que demora a responder.

Não estou dizendo que a estrada foi lisa. Em quase dois anos teve altos e baixos, foi um caminho acidentado em alguns momentos, e isso é esperado de um provedor mais novo. Mas os tropeços nunca foram do tipo que me fizesse querer voltar para as alternativas. O que falta hoje é um serviço de Postgres totalmente gerenciado; se existisse, eu migraria toda a stack dos meus clientes para o Fly.io sem pensar duas vezes.

Depois de tanto tempo testando infraestrutura de deploy, o Fly.io virou o padrão para o qual eu retorno sempre que preciso colocar um protótipo Node.js no ar com velocidade e sem cold start. Continuo acompanhando as idas e vindas do provedor de perto, torcendo para que o Postgres gerenciado chegue e feche a última peça que falta. Como cliente satisfeito, a intenção é seguir usando em todos os projetos de clientes que passarem pela minha mão.