Serverless é posição no mapa: Wardley Maps antes do diagrama de arquitetura

Raphael Moura | 5 de ago. de 2026 min de leitura
Serverless é posição no mapa: Wardley Maps antes do diagrama de arquitetura

A reunião é sempre a mesma. Alguém propõe Lambda para o serviço novo e a sala se divide em dois personagens. O evangelista já viu função resolver tudo e quer o sistema inteiro serverless até o fim do trimestre. O traumatizado carrega uma fatura que ninguém esquece ou um cold start que apareceu em review de incidente, e decidiu que nunca mais. Os dois têm cicatriz, os dois falam com convicção, e nenhum consegue explicar por que este componente específico deveria ou não rodar gerenciado. A decisão sai no critério de quem defendeu a opinião com mais energia, e o diagrama de arquitetura vem depois, para justificar o que a sala já decidiu.

Já sentei dos dois lados dessa mesa. Passei anos numa consultoria serverless, desenhando backend de hospitalidade global e definindo padrões para squads de uma companhia aérea, o ambiente onde a resposta default é função. Antes disso, passei pela modernização do maior banco da América Latina construindo pipeline de streaming com Kafka e Spark, o ambiente onde Lambda nem entrava na pauta. Vi times excelentes errarem nas duas direções, e sempre pelo mesmo motivo: discutiam tecnologia quando a decisão era de posição.

É essa a tese deste artigo: serverless é decisão de posição. Componente que já evoluiu até commodity pertence ao serviço gerenciado; componente que ainda é o seu diferencial competitivo pede código seu, portátil, mesmo quando roda em cima de serverless; e o custo real do lock-in cresce exatamente na direção errada do mapa, dos componentes genéricos para o seu core. O instrumento que torna essa posição visível é o Wardley Map, e eu vou usá-lo do único jeito que respeito: desenhando um sistema real, até sobrar uma regra de leitura que você leva para a sua próxima reunião.

O mapa, desenhado num sistema real

Mapa se aprende desenhando, então vou desenhar um sistema que você já viu neste blog: a venda de ingressos do artigo de space-based architecture, dois milhões de pessoas disputando cinquenta mil ingressos às dez da manhã.

O desenho começa pelo topo, e no topo vai a necessidade do usuário, nunca um serviço da AWS: comprar o ingresso no segundo em que a venda abre. Dela desce a cadeia de valor, cada componente sustentando o de cima. A jornada de compra precisa de admissão justa quando dois milhões chegam juntos, de pagamento, de identidade, de uma API de venda. A API precisa da regra que decide quem leva o ingresso sem deixar cinquenta mil virarem cinquenta mil e um. E a regra precisa de computação para rodar, de um espaço em memória para absorver o pico, de um buffer para drenar os eventos, de uma persistência para o resto do negócio enxergar o que foi vendido. Quanto mais fundo na cadeia, menos visível ao usuário. E é no fundo invisível que a briga de Lambda costuma acontecer.

O eixo horizontal é o que transforma o desenho em instrumento. Cada componente se posiciona pelo estágio de evolução: gênese quando a coisa está sendo inventada, custom-built quando você constrói porque não existe pronta, produto quando você aluga de alguém, commodity quando virou utility e ninguém compete mais por fazer aquilo melhor. Posicione os componentes do sistema de ingressos nesse eixo e o mapa conta uma história que o diagrama de arquitetura esconde. Computação, API, fila, banco chave-valor, identidade: tudo isso cruzou a fronteira da commodity faz anos. O waiting room e o espaço em memória são produto, você aluga Queue-it ou liga um ElastiCache. E, abaixo da jornada, um único componente da maquinaria invisível sobra no lado esquerdo: a regra de alocação, com o decremento atômico e o write coalescing que detalhei no outro artigo. Ela está em custom-built porque não existe de prateleira, e não existe de prateleira porque é a sua venda sobrevivendo ao pico. É o seu diferencial.

O mapa do sistema de ingressos: necessidade do usuário no topo, cadeia de valor descendo, cada componente posicionado pelo estágio de evolução. Na maquinaria invisível, um único componente mora no lado esquerdo, e é ele que diferencia o sistema.

O mapa do sistema de ingressos: necessidade do usuário no topo, cadeia de valor descendo, cada componente posicionado pelo estágio de evolução. Na maquinaria invisível, um único componente mora no lado esquerdo, e é ele que diferencia o sistema.

Simon Wardley criou a técnica em 2005 mapeando a própria empresa, a Fotango, subsidiária da Canon que ele dirigia, e o mapa dizia que computação estava escorregando para commodity. Ele apostou o negócio nisso: o Zimki, construído em 2005 e aberto ao público no ano seguinte, cobrava rede, storage e computação por função, serverless funcional cerca de oito anos antes de o Lambda existir. A Canon desligou o produto na véspera do Natal de 2007, e o mapa continuou certo mesmo assim. É toda a teoria de que você precisa por aqui: o livro completo é aberto para quando quiser a doutrina inteira, mas o instrumento existe para uma coisa só, enxergar para onde cada componente está indo antes de o mercado anunciar.

