Em Resumo (TL;DR)
Adotar uma mentalidade FinOps na cloud permite reduzir as despesas operacionais até 60% sem sacrificar o desempenho.
Tecnologias como o AWS Lambda SnapStart eliminam os problemas de cold start, garantindo latências mínimas sem custos fixos adicionais.
A orquestração inteligente através de AWS Step Functions evita o desperdício de recursos durante as esperas, otimizando drasticamente os processos assíncronos.
O diabo está nos detalhes. 👇 Continue lendo para descobrir os passos críticos e as dicas práticas para não errar.
No panorama atual da computação na cloud, a otimização de custos serverless já não é apenas uma questão de poupança, mas uma verdadeira disciplina de engenharia necessária para garantir a sustentabilidade do negócio. Imaginemos o cenário da MutuiperlaCasa, uma plataforma de comparação de crédito habitação de tráfego elevado. Até ontem, a infraestrutura baseava-se em clusters de instâncias EC2 sempre ativas, dimensionadas para gerir os picos de tráfego de segunda-feira de manhã, mas largamente subutilizadas durante a noite e os fins de semana. O resultado? Um desperdício de recursos e um OPEX (Operating Expense) insustentável.
Neste guia técnico, analisaremos como a adoção de uma mentalidade FinOps aplicada a uma arquitetura serverless na AWS pode transformar radicalmente o modelo de custos, reduzindo as despesas até 60% sem comprometer o desempenho. Exploraremos soluções avançadas para gerir os cold starts, a orquestração inteligente dos workflows e o uso de capacidade de computação spot.
1. A Mudança de Paradigma: De Provisioned a Pay-per-Use
O primeiro passo para a otimização de custos serverless é compreender onde reside a ineficiência. Numa arquitetura tradicional baseada em VM (Virtual Machines), paga-se pela capacidade reservada, independentemente da utilização real. Num modelo serverless, paga-se pela invocação e pela duração da execução.
Para a MutuiperlaCasa, a migração comportou o desmembramento do monólito Java em microsserviços baseados em AWS Lambda. No entanto, o simples «lift-and-shift» do código para funções Lambda não garante automaticamente uma poupança. Sem um tuning adequado, corre-se o risco de gastar ainda mais devido a configurações de memória erradas ou tempos de execução prolongados.
2. Gestão de Cold Starts: Desempenho vs Custos
Um dos principais entraves à adoção de Lambda para aplicações orientadas ao utilizador (como um simulador de prestação de crédito habitação em tempo real) é o problema do Cold Start. Quando uma função não é invocada há algum tempo, o fornecedor de cloud deve inicializar o ambiente de execução, descarregar o código e iniciar o runtime. Para linguagens como Java (frequentemente usado no setor bancário pela sua robustez), isto pode traduzir-se em latências de vários segundos.
A Solução: AWS Lambda SnapStart
Para mitigar este problema sem recorrer à dispendiosa Provisioned Concurrency (que de facto reintroduz um custo fixo semelhante às EC2), a estratégia vencedora é a utilização do AWS Lambda SnapStart. Esta tecnologia, disponível para os runtimes Java geridos, cria um snapshot da memória e do estado do disco da função inicializada e armazena-o na cache.
- Como funciona: No momento da invocação, a Lambda retoma a execução a partir do snapshot em vez de inicializar tudo do zero.
- Impacto FinOps: Obtêm-se desempenhos de «warm start» (latências abaixo dos 200ms) pagando apenas pelas invocações padrão, eliminando a necessidade de manter instâncias quentes pagas.
- Configuração: É fundamental otimizar o código de inicialização (blocos estáticos) para que seja executado durante a fase de criação do snapshot, não durante a invocação.
Provisioned Concurrency: Quando usar?
Apesar do SnapStart, existem cenários críticos onde a variabilidade não é tolerável. Para os serviços core da MutuiperlaCasa, como a API de login, pode-se adotar uma estratégia híbrida: utilizar o Application Auto Scaling para regular a Provisioned Concurrency com base em horários previsíveis (ex: aumentar a capacidade às 08:00 e reduzi-la às 20:00). Isto equilibra a garantia de desempenho com o controlo de custos.
3. Orquestração Financeira com AWS Step Functions
Um erro comum na otimização de custos serverless é o uso de funções Lambda para aguardar respostas de serviços externos. No caso da MutuiperlaCasa, a verificação da solvabilidade requer interrogações a sistemas externos (ex: Banco de Portugal ou centrais de risco) que podem demorar de 30 segundos a vários minutos.
Se utilizássemos uma Lambda para aguardar esta resposta, pagaríamos por todo o tempo de «idle» (espera). A solução de engenharia correta é o uso de AWS Step Functions.
Standard vs Express Workflows
Para otimizar os custos, é crucial escolher o tipo de workflow correto:
- Standard Workflows: Paga-se por transição de estado, não pela duração. Isto é ideal para os processos de aprovação de crédito que duram horas ou dias. Podemos usar o padrão Wait for Callback (.waitForTaskToken): a máquina de estados para e não custa nada até que o sistema externo responda.
- Express Workflows: Paga-se por número de execuções e duração/memória. Ideal para orquestrações de alto volume e baixa latência (ex: agregação de dados de vários bancos em tempo real).
Implementando os workflows Standard para as chamadas assíncronas, a MutuiperlaCasa eliminou milhares de horas de execução Lambda «vazias», reduzindo a fatura de computação para estes processos em 90%.
4. AWS Fargate Spot para Processamento em Batch
Nem tudo pode ser uma função Lambda. Gerar os relatórios PDF dos contratos ou processar os logs noturnos são tarefas que requerem tempos longos e recursos constantes. Aqui entra em jogo o AWS Fargate, o motor serverless para contentores.
Para maximizar a otimização de custos serverless, a estratégia prevê o uso exclusivo de Fargate Spot. As instâncias Spot aproveitam a capacidade não utilizada da AWS, oferecendo descontos até 70% em relação ao preço On-Demand.
Gerir as Interrupções
A única desvantagem das instâncias Spot é que podem ser terminadas com um pré-aviso de dois minutos se a AWS necessitar dos recursos. Para gerir isto num ambiente de produção:
- A aplicação deve ser stateless e idempotente.
- Implementar um gestor do sinal
SIGTERMno contentor para guardar o estado (checkpointing) no Amazon S3 ou DynamoDB antes do encerramento. - Utilizar AWS Batch ou Step Functions para reiniciar automaticamente os jobs interrompidos na nova capacidade disponível.
5. Resultados: Análise do OPEX
A aplicação rigorosa destas estratégias de otimização de custos serverless levou aos seguintes resultados para a MutuiperlaCasa:
- Redução de Compute: -65% graças à passagem de EC2 always-on para Lambda/Fargate Spot.
- Redução de Storage: -20% graças a políticas de Lifecycle no S3 (movimentação automática dos documentos antigos para Glacier).
- Custos de Gestão: Redução drástica das horas-homem dedicadas ao patching do sistema operativo e à gestão dos servidores.
Conclusões
A adoção do serverless não é uma varinha mágica para os custos, mas uma ferramenta poderosa se governada por princípios FinOps sólidos. A chave do sucesso reside em compreender as nuances dos modelos de pricing (como a diferença entre pagar por duração vs transição) e em arquitetar o software para tirar partido destas diferenças. Para as empresas fintech como a MutuiperlaCasa, esta abordagem não só liberta recursos económicos, mas permite escalar infinitamente mantendo as margens de lucro saudáveis.
Perguntas frequentes
O Serverless FinOps é uma disciplina que aplica princípios de gestão financeira às arquiteturas cloud serverless, transformando a otimização dos custos numa prática de engenharia. A principal vantagem reside na passagem de um modelo de despesa fixa baseado na capacidade reservada para um modelo pay-per-use, onde se paga apenas pela execução efetiva do código. Esta abordagem permite eliminar os desperdícios com recursos inativos e reduzir drasticamente as despesas operacionais, frequentemente até 60% em comparação com as infraestruturas tradicionais.
Para evitar os custos fixos da Provisioned Concurrency mantendo um elevado desempenho, a melhor estratégia é utilizar o AWS Lambda SnapStart, especialmente para runtimes como Java. Esta tecnologia cria e memoriza um snapshot do ambiente de execução inicializado, permitindo que a função arranque quase instantaneamente no momento do pedido. Desta forma, obtêm-se latências mínimas pagando apenas pelas invocações padrão, sem ter de manter instâncias sempre ativas.
Utilizar funções Lambda para aguardar respostas de serviços externos ou processos longos é financeiramente ineficiente porque se paga por todo o tempo de espera inativa. As AWS Step Functions, em particular com os Workflows Standard, resolvem este problema permitindo colocar a execução em pausa sem custos adicionais até que se receba uma resposta externa. Paga-se apenas pelas transições de estado e não pela duração da espera, gerando uma poupança significativa nos processos assíncronos.
O AWS Fargate Spot é ideal para tarefas que não requerem execução imediata ou continuidade absoluta, como o processamento batch de dados, a geração de relatórios ou a análise de logs. Oferece descontos até 70% em relação às tarifas On-Demand aproveitando a capacidade não utilizada da cloud. No entanto, uma vez que as instâncias podem ser interrompidas com curto pré-aviso, é fundamental que as aplicações sejam stateless e capazes de guardar o seu próprio estado para retomar o trabalho em caso de interrupção.
Uma simples migração direta do código, conhecida como lift-and-shift, sem um tuning adequado pode paradoxalmente aumentar os custos em vez de os reduzir. Os principais riscos incluem configurações de memória erradas que prolongam a duração da faturação e o uso impróprio de funções Lambda para tarefas de espera. Para garantir a poupança é necessário reprojetar a arquitetura aproveitando serviços específicos para a orquestração e otimizar os tempos de execução do código.
Fontes e Aprofundamento
Achou este artigo útil? Há outro assunto que gostaria de me ver abordar?
Escreva nos comentários aqui em baixo! Inspiro-me diretamente nas vossas sugestões.