Padronização

Introdução

Padronização é o princípio que transforma as boas decisões de um time no padrão de todos os outros. A meta é simples de falar e difícil de fazer: o jeito certo também precisa ser o jeito mais fácil, para que os times gastem energia no produto e não em redescobrir, pela quinta vez no ano, como chamar uma API com retry.

Em empresas pequenas, isso acontece quase sem querer: são cinco devs, sentados lado a lado, e todo mundo usa o que a pessoa mais sênior escolheu. O problema aparece quando a empresa cresce. Chegam times novos, cada um com o seu gosto, o seu framework favorito e o seu jeito "melhor" de fazer as coisas. Alguns anos depois, você olha o cenário e encontra:

• Várias bibliotecas de log, cada uma com um formato, e ninguém consegue correlacionar uma requisição entre serviços;
• Cinco jeitos diferentes de chamar uma API HTTP, sendo que três deles não têm timeout;
• Cada serviço com seu próprio formato de erro, obrigando cada cliente a escrever um parser sob medida;
• Infraestrutura copiada e colada entre repositórios, com pequenas diferenças que ninguém lembra por que existem;
• Gente nova que leva meses para ficar produtiva, porque cada repositório é um mundo;
• Um patch de segurança crítico que leva semanas para ser aplicado, porque ninguém sabe onde a biblioteca vulnerável é usada;

Pois é, é raro, mas acontece bastante... Quem nunca abriu um repositório e pensou "pera, por que esse serviço faz tudo diferente dos outros?" E o pior é que cada uma dessas escolhas fazia todo o sentido no dia em que foi feita.

Júnior Inocente

"Mas autonomia do time não é justamente isso? Cada squad escolhe a melhor ferramenta pro seu problema. Padrão me parece a polícia da arquitetura vindo tomar meu framework favorito!"

Calma aí, Júnior! Autonomia é ótimo, e ninguém aqui quer polícia da arquitetura. Mas autonomia sem nenhum chão comum tem um preço, e quem paga são todos: a pessoa de plantão que precisa depurar um serviço escrito numa stack que ela nunca viu, o time de segurança caçando dependências vulneráveis e o próximo dev que entrar no seu squad.

Uma boa padronização não tira autonomia. Ela tira as decisões que não merecem a sua atenção (qual logger, qual formato de log, como montar um pipeline) para que você gaste a sua autonomia onde ela realmente importa: o problema de negócio.

A História das 12 Bibliotecas de Log e dos 5 Jeitos de Chamar uma API

Deixa eu contar uma história que, com pequenas variações, eu já vi em mais de uma empresa.

A empresa começa com um monolito. Depois adota microsserviços, e cada time novo ganha bastante liberdade. O time de pagamentos ama uma biblioteca de log. O time de catálogo prefere outra, porque é mais rápida. O time de busca escreve o próprio wrapper, porque nenhuma das existentes "faz exatamente o que a gente precisa". Três anos e quarenta serviços depois, alguém resolve contar: doze bibliotecas de log. E para chamar APIs HTTP existem cinco abordagens, desde um cliente bem configurado com retry e circuit breaker até uma função caseira que simplesmente espera para sempre quando o outro lado não responde.

Tudo funciona, mais ou menos, até o dia do grande incidente. Um cliente reclama que os pagamentos estão falhando de forma intermitente. A pessoa de plantão tenta seguir a requisição do frontend até o provedor de pagamentos e descobre que:

• Cada serviço loga num formato diferente, uns em JSON, outros em texto puro;
• Só metade deles propaga um correlation ID, e cada um usa um nome de header diferente;
• O serviço que está de fato falhando usa o cliente HTTP caseiro, sem timeout, então as threads vão se acumulando até tudo parar;

A correção leva dez minutos. Achar o problema leva seis horas.

Alguns meses depois, é anunciada uma vulnerabilidade crítica numa biblioteca de log popular (quem viveu o Log4Shell em dezembro de 2021 sabe exatamente como é). Quantos serviços usam essa biblioteca? Ninguém sabe. Cada time precisa verificar as próprias dependências, uns estão de férias, alguns repositórios não são compilados há um ano. O patch que deveria levar um dia leva três semanas.

Repare que ninguém nessa história era incompetente. Cada decisão, isoladamente, era razoável. O problema é a soma de decisões locais razoáveis, sem ninguém olhando o todo. É exatamente essa lacuna que este princípio preenche.