A regra de leitura

O mapa vira decisão com uma regra de três zonas, e essa regra é o que eu quero que você leve deste texto. Lado direito do mapa, consome gerenciado sem culpa. Meio, aluga com um adaptador fino na frente. Lado esquerdo, constrói; e se construir em cima de serverless, mantém o core portátil.

Consumir sem culpa significa dar ao componente a atenção que a posição dele merece, nenhuma a mais. Lambda, SQS, DynamoDB e Cognito entram no sistema como energia elétrica entra no prédio, analogia que carrega um asterisco cobrado duas seções adiante: você dimensiona, configura e segue para o problema que paga o seu salário. Time que gasta três sprints comparando runtime de função está investindo o melhor da engenharia no quadrante onde nenhuma escolha gera vantagem competitiva. No mapa isso aparece de graça: a distância horizontal entre a regra de alocação e o resto dos componentes é a distância entre o que merece debate e o que merece configuração.

O meio pede um cuidado a mais. Produto ainda troca de dono, de preço e de fornecedor, então o contrato com ele passa por uma interface sua, fina de propósito. O espaço em memória é ElastiCache hoje e pode ser outra coisa no ano que vem; o waiting room é Queue-it hoje e Cloudflare amanhã. Adaptador fino é uma porta pela qual o fornecedor consegue sair, sem a ambição da camada de abstração pesada que tenta escondê-lo por inteiro.

E o lado esquerdo é onde mora a inversão que o evangelista não faz. A regra de alocação pode e deve rodar em Lambda, o artigo de space-based está inteiro construído em cima disso. Rodar em serverless nunca foi o problema. O problema é deixar essa regra se dissolver na plataforma: espalhada em vinte funções, colada no formato do evento, com o fluxo de negócio dentro do orquestrador. O seu diferencial passa a morar dentro de uma empresa que não é a sua. Core portátil quer dizer que a regra vive num módulo seu, testável sem AWS na sala, e o handler é um adaptador que a invoca. A própria AWS recomenda arquitetura hexagonal para Lambda no prescriptive guidance, o que diz bastante sobre quem está prestando atenção.

Reli dois artigos que publiquei aqui com o mapa na mão, e os dois eram decisões de posição sem o desenho. A pergunta que fecha o de space-based, o seu pico concentra numa única chave?, é uma pergunta sobre a costura entre duas zonas: o DynamoDB é commodity e entrega o que prometeu, mil escritas por segundo por partição, mas quando o pico concentra num único item, uma fatia do problema que você achava comprada atravessa a fronteira de volta para o seu lado do mapa, e você herda o princípio da space-based architecture querendo ou não. E o monolito distribuído do artigo de DDD é o que acontece quando o time fatia o sistema por tipo de recurso em vez de fatiar por posição: trezentas Lambdas onde core e commodity moram misturados, ninguém sabendo qual fronteira defende o quê. Os dois textos aplicavam a régua sem mostrar o instrumento. Este mostra.

A mesma cadeia com a regra de leitura por cima: constrói o diferencial mantendo o core portátil, aluga produto atrás de adaptador fino, consome commodity sem culpa. A linha tracejada é a costura onde vive a pergunta do hot key.

A mesma cadeia com a regra de leitura por cima: constrói o diferencial mantendo o core portátil, aluga produto atrás de adaptador fino, consome commodity sem culpa. A linha tracejada é a costura onde vive a pergunta do hot key.

Onde o mapa mente: o gradiente do lock-in

O mapa tem um ponto cego para quem lê ingênuo, e ele fica justo onde a discussão esquenta: a coluna da direita sugere uma intercambiabilidade que a plataforma não entrega. Utility de verdade funciona como energia elétrica, você troca de fornecedor sem reformar o prédio. Serverless é utility no modelo de consumo, paga pelo uso, escala com a demanda, capacidade invisível. Na interface, é proprietário. O plugue é padrão; a tomada é de um fabricante só. O próprio Wardley sabia disso desde 2008: commodity padroniza para um de facto, e intercambiabilidade é resultado que se constrói, com segunda fonte e implementação aberta. No cloud, ninguém construiu. O livro dele concede o ponto numa linha do capítulo “A smorgasbord of the slightly useful”: não existe mercado interoperável e competitivo entre provedores; o que existe, nas palavras dele e em tradução livre, é “um continente (Amazon), algumas ilhas substanciais e muitos atóis pequenos, a maioria afundando rápido no mar”.

