Engenharia de plataforma
A plataforma por trás de cada time rápido.
Plataformas internas, ferramentas para desenvolvedores e caminhos dourados — a infraestrutura que transforma "funciona na minha máquina" em "foi publicado hoje de manhã". Construída para ser mantida, não admirada.
O que construímos
- Plataformas internas de desenvolvimento e caminhos dourados
- CI/CD em que seu time confia o bastante para fazer deploy numa sexta
- Ambientes, ferramentas e templates que fazem do caminho certo o caminho fácil
- Documentação como parte da entrega, não como algo pensado depois
Provas
Auth0
Dentro do produto da Auth0, por sete anos construímos o trabalho de plataforma que nenhum usuário vê e do qual todo time depende: o Admin Panel, o Support Center, sete extensões e as bibliotecas de Python e Node.js sobre as quais outros engenheiros constroem.
Leia o caso- Admin Panel · Support Center · 7 extensões
- Bibliotecas sobre as quais outros times constroem
Quando os times nos procuram
- Cada deploy é um evento
- Integrar um engenheiro leva semanas
- Cada time resolve o mesmo problema de infraestrutura de forma diferente
Por que cada time resolve de forma diferente
Ninguém decide ter cinco formas de fazer deploy de um serviço. Isso acontece uma decisão razoável por vez: um time precisava entregar, a forma compartilhada era lenta ou não estava documentada, então construíram a própria — e funcionou, para eles. Dois anos depois um engenheiro novo leva três semanas para fazer o primeiro deploy, porque a resposta para "como fazemos isso aqui" depende de a qual time você pergunta, e cada incidente começa descobrindo qual das cinco formas esse serviço usa.
Uma plataforma não resolve isso com um mandato. Resolve fazendo com que a forma compartilhada seja melhor que a própria: um template que inicia um serviço com logging, testes, CI e um destino de deploy já prontos; ambientes que aparecem para uma branch em minutos; um pipeline rápido e confiável o bastante para que ninguém queira o seu. Os times migram para o caminho porque é mais rápido, e ficam porque sair significa devolver tudo isso. Adoção é a única métrica que conta — uma plataforma que precisa ser imposta já falhou.
Como construímos
Auditoria de atrito
onde os seus engenheiros realmente perdem tempo
Primeiro os caminhos dourados
fazer do caminho certo o caminho fácil
Automatizar o chato
ambientes, templates, verificações
Medir a adoção
uma plataforma que ninguém usa é decoração
O que é um caminho dourado
O padrão é o caminho certo
um serviço novo começa de um template que já tem logging, testes, CI e um destino de deploy. O engenheiro que segue o caminho recebe tudo isso de graça; quem sai dele precisa justificar por quê.
Ambientes sob demanda
uma branch recebe o próprio ambiente, com dados parecidos com produção, em minutos. "Funciona na minha máquina" deixa de ser um argumento porque já não há diferença.
O pipeline é confiável
verificações que rodam em menos de dez minutos, taxa de instabilidade perto de zero e um rollback que é um único comando. É isso que faz um deploy numa sexta ser comum em vez de corajoso.
A adoção é a métrica
uma plataforma que ninguém usa é decoração. Medimos o tempo até o primeiro deploy de um engenheiro novo, a frequência de deploy por time e quantos serviços estão no caminho — antes e depois.
A meta não é um time de plataforma. É que cada time entregue como se tivesse um.
Funciona bem com
Perguntas frequentes
Isso é DevOps com outro nome?
DevOps opera sistemas; a engenharia de plataforma deixa cada time mais rápido. Relacionados, não idênticos.
Construir ou comprar a plataforma?
Compor: comprar onde é commodity, construir onde o seu fluxo de trabalho é específico.
Como sabemos que funcionou?
Tempo até o primeiro deploy, tempo de integração, frequência de deploy — medidos antes e depois.
Onde a IA entra nisso?
Em dois lugares. O pipeline e os templates são o que torna o desenvolvimento assistido por IA seguro nessa velocidade: especificações no repositório, cada mudança revisada por uma pessoa, verificações automáticas antes de qualquer publicação. E quando um time roda os próprios modelos, a plataforma é o que os serve — versionados, monitorados, reversíveis — do mesmo jeito que serve todo o resto.
Nossos times são pequenos. Isso é exagero?
A plataforma escala para baixo: para um time pequeno costuma ser um template, um pipeline e uma receita de ambiente — uma semana de trabalho que tira uma hora de cada dia seguinte. Exagero é montar um time de plataforma; o ponto é que você não precisa de um.
Quem fica dono da plataforma depois que vocês saem?
Os seus engenheiros, e ela é construída para isso: templates nos seus repositórios, pipelines nas ferramentas que você já usa, documentação que é parte da entrega. A meta nunca foi um time de plataforma; é que cada time entregue como se tivesse um, sem um novo departamento para financiar.