O que é Platform Engineering: quando realmente vale a pena

São 22:10 e um desenvolvedor novo está tentando subir um ambiente de staging há dois dias. Abriu três tickets, colou duas vezes o mesmo erro do Terraform no Slack, e ainda não sabe qual dos quatro templates de CI é o real. Essa cena é a resposta toda para «o que é platform engineering»: é o trabalho de construir a estrada interna para que ninguém tenha que hackear sozinho a selva, e tratar essa estrada como um produto com usuários.

Na prática, uma equipe de platform constrói uma plataforma interna para desenvolvedores (IDP, em inglês): ferramentas self-service que deixam outros devs criar serviços, fazer deploy e ver o que está rodando sem esperar por um humano. Aqui está o que quebra na prática quando você pula isso: cada equipe reinventa deployment, e o conhecimento vive na cabeça de três pessoas.

O que é platform engineering, sem o jargão

A definição mais limpa que conheço vem da comunidade platformengineering.org: projetar e construir plataformas que dão às equipes capacidades self-service para as partes recorrentes do trabalho. Tire o jargão e sobram três peças.

Primeiro, uma plataforma interna para desenvolvedores. Não é um produto único que você compra. É uma camada fina de templates, pipelines, APIs e documentação que fica em cima das ferramentas que você já roda (conta cloud, Kubernetes, CI, secrets, monitoramento) e esconde as arestas perigosas.

Segundo, uma equipe de platform. Um pequeno grupo de engenheiros cujos clientes são outros engenheiros. O output deles não é features para usuários finais. O output deles é o quão rápido todo mundo consegue fazer ship.

Terceiro, mentalidade de produto. A plataforma tem usuários, backlog, números de adoção e uma rotina de on-call. Se ninguém usa, falhou, não importa o quanto elegante a arquitetura é.

Gartner previu que até 2026, 80% das grandes organizações de engenharia de software teriam equipes de platform, acima dos 45% em 2022. Trate como um marcador de tendência, não uma promessa. A mesma conversa de indústria diz que uma grande parte dessas equipes lutam para mostrar impacto, o que é exatamente por que o resto deste artigo gasta tempo em o que dá errado.

Como é diferente de DevOps e SRE?

Versão curta: DevOps é uma cultura, SRE é uma disciplina de confiabilidade, platform engineering é um shape de equipe que productiza ambos.

DevOps disse que desenvolvedores e operações devem compartilhar ownership de rodar software. Boa ideia. Em uma empresa de 15 pessoas funciona porque todo mundo consegue ver tudo. Em uma de 300 pessoas se torna silenciosamente «cada squad também precisa virar expert em Kubernetes», o que não é o que ninguém assinou.

SRE foca em targets de confiabilidade: error budgets, resposta a incidentes, capacity. Uma equipe de platform se preocupa com confiabilidade também, mas sua métrica principal é diferente. Ela mede quanto tempo um dev espera entre «tenho uma ideia para um serviço» e «está rodando em produção com logs e alertas».

Platform engineering é a resposta à carga cognitiva que DevOps deixou para trás. Em vez de pedir que cada dev aprenda a toolchain inteira, você dá um default suportado e mantém a expertise dentro da plataforma. Três razões para fazer, uma para não fazer: só compensa uma vez que o número de equipes ou serviços é grande o suficiente para que duplicação doa. Vamos chegar nesse threshold abaixo.

O que uma equipe de platform realmente entrega?

Esquece os diagramas de arquitetura. Aqui está o que o backlog de uma equipe de platform de verdade parece em uma terça-feira normal.

Um template de serviço. Um comando, ou um botão em um portal, cria um repositório com um pipeline que funciona, um Dockerfile, health checks, setup de logging e um dashboard básico. O dev muda a lógica de negócio, não o encanamento.

Um caminho de deployment. Push para main, testes rodam, o artefato é construído e promovido através de ambientes com os mesmos passos toda vez. Sem snowflakes por equipe.

Ambiente sob demanda. Um ambiente de preview por pull request, destruído automaticamente. Essa é a feature que devs realmente agradecem.

Secrets e acesso. Credenciais de curta duração, um lugar para solicitar, uma trilha de auditoria. Chato, e a coisa que salva você em uma revisão de segurança.

Observabilidade por padrão. Cada serviço criado a partir do template entrega metrics, logs e traces sem que ninguém os coloque manualmente. Uma stack como Grafana geralmente fica atrás dessa camada, e sua free tier e opção open-source servem bem uma equipe pequena.

Note o que falta dessa lista: um portal customizado com três meses de roadmap. O portal é a última coisa que você adiciona, não a primeira.

Golden paths: a ideia que faz o resto funcionar

Um golden path é o jeito suportado e com opinião para fazer uma tarefa comum. É mais rápido do que fazer manualmente e mais seguro do que improvisar, e crucialmente é opcional. Desenvolvedores conseguem sair do path quando têm uma razão real. Só que assumem a responsabilidade que vem com isso.

Tem uma distinção útil no artigo do Octopus sobre paved versus golden paths: uma estrada paved é a superfície ampla e bem mantida, enquanto um golden path é a rota recomendada específica para um dado trabalho. Na minha experiência a diferença importa menos que o princípio por baixo. Você ganha fazendo o jeito certo ser o jeito fácil, não banindo os outros jeitos.

Aqui está o que o menor golden path possível parece. É um comando scaffold único que um dev roda uma vez:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Por baixo dessa única linha ficam um repo, um pipeline, DNS, um database stub, alertas e um registro de ownership. O comando é trivial. A parte difícil é seis meses acordando no que «node-api» significa, e mantendo atualizado quando Node, sua imagem base ou seu cloud provider mudam.

