Quando o Serverless Começa a Doer de Verdade
O problema não é usar serverless. O problema é acreditar que ele é “sem custo”, “infinitamente escalável” e “de baixa manutenção”. A fantasia cai na primeira madrugada em que o sistema viraliza e o faturamento explode junto com a latência fria das suas funções.
**O que mais machuca:** funções acordando lentas, pipelines de eventos engasgando, logs duplicados e faturas que lembram financiamento imobiliário.
É aqui onde times cometem o pecado clássico: **over-engineering mascarado de modernidade**.
Como Colocar Serverless no Eixo Antes Que Ele Te Coloque no Mapa da Auditoria
Quer serverless funcionando? Pare de tratar ele como substituto de arquitetura. Ele é uma peça. Não é a fundação.
O caminho pragmático envolve três pontos:
- Medir latência fria e quente antes de ir pra produção.
- Configurar limites de execução e alarmes de custo.
- Tratar eventos como fluxos reais, não PowerPoint motivacional.
**Sem isso, você não tem arquitetura. Você tem fé.**
Implementação de Sênior: Observabilidade de Funções com OpenTelemetry
Aqui vai algo prático que evita narrativas mágicas: instrumentação de funções serverless com OpenTelemetry. Nada de pseudoexemplo. Código real.
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
const sdk = new NodeSDK({
traceExporter: new OTLPTraceExporter({
url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT
}),
instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();
export const handler = async (event) => {
// Negócio real
return { statusCode: 200, body: 'OK' };
};Com isso você sabe exatamente quando sua função dorme, acorda e quanto tempo passa tossindo antes de entregar algo.
O Preço de Seguir (ou Abandonar) a Promessa Serverless
**Tudo tem trade-off.** Serverless reduz manutenção de infraestrutura, mas aumenta dependência de provedor, imprevisibilidade de custo e latência sensível a carga.
- Se você usa errado: vira refém da nuvem.
- Se usa certo: ganha elasticidade real e custo alinhado ao negócio.
- Se evita sem pensar: vira o time que gasta fortunas mantendo VM que nem precisava existir.
Direto das Trincheiras
- Timeout é indicador de arquitetura ruim. Não trate como incidental.
- Se o custo explodiu, não culpe o provedor. Culpe o design de eventos.
- Faça chaos testing em lambda. Pelo menos uma vez por semana.
Fontes
[Akitando] #143 – Discutindo sobre Banco de Dados, ebook-50-anos-bbts.pdf, Redes de computadores: uma abordagem de sistemas – Kufunda.net
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos no blog reymaster.dev.br, onde destrinchamos outros hypes da nossa área.
Valeu e até a próxima! 😉