Por Que os Padrões Valem a Pena

É fácil enxergar padrão como burocracia. Então vamos ser concretos sobre o que eles compram.

Menos carga cognitiva

Toda decisão técnica que um dev precisa tomar, ou entender, ocupa um pedacinho da cabeça. O pessoal do Team Topologies fala em carga cognitiva estranha (extraneous cognitive load): o esforço gasto com coisas que não têm nada a ver com o problema que você está resolvendo. Descobrir qual dos doze loggers esse repositório usa, e como ele está configurado, é carga estranha pura.

Quando o básico está padronizado, quem abre qualquer repositório da empresa já sabe onde está o pipeline, como os logs são escritos, como os erros são devolvidos e como o serviço é implantado. A cabeça fica livre para a parte realmente nova: a regra de negócio.

Onboarding mais rápido

Quem chega num ambiente padronizado aprende a plataforma uma vez. Depois disso, trocar de time custa dias, não meses. O mesmo vale para a mobilidade interna: as pessoas conseguem ajudar outros times durante um incidente, cobrir colegas de férias ou mudar de produto sem começar do zero.

Menos risco

Padrões concentram conhecimento e esforço. Um cliente HTTP compartilhado, com timeouts sensatos, retry com backoff e circuit breaker, protege todos os serviços que o utilizam. Um patch de segurança numa biblioteca compartilhada é aplicado num lugar só e distribuído com uma troca de versão. Um inventário de quais serviços usam quais blocos diz, em minutos, onde você está exposto.

Economia de escala

Tudo que é construído uma vez e reutilizado muitas vezes melhora com o tempo: mais gente usa, mais bugs são encontrados, mais casos de borda são tratados. Tudo que é construído quarenta vezes ganha quarenta vezes os bugs, e cada cópia melhora (ou apodrece) sozinha.

O Que Padronizar (e o Que Deixar em Paz)

Nem tudo merece um padrão. Uma boa regra de bolso é: padronize as costuras, não o recheio.

As costuras são os pontos onde times, sistemas e pessoas se encontram: contratos de API, formatos de eventos, autenticação, logs e traces, deploy, infraestrutura. Inconsistência ali machuca todo mundo, porque vaza para outros times. O recheio são os detalhes de implementação de um serviço que ninguém de fora precisa ver: como o código está organizado internamente, qual helper de teste o time prefere, como as funções privadas são nomeadas. Inconsistência ali machuca, no máximo, o próprio time.

Essa divisão também ajuda com a tensão que o Júnior levantou. Os times mantêm autonomia onde ela não afeta mais ninguém e abrem mão de um pouquinho dela nas costuras, em troca de muito benefício coletivo.

A Caixa de Ferramentas da Padronização

Não existe uma única ferramenta que resolva a padronização. Existe um conjunto de práticas complementares, cada uma boa numa coisa. Bora passar por elas.

1. Mantenha um Radar de Tecnologia

Meta: deixar as escolhas de tecnologia visíveis, explícitas e fáceis de consultar, em vez de viverem na cabeça de meia dúzia de pessoas sêniores.

A ideia foi popularizada pela ThoughtWorks, que publica o seu Technology Radar duas vezes por ano há mais de uma década. Cada tecnologia (uma ferramenta, uma plataforma, uma técnica, uma linguagem ou framework) é colocada num de quatro anéis:

• Adote (Adopt): a escolha padrão para trabalho novo. Se você escolher outra coisa, precisa de um bom motivo;
• Experimente (Trial): vale usar em projetos reais onde o risco é controlável. Estamos ganhando experiência com ela;
• Avalie (Assess): vale explorar, com um spike ou uma prova de conceito, para entender como pode nos afetar;
• Evite (Hold): não comece nada novo com ela. O que já existe pode ficar, mas a direção é se afastar;

A mágica do radar é que ele é uma conversa, não uma lei. Ele mostra para os times para onde a organização está indo, dá às tecnologias novas um caminho legítimo de entrada (Avalie, depois Experimente, depois Adote) e dá às antigas uma saída digna (Evite). A ThoughtWorks inclusive abriu o seu ferramental, então qualquer empresa pode montar o próprio radar.