Testado, não ótimo, e aqui está por que fazemos mesmo assim: um golden path medíocre que 80% das equipes usam bate um perfeito que 10% adotam, porque o primeiro te dá leverage para melhorar tudo de uma vez.

Quando vale a pena, e quando é distração?

Essa é a seção que a maioria dos artigos pula. Platform engineering não é de graça, e para muitas equipes é a jogada errada.

O overview do platformengineering.org sugere que organizações tipicamente começam a se beneficiar uma vez que passam algo como 20 a 30 usuários da plataforma. Eu leria isso como um chão bruto, não uma regra. Abaixo dele, um README compartilhado, um bom template de CI e uma pessoa que se importa faz mais que uma equipe de platform formal.

Vale a pena quando você tem mais do que um punhado de equipes, e cada uma construiu seu próprio pipeline de deploy. Novos devs levam semanas, não dias, para fazer seu primeiro change rodar. O mesmo tipo de incidente se repete porque cada serviço ligou seus próprios alertas. Segurança ou compliance pede consistência que você não consegue entregar pedindo com gentileza.

Pule quando você é uma equipe de cinco. Escreva um script, não uma plataforma. Você ainda não sabe como seus serviços parecem. Padronizar muito cedo congela as decisões erradas. A proposta é «construir um portal» sem uma lista de dores que remove.

Para builders solo e pequenas crews de side-project, o takeaway honesto é mais simples. Você não precisa de uma equipe de platform, mas precisa dos hábitos: um script de deploy repetível, um template para novos projetos, um dashboard que você checa. Essa é uma plataforma de um, e vai te poupar um fim de semana cada mês.

As ferramentas que as pessoas realmente combinam

Não tem um único «produto de platform engineering». Equipes montam uma stack, e as peças caem em alguns buckets.

Para o portal e catálogo, muitas equipes usam Backstage ou uma alternativa hospedada, que dá uma lista pesquisável de serviços, owners e docs. Para provisioning, Terraform ou OpenTofu mais uma ferramenta GitOps como Argo CD ou Flux. Para CI e delivery, o que você já tem, envolvido em templates compartilhados.

Dois buckets merecem um olhar mais perto, porque decidem se a plataforma se sente confiável.

Observabilidade. Se desenvolvedores não conseguem ver o que o serviço deles está fazendo, não vão confiar na plataforma que fez deploy. Datadog te dá um painel polido único através de infra, APM e logs, por um preço por host que cresce rápido. Stack open-source do Grafana custa você tempo de operações em vez de taxa de licença. Escolha baseado em se seu recurso escasso é dinheiro ou atenção.

Docs e qualidade. Uma plataforma sem boas docs é uma queue de tickets disfarçada. Ferramentas docs-as-code mantêm guias próximos ao repo que descrevem, e gates de code-quality em CI mantêm os templates honestos.

Nenhum desses é obrigatório. São exemplos da camada onde uma equipe de platform gasta seu tempo: escolher um default, ligá-lo ao template, e own do upgrade path.

Como começar sem construir a coisa errada

A maioria dos esforços de platform que falham compartilha o mesmo padrão. Começam grande demais, constroem por meses antes de uma única equipe tocar, e otimizam para o slide da roadmap em vez de adoção. A solução é sem glamour.

Escolha uma tarefa dolorosa e frequente. «Criar um novo serviço» e «conseguir um ambiente de preview» são os vencedores usuais. Entreviste três desenvolvedores e veja eles fazendo. Conte os passos e os minutos.

Construa a versão mais fina que remove a maioria da dor. Um repo de template e um arquivo de pipeline compartilhado contam. Dê a uma equipe amigável e sente do lado deles enquanto usam. Conserte o que quebra, aí ofereça para uma segunda equipe.

Acompanhe dois números: quanto tempo de «novo serviço» até «rodando em produção», e quantas equipes usam o path voluntariamente. Se o segundo número é plano, a plataforma é um mandate, e mandates apodrecem.

Staff como uma equipe de produto. Platform engineers não são DevOps com título novo. O material do platformengineering.org nota que platform engineers ganham em torno de 27% mais que profissionais de DevOps, o que diz que o mercado vê a mistura de produto-e-engenharia como um trabalho distinto e mais difícil.

Mais uma razão para fazer agora: o wrinkle mais novo é que o «usuário» de uma plataforma não é mais só um humano. Agentes de coding abrem pull requests, rodam testes e pedem ambientes. Uma plataforma com templates claros, permissões claras e docs legíveis por máquina é um lugar muito mais seguro para um agente trabalhar que uma pilha de repos snowflake.

Credenciais de curta duração, ambientes de preview e um pipeline consistente são o que mantêm os erros de um agente contidos a uma branch throwaway. Se sua plataforma não consegue dizer um deploy humano de um automatizado, adicione isso antes de adicionar mais alguma coisa.

O que você deveria construir depois?

Se você lidera uma equipe de 30 devs e cada squad tem seu próprio pipeline, uma pequena equipe de platform com um golden path é provavelmente seu hire de maior leverage. Se você é um dev solo com três side projects, copie o pipeline do seu melhor projeto num repo de template esse fim de semana e pronto.

De qualquer forma, a pergunta que vale levar à sua próxima sessão de planejamento é concreta: qual tarefa única seus desenvolvedores repetem mais, e o que custaria para fazer ela um trabalho de um comando?