Um Ano de Laravel Vapor: Lições de Rodar PHP Serverless em Produção

Após um ano inteiro rodando uma aplicação Laravel de alto tráfego no Vapor (AWS Lambda), aqui estão as lições honestas aprendidas -- tanto as vitórias quanto os desafios.

O Que Funcionou Bem

Escalonamento automático. Picos de tráfego que teriam exigido intervenção manual em servidores tradicionais são tratados sem problemas. O Lambda escala para cima e para baixo sem mudanças de configuração.

Redução da carga operacional. Sem patches de servidor, sem atualizações de SO, sem planejamento de capacidade. A equipe foca no código da aplicação em vez do gerenciamento de infraestrutura.

Previsibilidade de custos com carga variável. O preço por requisição significa que períodos tranquilos custam quase nada, enquanto a capacidade de burst está sempre disponível sem provisionamento excessivo.

Simplicidade de deploy. Deploys pelo Vapor são rápidos e atômicos. Fazer rollback é simples se problemas surgirem.

Desafios Encontrados

Cold starts. A limitação de serverless mais discutida é real, mas gerenciável. O prewarming resolve a maioria dos problemas de cold start a um custo desprezível. Os containers Lambda reutilizam conexões após a primeira requisição, então apenas a invocação inicial de um novo container experimenta atraso.

Conexões com o banco de dados. Cada container Lambda abre sua própria conexão com o banco de dados. Em escala, isso pode esgotar os limites de conexão do banco. As soluções incluem RDS Proxy para pool de conexões ou usar bancos de dados projetados para cargas de trabalho de alta concorrência.

Complexidade de debugging. Funções serverless distribuídas são mais difíceis de debugar do que um único servidor. O CloudWatch fornece logs, mas rastrear problemas entre invocações Lambda requer ferramentas de observabilidade mais sofisticadas.

Limitações de sistema de arquivos. O Lambda fornece apenas um diretório /tmp temporário com armazenamento limitado. Aplicações que dependem de armazenamento local de arquivos precisam usar S3 ou serviços similares.

Limites de tempo de execução. O Lambda tem um tempo máximo de execução de 15 minutos. Processos de longa duração como importação de dados ou processamento de vídeo precisam ser divididos em partes menores ou movidos para diferentes serviços de computação.

Insights de Desempenho

Com prewarming adequado e gerenciamento de conexões com o banco de dados, os tempos de resposta são comparáveis aos deploys em servidores tradicionais. A sobrecarga do ambiente de execução do Lambda é mínima para aplicações bem otimizadas.

Os maiores ganhos de desempenho vieram de:

1. Implementar prewarming para eliminar cold starts
2. Usar pool de conexões para o banco de dados
3. Aproveitar o cache do CDN agressivamente para assets estáticos
4. Migrar para o Laravel Octane para conexões persistentes dentro dos containers Lambda

Análise de Custos

Para aplicações com tráfego variável (noites tranquilas, dias movimentados, picos ocasionais), o Vapor tipicamente custa menos do que provisionar servidores tradicionais para capacidade de pico. Para aplicações com tráfego alto e consistente 24/7, a comparação de custos se torna mais próxima, e servidores tradicionais podem ser mais econômicos.

Veredito Após Um Ano

O Laravel Vapor é excelente para equipes que desejam eliminar a sobrecarga de gerenciamento de infraestrutura e têm aplicações com padrões de tráfego variáveis. Não é uma solução universal -- algumas cargas de trabalho são melhor atendidas por containers ou servidores tradicionais. Mas para o caso de uso certo, ele reduz significativamente a complexidade operacional enquanto fornece infraestrutura confiável e escalável.