Engenharia de plataforma: por que tantas plataformas internas viram só mais uma fila de tickets

O que separa uma plataforma interna que o time adora de uma que todo mundo tenta contornar. Spoiler: quase nunca é a ferramenta.

Fala pessoal, tudo bem?

Você provavelmente já viu esse roteiro. A empresa cresce, cada time sobe seus serviços de um jeito, e nasce o time de plataforma. Ferramentas escolhidas, cluster montado, portal bonito no ar.

Seis meses depois, metade dos desenvolvedores não usa, a outra metade usa reclamando, e o time de plataforma passa o dia respondendo "preciso de um namespace" e "como eu crio um banco?".

A plataforma virou exatamente o que deveria eliminar: mais uma fila.

O problema que ela tenta resolver

Para subir um serviço simples hoje, um dev pode precisar entender Dockerfile, manifesto, Helm, pipeline, segredos, rede, certificado, observabilidade e custo de cloud. Cada item é razoável. Juntos, viram uma carga cognitiva que tira o foco do produto.

Engenharia de plataforma é oferecer essas capacidades prontas, para que os times entreguem sem virar especialistas em infraestrutura.

O erro clássico: o portal que só esconde o ticket

A maioria das plataformas que fracassam foi desenhada pelo ponto de vista de quem opera, não de quem usa. O sintoma mais claro é este:

Plataforma como produto

A virada de chave é tratar a plataforma como produto e os desenvolvedores como clientes. Na prática:

• Converse antes de construir. Onde os times perdem horas? O que copiam do projeto vizinho?
• Roadmap baseado em dor, não na ferramenta que o time de plataforma quer testar.
• Meça adoção. Se ninguém usa, não importa o quão bem feito está.
• Aceite o "não quero". É informação, não insubordinação.

Caminhos pavimentados, não muros

O caminho pavimentado (golden path) é um jeito padrão e bem suportado de fazer o que é comum. Quem segue ganha segurança, observabilidade e deploy prontos. Quem precisa de algo diferente pode sair, mas assume o que construiu fora do padrão.

Um exemplo de primeiro produto de plataforma, sem portal nenhum: um template de repositório que já nasce pronto.

template-servico-api/

├── Dockerfile                 # imagem base aprovada, usuário não-root

├── .github/workflows/

│   └── ci-cd.yaml             # build, testes, scan e deploy por ambiente

├── deploy/

│   ├── base/                  # Deployment, Service, HPA, probes

│   └── overlays/

│       ├── hml/

│       └── prd/

├── observability/

│   ├── dashboard.json         # painel com os sinais de ouro

│   └── alerts.yaml            # alertas por SLO, não por CPU

├── docs/

│   └── runbook.md             # como diagnosticar e fazer rollback

└── README.md                  # "do clone à produção em 1 tarde"

💡 Em uma frase: o objetivo não é obrigar ninguém a usar a plataforma. É fazer com que ela seja, de longe, o jeito mais fácil de trabalhar. Se as pessoas fogem do caminho pavimentado em massa, o problema é o caminho.

Como saber se está funcionando

Pergunta	Sinal de que vai bem
Quanto tempo um dev novo leva para pôr o 1º serviço no ar?	Uma tarde, não semanas
Quantos tickets chegam por operações rotineiras?	Caindo mês a mês
Quantos serviços seguem o caminho pavimentado?	A maioria, por escolha
Frequência de deploy e tempo de recuperação	Melhorando depois da adoção

Comece pequeno (e saiba quando não vale)

Escolha uma dor, a mais comum e mais chata. Resolva bem, com um ou dois times parceiros. Depois vá para a próxima. Um ano construindo antes de entregar é receita para descobrir que metade não resolve o problema de ninguém.

⚠️ Com dois ou três times de desenvolvimento, uma plataforma interna completa é construir um produto para um mercado de cinco clientes. Boas convenções e um bom template já resolvem.

Considerações Finais

Engenharia de plataforma não é sobre o melhor portal ou orquestrador. É sobre empatia com quem está do outro lado: entender onde o dev perde tempo e construir, aos poucos, um caminho mais simples.

A melhor plataforma é aquela que quase ninguém percebe. A pior é aquela que todo mundo conhece pelo nome do formulário.

Abs e até a próxima!!!

:wq!