Benefício: menos tecnologias em paralelo fazendo o mesmo trabalho, menos surpresas e um lugar onde "por que a gente usa X?" tem uma resposta escrita. Conecte o radar aos esforços de racionalização do portfólio: o anel Evite costuma ser a primeira lista de candidatos à aposentadoria.

2. Publique Arquiteturas de Referência

Meta: dar aos times um ponto de partida comprovado para os tipos de sistema mais comuns.

Uma arquitetura de referência é um blueprint documentado e opinativo para um problema recorrente: "uma API REST com banco relacional", "um worker orientado a eventos", "um site estático com CDN", "um pipeline de dados". Ela mostra os componentes, como se conectam, quais blocos usar, como tudo é protegido, monitorado e implantado e, muito importante, por que cada escolha foi feita.

Os provedores de nuvem publicam várias (o Azure Architecture Center e o AWS Architecture Center são bons exemplos), mas as mais valiosas são as suas, porque já incluem o seu provedor de identidade, as suas regras de rede, a sua stack de observabilidade e os seus requisitos de compliance.

Benefício: um time que começa um serviço novo não parte de uma página em branco. Parte de algo que já passou pela revisão de segurança, já se encaixa na plataforma e já tem um perfil de custo conhecido.

3. Construa Golden Paths sobre uma Plataforma Interna de Desenvolvimento

Meta: transformar padrões em algo que os times usam, e não em algo que eles leem.

Documento é ótimo, mas ninguém lê documento às seis da tarde de uma sexta-feira. O que funciona muito melhor é fazer do padrão o caminho de menor resistência. Essa é a ideia do golden path (termo do Spotify) ou paved road (termo da Netflix): um jeito suportado, opinativo e bem mantido de construir e operar um certo tipo de software, do primeiro git init até produção.

Na prática, o golden path é entregue por uma plataforma interna de desenvolvimento (internal developer platform): um conjunto de capacidades self-service, mantido por um time de plataforma e tratado como produto. O dev escolhe um template num portal (ferramentas como o Backstage são comuns aqui), responde algumas perguntas e recebe um repositório com o esqueleto do serviço, o pipeline, a infraestrutura, logs, tracing, dashboards e alertas, tudo já ligado aos padrões da empresa.

Júnior Inocente

"Então o time de plataforma decide tudo e a gente só obedece? E se o meu serviço precisar mesmo de algo que o golden path não tem?"

Ótima pergunta, Júnior, e é por isso que a figura tem uma caixa fora do trilho. Um golden path é uma recomendação que ficou irresistível, não uma jaula. Você pode sair dele, mas aí passa a ser dono de tudo que a plataforma faria por você: o pipeline, os patches, o monitoramento, o pager tocando às três da manhã. A maioria dos times, fazendo essa conta com honestidade, fica no caminho. Os poucos que saem geralmente têm um motivo real, e esses motivos são o melhor input que o time de plataforma pode receber sobre o que construir a seguir.

A outra metade da resposta: um bom time de plataforma trata os devs como clientes. Tem roadmap, coleta feedback, mede adoção e satisfação e disputa os seus usuários. Se os times estão fugindo do golden path em massa, o problema é o caminho, não os times. O trabalho da CNCF sobre plataformas e o Team Topologies (com as ideias de "plataforma como produto" e de "plataforma mínima viável", a thinnest viable platform) são bons lugares para se aprofundar.

Benefício: padrões aplicados por padrão, sem ninguém precisar lembrar deles. Um serviço novo já nasce em conformidade, observável e seguro, e é aí que a excelência operacional e o security shift-left ficam baratos em vez de heroicos.

4. Ofereça Módulos e Templates de IaC Reutilizáveis

Meta: transformar a própria infraestrutura num conjunto de blocos testados e versionados.

Copiar código de infraestrutura de outro repositório e dar uma ajeitada é como quase todo drift começa. Uma abordagem melhor é publicar módulos (módulos Terraform, módulos Bicep, componentes Pulumi, templates CloudFormation) para as peças que todo time precisa: uma rede com a segmentação certa, um banco com backup e criptografia habilitados, uma aplicação em contêiner com os sidecars padrão, uma conta de armazenamento com a política de retenção correta.

Algumas práticas deixam os módulos realmente úteis:

• Versione com versionamento semântico, para que os times atualizem no próprio ritmo e saibam quando uma mudança quebra compatibilidade;
• Mantenha-os pequenos e combináveis, um módulo por responsabilidade, em vez de um módulo gigante "faz tudo" com cem parâmetros;
• Embuta o inegociável (criptografia, tags, rede privada) dentro do módulo, para que os times não precisem lembrar;
• Teste-os no pipeline do próprio módulo, antes de qualquer time consumir uma versão nova;
• Publique num registry com documentação e exemplos, para que achar o módulo seja mais fácil do que reescrevê-lo;

Benefício: infraestrutura consistente, controles de segurança e de custo embutidos e melhorias que chegam a todos os times com uma troca de versão.

5. Defina Padrões de Serviço e de API

Meta: fazer com que toda API da empresa pareça ter sido desenhada pela mesma pessoa.

APIs são as costuras mais importantes de todas. Quando cada time desenha a sua do seu jeito, os clientes acabam aprendendo dezenas de dialetos. Um guia de API curto e prático normalmente cobre:

• Nomes: substantivos no plural para recursos, um padrão de casing (escolha camelCase ou snake_case para os campos e nunca misture), URLs previsíveis;
• Versionamento: como a versão é expressa (URL, header ou media type), o que conta como mudança que quebra compatibilidade, por quanto tempo versões antigas são suportadas e como a descontinuação é anunciada;
• Erros: um único formato de erro para todos;
• Paginação, filtros e ordenação: um jeito só para cada um;
• Headers transversais: correlation IDs, chaves de idempotência, headers de rate limit;
• Segurança: esquema de autenticação, escopos, o que nunca pode aparecer numa URL ou num log;

Para os erros, você nem precisa inventar nada: a RFC 9457 (Problem Details for HTTP APIs) define um formato JSON padrão que muitos frameworks já suportam:

{
  "type": "https://api.example.com/problems/insufficient-funds",
  "title": "Saldo insuficiente",
  "status": 422,
  "detail": "O saldo da conta é 30,00, mas a transferência precisa de 50,00.",
  "instance": "/transfers/7f3c",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Se não quiser começar do zero, guias públicos como as REST API Guidelines da Microsoft e as API Improvement Proposals (AIPs) do Google são ótimas referências para adaptar. Para eventos e telemetria vale o mesmo raciocínio: combine os schemas e prefira padrões abertos como o OpenTelemetry para traces, métricas e logs (que, aliás, é exatamente o que torna possível a observabilidade em primeiro lugar entre times).

Benefício: os clientes integram mais rápido, o ferramental genérico (gateways, geradores de SDK, linters, dashboards) funciona para todos os serviços, e a pessoa de plantão lê qualquer erro sem precisar de tradutor.

6. Escolha com Cuidado entre Biblioteca Compartilhada e Copiar e Colar

Meta: compartilhar o que realmente precisa ser compartilhado, e nada além disso.

Agora um assunto polêmico. Bibliotecas compartilhadas são o jeito óbvio de reutilizar código, mas também criam acoplamento: todo consumidor passa a depender do ciclo de release da biblioteca, das suas dependências transitivas e dos seus bugs. A comunidade Go tem um provérbio famoso sobre isso: "a little copying is better than a little dependency" (um pouco de cópia é melhor do que um pouco de dependência).

Então quando vale uma biblioteca compartilhada, e quando copiar tudo bem?

Uma heurística prática é a regra de três: escreva uma vez, copie na segunda, extraia um componente compartilhado só quando o terceiro time precisar e o formato estiver claro. Extrair cedo demais congela a abstração errada e acopla times sem motivo.

E nunca, jamais, coloque regra de negócio numa biblioteca "commons" compartilhada por todos os serviços. É assim que nasce um monolito distribuído, em que mudar uma regra de cliente exige deploy coordenado de quinze serviços. Lógica de domínio mora dentro do seu bounded context.

7. Adote o Inner Source

Meta: deixar todo mundo contribuir com os componentes compartilhados, em vez de enfileirar pedidos para um time central sobrecarregado.

Inner source é aplicar práticas de código aberto dentro da empresa: os componentes compartilhados ficam em repositórios que todos podem ler, qualquer pessoa pode abrir um pull request, existe um CONTRIBUTING.md explicando como, e um pequeno grupo de trusted committers revisa e faz o merge. A comunidade InnerSource Commons tem muitos padrões e material sobre o assunto.

Isso resolve um problema clássico: o time central dono da biblioteca compartilhada vira gargalo, os times cansam de esperar e fazem um fork do código, e pronto, lá estão seis bibliotecas "compartilhadas" de novo. Com inner source, o time que precisa de uma funcionalidade pode construí-la ele mesmo, com os donos cuidando da qualidade e do design.

Benefício: os componentes compartilhados evoluem na velocidade dos seus usuários, o conhecimento se espalha entre os times e os donos deixam de ser gargalo sem perder o controle da qualidade.

Como um Padrão Nasce, Vive e Morre

Um padrão não é uma tábua de pedra. Ele tem um ciclo de vida, e gerenciar bem esse ciclo é o que separa padrões vivos de documentos mortos que todo mundo ignora.

Nascimento: RFCs e comunidades de prática

O pior jeito de criar um padrão é uma pessoa (geralmente com "arquiteto" no cargo) escrever tudo sozinha e anunciar por e-mail. Ninguém segue regra da qual não participou, principalmente regra que não bate com a realidade do time.

Um jeito muito melhor:

1. Comece de uma dor real. "Temos doze loggers e não conseguimos correlacionar requisições" é um ótimo motivo. "Seria legal ter um padrão para X" não é;
2. Escreva um RFC (Request for Comments): um documento curto descrevendo o problema, a proposta, as alternativas consideradas, o custo de migração e os trade-offs. Guarde no controle de versão, onde qualquer um pode comentar;
3. Discuta numa comunidade de prática: um grupo de pessoas de times diferentes que se importam com o tema (backend, frontend, dados, observabilidade). Elas revisam o RFC, trazem a visão das trincheiras e viram embaixadoras do padrão nos seus times;
4. Registre a decisão num ADR (Architecture Decision Record), com o contexto e os motivos, para que daqui a dois anos ninguém precise adivinhar o porquê;
5. Faça um piloto com um ou dois times voluntários antes de espalhar, e ajuste com base no que eles aprenderem;

O artigo do Andrew Harmel-Law no martinfowler.com sobre escalar a arquitetura com o advice process é uma ótima leitura aqui: qualquer pessoa pode tomar uma decisão de arquitetura, desde que peça conselho a quem é afetado e a quem tem experiência no assunto. Encaixa muito bem com padrões.

Vida: dono e versionamento

Depois de adotado, um padrão precisa do mesmo que qualquer produto: um dono (um time ou um grupo nomeado, nunca "todo mundo"), um lugar onde está documentado, uma versão, um changelog e um canal para dúvidas e feedback. Padrões também precisam aparecer onde os devs já estão: nos templates, nos linters, nas verificações do pipeline e no portal, e não só numa página de wiki.

Morte: depreciação e aposentadoria

Padrões devem morrer. Tecnologias envelhecem, opções melhores aparecem, e um padrão que era ótimo cinco anos atrás pode virar uma âncora. Aposentar um padrão direito envolve:

• Movê-lo para Evite no radar e anunciar o substituto;
• Definir uma data de sunset, com tempo suficiente para os times migrarem;
• Oferecer um caminho de migração: guias, codemods, templates atualizados e ajuda dos donos;
• Acompanhar o uso, para saber quem ainda depende dele e ajudar essas pessoas especificamente;
• Remover de verdade quando a data chegar, em vez de deixar lá para sempre;

Júnior Inocente

"Mas por que aposentar alguma coisa? Se o padrão antigo ainda funciona, deixa ele lá. Não faz mal a ninguém!"

Ah, Júnior, quem dera fosse simples assim! Todo padrão que nunca é aposentado continua no cenário, e mantê-lo custa dinheiro: alguém precisa aplicar patches, alguém precisa saber como ele funciona, quem chega precisa aprendê-lo. Sem aposentadoria, a "padronização" vira acúmulo aos poucos. Você acaba com dois padrões para a mesma coisa, depois três, e volta direto para os doze loggers, só que agora cada um com carimbo oficial. Aposentar padrões faz parte deste princípio tanto quanto criá-los.

A Armadilha da Padronização Excessiva

Agora o outro lado da moeda. Assim como a falta de padrões gera caos, o excesso gera paralisia. Sinais de que você passou do ponto:

• Os times precisam da aprovação de um comitê para usar qualquer biblioteca, até numa ferramenta interna pequena;
• A stack aprovada não muda há anos, e toda ideia nova esbarra no "não está no padrão";
• As pessoas passam mais tempo preenchendo pedido de exceção do que escrevendo código;
• Bons engenheiros vão embora porque sentem que não podem aprender nem testar nada novo;
• Aparece o shadow IT: os times usam o que querem, em silêncio, e escondem;
• Os padrões descrevem como as coisas eram feitas em 2018, e não como os melhores times trabalham hoje;

A padronização excessiva mata a inovação de um jeito bem silencioso. Ninguém proíbe explicitamente a experimentação; ela só fica tão cara que ninguém se dá ao trabalho.

Alguns jeitos de evitar isso:

Tradeoffs

A padronização reduz variância, carga cognitiva e risco, e permite que a organização aprenda uma vez e aplique em todo lugar. Mas, como todo princípio, ela traz trade-offs. Algo que deixa o cenário mais consistente pode prejudicar outras qualidades da arquitetura, ou da própria organização.

Bora ver os principais?

Consistência vs Autonomia dos Times

Essa é a tensão central. Todo padrão tira uma escolha de um time. Quando a escolha não importava muito (qual logger), é ganho. Quando a escolha importava de verdade para o problema daquele time (um time de dados obrigado a usar o mesmo banco de um serviço CRUD), é perda, e às vezes grande.

O equilíbrio vem da divisão que vimos antes: rígido nas costuras, flexível no recheio. E de uma cultura em que os times podem questionar um padrão com argumentos e dados, e em que os donos do padrão realmente escutam. Autonomia e alinhamento não são opostos; o objetivo é a autonomia alinhada.

Lock-in em Plataformas Internas

Todo mundo se preocupa com vendor lock-in em provedores de nuvem, mas pouca gente percebe o lock-in interno. Quando todos os serviços dependem da plataforma interna, das bibliotecas internas e dos templates internos, a empresa fica presa à própria criação. Se o time de plataforma encolher, se a plataforma envelhecer ou se a empresa for adquirida e precisar se integrar a outra stack, essa dependência pode sair muito cara.

Algumas mitigações: construa a plataforma sobre padrões abertos (OpenTelemetry, contêineres OCI, ferramentas de IaC de mercado) em vez de formatos internos proprietários; mantenha as camadas de abstração finas, para que os times enxerguem o que existe por baixo; e documente as rotas de fuga. A ideia de thinnest viable platform existe justamente para isso.

Custo de Manutenção dos Componentes Compartilhados

Nada é de graça. Uma biblioteca compartilhada, um módulo de IaC ou um template de golden path precisa de gente: para corrigir bugs, atualizar dependências, responder dúvidas, manter a retrocompatibilidade, escrever documentação. Quando esse custo não é planejado, o componente compartilhado apodrece aos poucos, os times perdem a confiança nele e voltam a construir o próprio. É assim que se chega a doze loggers com um padrão.

Se a organização quer blocos reutilizáveis, precisa financiá-los como produtos, com time, roadmap e orçamento. Caso contrário, é melhor ter menos blocos e mantê-los bem.

Tradeoffs com Confiabilidade (Reliability)

Componentes compartilhados criam modos de falha compartilhados. Um bug no cliente HTTP comum ou uma versão ruim da imagem base de contêiner pode atingir todos os serviços de uma vez. O blast radius de um erro cresce junto com a adoção. Monoculturas são eficientes até o dia em que adoecem todas juntas.

Mitigações: distribua versões novas de componentes compartilhados de forma progressiva (times canary primeiro), mantenha a retrocompatibilidade, teste muito e garanta que os serviços fixem versões em vez de sempre puxar a "latest". Do lado positivo, uma biblioteca de resiliência bem feita pode aumentar a confiabilidade de todos os serviços de uma vez só.

Tradeoffs com Segurança (Security)

A padronização é, na maior parte do tempo, amiga da segurança: menos tecnologias significam uma superfície de ataque menor, patches são aplicados num lugar só e inventários ficam fáceis. O outro lado é que uma única vulnerabilidade num componente muito adotado expõe tudo ao mesmo tempo, e os atacantes adoram componentes muito usados exatamente por isso. O pipeline compartilhado e o registry interno de pacotes também viram alvos valiosos na cadeia de suprimentos de software, e precisam ser protegidos à altura (frameworks como o SLSA ajudam aqui).

Tradeoffs com Otimização de Custos (Cost Optimization)

Times de plataforma, comunidades de prática, revisões de RFC, migrações para padrões novos e a aposentadoria dos antigos consomem tempo e dinheiro que poderiam ir para funcionalidades do produto. No curto prazo, a padronização muitas vezes custa mais do que economiza. O retorno vem depois, com onboarding mais rápido, menos incidentes e menos trabalho duplicado. Por outro lado, os padrões também podem melhorar a otimização de custos diretamente: módulos padrão com tags obrigatórias, tamanhos padrão bem dimensionados e licenças consolidadas.

Tradeoffs com Eficiência de Performance (Performance Efficiency)

Padrões são feitos para o caso comum. Um cliente HTTP genérico, uma configuração padrão de banco ou um tamanho padrão de contêiner vão ser bons o bastante para a maioria dos serviços e subótimos para alguns. Um serviço com requisitos extremos de latência ou throughput pode precisar sair do trilho, e os padrões devem permitir isso quando houver evidência (medições, não achismo) de que o padrão não dá conta.

Júnior Inocente

"Pera aí... Então padrão de menos é caos, padrão demais é paralisia, e cada um tem um custo. Como eu sei qual é o ponto certo?"

Exatamente, Júnior, não existe número mágico. O ponto certo depende do tamanho da empresa, do contexto regulatório, da maturidade e da estratégia. Uma startup com três times precisa de pouquíssimos padrões; um banco com trezentos times precisa de muito mais. O que funciona em qualquer lugar é começar pelas costuras que mais doem, medir se os padrões ajudam, ouvir os times que os usam e continuar aposentando o que não faz mais sentido. Padronização é uma prática contínua, não um projeto com data para acabar.

Conclusão

A padronização é como uma organização para de pagar, de novo e de novo, pelas mesmas decisões. Radares de tecnologia deixam as escolhas explícitas, arquiteturas de referência dão aos times um ponto de partida comprovado, golden paths e plataformas internas fazem do padrão o caminho mais fácil, módulos de IaC reutilizáveis e guias de API mantêm as costuras consistentes, e o inner source mantém os componentes compartilhados vivos e evoluindo.

Mais importante: bons padrões nascem de dores reais, são construídos com as pessoas que vão usá-los, têm dono e morrem quando deixam de ser a melhor opção. Eles reduzem carga cognitiva, tempo de onboarding e risco, sem matar a experimentação que faz a empresa andar para a frente.

E lembre-se: os padrões definem o quê. Quem decide, como a conformidade é verificada e como as exceções são tratadas é papel da governança. Acerte os dois e você terá uma organização em que os times andam rápido porque compartilham um chão comum sólido, e não apesar dele.

Próximos Passos

1. Faça o inventário do cenário atual Mapeie quais linguagens, frameworks, bibliotecas, pipelines e padrões de infraestrutura estão em uso hoje. Não dá para padronizar o que você não enxerga, e só o inventário já costuma revelar as piores duplicações.

2. Escolha as costuras que mais doem Comece pelas áreas em que a inconsistência causa incidentes ou atrasos de verdade: logs e tracing, erros de API, autenticação, pipelines de deploy. Deixe o recheio dos serviços em paz.

3. Publique o seu primeiro radar de tecnologia Mesmo um radar simples, com algumas dezenas de itens, dá aos times uma referência comum e abre a conversa sobre o que adotar, experimentar, avaliar e evitar.

4. Construa um golden path de ponta a ponta Escolha o tipo de serviço mais comum da empresa e torne possível ir do zero à produção pela estrada pavimentada em horas. Meça o tempo até o primeiro deploy antes e depois.

5. Monte o ciclo de vida Crie um template de RFC, uma comunidade de prática, ADRs e um dono para cada padrão. Defina como os padrões são revisados, depreciados e aposentados, e use o processo de verdade.

6. Meça e escute Acompanhe o tempo de onboarding, o tempo de resolução de incidentes, a adoção dos componentes compartilhados e a satisfação dos devs. Quando os times insistirem em sair do golden path, trate isso como feedback sobre o caminho.