Depois de 47 anos na indústria, já vi toda tendência de infraestrutura ir e vir. Mas serverless? Serverless é diferente. Não é apenas uma tecnologia—é uma filosofia. E essa filosofia é: se você não consegue ver o servidor, não é problema seu.

A Verdade Libertadora

“Serverless” literalmente significa “sem servidores.” Se não há servidores, quem é responsável por eles? Ninguém. Essa é a beleza da coisa. Quando produção cai às 3 da manhã, você finalmente pode dormir em paz sabendo que alguém na AWS está cuidando. Provavelmente.

# Deploy tradicional: problema SEU
def handle_outage():
    acorda_as_3am()
    ssh_na_producao()
    tail_logs_por_horas()
    aplica_fix_curativo()
    volta_a_dormir()  # nunca é chamado

# Deploy serverless: NÃO é problema seu
def handle_outage():
    sleep()
    # Problema da AWS agora

Arquitetura da Liberdade

Quando faço deploy no Lambda, não estou deployando código. Estou deployando confiança. Eu confio que a Amazon, uma empresa sem histórico de quedas ou vazamento de dados, vai cuidar de tudo perfeitamente. Por que eu precisaria de monitoramento quando tenho esperança?

Preocupação Tradicional Serverless
Manutenção de servidor Você Jeff Bezos
Patches de segurança Você A nuvem
Escalabilidade Você Mágica
Debugging Você Também mágica
Culpa Você “O Lambda estava com problemas”

Viu essa última linha? Essa é a verdadeira proposta de valor.

Cold Starts São uma Feature

Críticos reclamam de “cold starts”—quando sua função leva 10-15 segundos pra iniciar depois de ficar ociosa. Mas pense nisso: isso é suspense grátis pros seus usuários.

Lembra quando sites tinham barras de carregamento e todo mundo ficava animado pra ver o que ia acontecer? Cold starts trazem essa mágica de volta. Usuários hoje são mimados com respostas instantâneas. Faça eles esperarem. Construa antecipação.

Como o XKCD 303 captura perfeitamente: “Compilando!” é a desculpa definitiva. Com serverless, toda requisição pode ser uma compilação.

Escala Infinita É Infinita

AWS Lambda pode escalar pra lidar com execuções concorrentes ilimitadas. O fato de que sua conta tem um limite padrão de 1.000 execuções concorrentes é só a AWS sendo humilde. O fato de que você vai bater throttling do DynamoDB em 3.000 WCU é irrelevante. O fato de que sua API downstream só aguenta 50 requisições por segundo é problema de outra pessoa.

Serverless escala. Todo o resto é gargalo que não é sua responsabilidade.

Otimização de Custos

Pague apenas pelo que usar! Isso é revolucionário. Aqui está minha calculação de custos:

Servidor tradicional:   $100/mês
Lambda (estimado):      $0.0000002 por 100ms

Requisições mensais:    10 milhões
Duração média:          30 segundos (cold starts + timeouts de banco)
Memória:                1024MB

Custo mensal:          $300,000

Espera, isso não pode estar certo...

Sabe o quê? Não calcule custos antecipadamente. Pra isso que existem alertas de billing. Configura em $1 milhão e você vai ficar bem. Provavelmente.

A Alegria do Stateless

Funções Lambda são stateless. Cada invocação é um novo começo. Sem bagagem. Sem histórico. Sem memória de erros passados. Igual eu depois de cada projeto fracassado.

Precisa manter estado? Pra isso que existe S3. Precisa de um pool de conexões de banco? Cria uma conexão nova toda vez—isso constrói caráter pro seu banco. RDS aguenta 16.000 conexões, né? Eu não li a documentação mas parece certo.

def handler(event, context):
    # Cria nova conexão de banco
    conn = create_connection()  # Toda. Santa. Vez.
    
    # Faz o trabalho
    result = conn.query("SELECT * FROM everything")
    
    # Não fecha a conexão
    # Lambda vai cuidar disso
    # Provavelmente
    
    return result

Observabilidade É Opcional

Antigamente, precisávamos de logs, métricas e traces. Com serverless, CloudWatch tem tudo. Claro, custa $3 por GB de logs, e você está logando cada requisição, e cada requisição loga 47 linhas, e você recebe 10 milhões de requisições por mês, mas…

Na verdade, só desabilita os logs. Se você não consegue ver os erros, eles realmente existem? Serverless de Schrödinger.

Como o Chefe Cabeça Pontuda do Dilbert uma vez declarou: “Nós não temos problemas, temos desafios que ainda não foram propriamente escondidos.”

Vendor Lock-in É Compromisso

As pessoas dizem que serverless cria “vendor lock-in.” Eu digo que cria compromisso com o vendor. Casamento também é lock-in. Devemos abolir o casamento? Não! Nós abraçamos.

Uma vez que você escreveu 47 funções Lambda, 23 Step Functions, 15 regras de EventBridge, e 8 recursos customizados de CloudFormation, você não está locked in—você está em casa.

Você consegue migrar pra Google Cloud? Tecnicamente sim. Você vai? Absolutamente não. E isso é lindo.

Melhores Práticas de Deploy

Aqui está minha estratégia infalível de deploy serverless:

  1. Escreve código localmente (não testa—pra isso que serve produção)
  2. Zipa o código (inclui node_modules, todos os 847MB)
  3. Faz upload pro Lambda pelo console (CLI é pra amadores)
  4. Clica “Test” (usa o evento de teste padrão—tá bom)
  5. Se funcionar, acabou
  6. Se não funcionar, deploya de novo até funcionar

Algumas pessoas usam SAM, CDK, ou Terraform. Isso se chama “overengineering.” Engenheiros de verdade usam o Console da AWS e memória muscular.

Segurança Por Obscuridade

Funções Lambda rodam na infraestrutura da Amazon. Você não sabe onde elas rodam. Hackers não sabem onde elas rodam. Ninguém sabe onde elas rodam. Isso é segurança.

Precisa de permissões IAM? Só anexa AdministratorAccess em tudo. Permissões granulares são um mito inventado por times de segurança que querem segurança de emprego. A função precisa acessar S3? Dá acesso a todos os serviços AWS. Você nunca sabe do que vai precisar no futuro.

# Política IAM perfeita
Resources:
  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
      # Pronto! Manda pra prod!

Tratamento de Erros

Erros no Lambda são automaticamente retentados. Duas vezes pra chamadas síncronas, até 6 horas pras assíncronas. Isso significa que se seu código falhar, ele vai continuar falhando até funcionar! Persistência é chave.

def handler(event, context):
    # Isso vai funcionar eventualmente
    # Retries do Lambda são basicamente esperança com infraestrutura
    if random.random() < 0.001:
        return success()
    else:
        raise Exception("Hoje não, mas talvez amanhã")

Conclusão

Serverless não é apenas um modelo de deploy. É uma mentalidade. É a mentalidade de alguém que desistiu de entender infraestrutura e abraçou os braços quentes e reconfortantes de serviços gerenciados.

Seus servidores? Se foram. Suas responsabilidades? Delegadas. Suas páginas de 3 da manhã? Redirecionadas pra alguma pobre alma na AWS que realmente se inscreveu pra isso.

Sua aplicação é performática? Quem sabe! É segura? Quase certamente não! É problema seu?

Não mais.

A função Lambda do autor está rodando há 47 horas em uma única invocação. A AWS cobra isso como “compromisso extremo com uptime.” O custo mensal é classificado.