O exemplo mais honesto é o Step Functions. A Amazon States Language tem spec pública, e mesmo assim um fluxo escrito nela só executa de verdade dentro da AWS: o raro runtime alternativo, o Floe do ManageIQ, implementa a linguagem, mas o valor do Step Functions sempre esteve nas integrações gerenciadas com o resto da plataforma, e essas não acompanham. O mesmo raciocínio vale para dados: single-table design é excelente engenharia e só faz sentido no DynamoDB. Nada disso é acusação; plataforma boa integra fundo, e integração funda acopla. A pergunta que importa é outra: onde o lock-in custa caro.

O Gregor Hohpe desmontou o binarismo dessa guerra faz tempo: para ele, lock-in é custo de troca contra utilidade única, uma régua contínua em vez de chave de liga e desliga, e aceitar lock-in num componente é decisão legítima quando o retorno compensa. O que o mapa acrescenta ao argumento dele é a dimensão espacial. No lado commodity, proprietário custa pouco: o wiring de SQS para Lambda, as policies de IAM, o pipeline de deploy. Migrar isso é trabalho chato de algumas semanas, sem risco de negócio, porque nada ali diferencia a sua empresa da concorrência. Proprietário invadindo o lado esquerdo é outra conversa. Fluxo de negócio dentro de uma state machine, regra de alocação expressa em ASL, core moldado pelo modelo de dados do banco: quando isso precisa sair, o que sai junto é o motivo de a empresa existir, e o time passa meses reescrevendo o que diferencia o negócio em vez de trocar cabeamento de infraestrutura. O gradiente cabe numa frase: quanto mais à esquerda está o componente, mais caro é o proprietário dentro dele.

O gradiente do lock-in: acoplamento proprietário custa pouco na commodity e caro no custom. A guerra do lock-in, dos dois lados, trata essa curva como se fosse plana.

O gradiente do lock-in: acoplamento proprietário custa pouco na commodity e caro no custom. A guerra do lock-in, dos dois lados, trata essa curva como se fosse plana.

Quando o mapa não ajuda

Quatro limites, para o instrumento não virar religião.

Primeiro: posição no eixo é opinião desenhada. Duas pessoas competentes posicionam o mesmo componente em estágios diferentes, e o eixo não tem régua calibrada. Tudo bem. O valor do mapa está na conversa que ele força, com todo mundo apontando para o mesmo desenho, e um posicionamento errado aparece rápido quando está na parede. O que o mapa nunca vai ser é medição.

Segundo: na minha experiência, time apaixonado por ferramenta transforma o mapa em pauta. Se uma hora de quadro branco não produziu nenhuma decisão de construir, alugar ou consumir, vocês não estavam mapeando, estavam desenhando. O mapa é meio; a decisão de sourcing é o fim.

Terceiro: sistema pequeno não paga o cerimonial. Para três pessoas construindo um MVP, a regra de leitura aplicada de cabeça resolve: gerenciado para tudo que não é diferencial, e o diferencial num módulo que não sabe que a AWS existe. O desenho formal entra quando a decisão envolve mais gente do que cabe numa conversa.

E quarto, o limite que mais importa: o mapa diz se o componente vai para serverless; ele não diz como. Posição e forma da carga são perguntas ortogonais. O hot key do artigo de space-based não aparece em eixo nenhum do Wardley Map: o DynamoDB ocupa o mesmo lugar no desenho com pico distribuído ou concentrado, e a decisão de absorver o decremento em memória vem da forma da carga, de medir, do load test concentrado num único key. Posição decide sourcing. Carga decide desenho. Quem responde as duas com o mesmo instrumento erra pelo menos uma.

Fechando

O evangelista e o traumatizado da abertura discutiam a ferramenta errada para a pergunta errada. Serverless é decisão de posição: o mapa torna a posição visível, e a regra de leitura converte posição em sourcing, direita consome, meio aluga atrás de adaptador fino, esquerda constrói portátil, com o lock-in custando na proporção em que o proprietário invade a esquerda. Tudo isso cabe numa hora de quadro branco antes do próximo diagrama de arquitetura.

O passo concreto que recomendo muito: na próxima decisão de serverless ou não, reúne o time por uma hora antes de qualquer diagrama. Necessidade do usuário no topo, cadeia de valor descendo, cada componente posicionado no eixo de evolução, regra de leitura aplicada em voz alta, componente por componente. Montei um canvas de uma página com esse protocolo, para imprimir e riscar; quem preferir digital desenha o mapa a partir de texto no OnlineWardleyMaps. E fica registrado um compromisso: meus próximos artigos de arquitetura abrem com o mapa da decisão, antes do diagrama da solução. Tem um mapa em particular me incomodando há meses, o do stack agêntico, com metade dos componentes escorregando de custom para commodity mais rápido do que os times estão percebendo. Ele abre o próximo texto.

Referências