O que é platform engineering? Guia prático para equipes

O que é platform engineering? Na prática, é a disciplina de construir e manter uma plataforma interna que dá aos desenvolvedores acesso self-service ao que eles precisam para colocar software no ar: ambientes, pipelines, serviços, documentação e guardrails. Uma equipe pequena trata o caminho entre "tenho uma ideia" e "está rodando em produção" como um produto, e os desenvolvedores são os clientes desse produto. A meta é simples: menos espera, menos chamados e menos ferramentas para aprender.

Você provavelmente já viveu esse problema. Um serviço novo precisa de repositório, pipeline, banco de dados, secrets, dashboards e plantão, e cada um desses itens está numa página de wiki diferente ou com uma pessoa diferente no Slack.

Por que a engenharia de plataforma apareceu?

"Quem constrói, roda" funcionou bem enquanto um time era dono de um serviço e de meia dúzia de ferramentas. Deixou de escalar quando o conjunto cresceu para Kubernetes, Terraform, três sistemas de CI, um gerenciador de secrets, um service mesh e uma stack de observabilidade. De repente, todo desenvolvedor de produto passou a ser esperado como engenheiro de infraestrutura em meio período.

O custo aparece como carga cognitiva, não como uma linha no orçamento. Um desenvolvedor que gasta 90 minutos para descobrir qual Helm chart é o "certo" não está travado por falta de habilidade. Está travado por falta de padrões.

A engenharia de plataforma é a correção. Em vez de pedir que cada time monte a mesma stack do zero, uma equipe dedicada monta uma vez, deixa a opção fácil e mantém tudo saudável. Os analistas veem a mesma tendência: a Gartner projeta que 80% das grandes organizações de engenharia de software terão equipes de engenharia de plataforma até 2026, contra 45% em 2022.

O que uma equipe de plataforma realmente constrói?

Deixe os diagramas dos fornecedores de lado por um momento. Na maioria das empresas, uma equipe de plataforma entrega quatro coisas.

• Uma plataforma interna para desenvolvedores (IDP). É o conjunto de ferramentas e fluxos self-service sobre a sua nuvem e o seu CI. Pode ser um portal Backstage, um produto de fornecedor ou um repositório bem cuidado de templates com uma CLI.

• Golden paths. São caminhos opinados e suportados para tarefas comuns, como "criar um novo serviço de API" ou "adicionar uma fila".

• Guardrails. Política, varredura e limites de custo aplicados por padrão, para que a opção segura seja também a mais fácil.

• Documentação e descoberta. Um catálogo que responde "quem é dono deste serviço, onde está o runbook e do que ele depende?"

Nada disso exige uma nova categoria de produto. Muitas boas plataformas começaram como um template de cookiecutter e um README que alguém manteve atualizado.

O que é um golden path e por que as equipes o ignoram?

A CNCF descreve um golden path como uma "composição templatizada de código e capacidades bem integrados para o desenvolvimento rápido de projetos". A definição é explicada pelo Google Cloud com um exemplo em Spring Boot. Em termos simples, é um template que dá a um serviço novo, no primeiro dia, um repositório, um pipeline, logging e configuração de deploy.

O modo de falha é igualmente simples. Um caminho que ninguém pediu, construído sem conversar com as equipes que vão usá-lo, fica com adoção de um dígito enquanto a equipe de plataforma se pergunta por que os desenvolvedores continuam abrindo chamados. O caminho precisa ser mais curto que o atalho, senão as pessoas seguem pelo atalho.

Duas regras mantêm os golden paths vivos:

1. Pavimentado, não cercado. O desenvolvedor pode sair do caminho, mas assume o suporte do que construir fora dele.

2. Tratado como produto. Alguém lê o feedback, acompanha a adoção e apaga os caminhos que ninguém usa.

Platform engineering é só DevOps com outro nome?

Em parte, e a resposta honesta é mais útil que a de marketing. DevOps é uma cultura: responsabilidade compartilhada entre desenvolvimento e operações, com ciclos de feedback curtos. Platform engineering é uma forma de tornar essa cultura sustentável em escala, transformando trabalho operacional repetido em produto.

SRE é outra disciplina. Os SREs definem metas de confiabilidade, medem e decidem quando parar de lançar mudanças para protegê-las. Uma equipe de plataforma fornece a estrada pavimentada; uma equipe SRE diz quanto risco você pode correr nela.

• DevOps é cultura e um conjunto de práticas. Entrega responsabilidade compartilhada e automação, e costuma falhar quando vira um cargo e uma fila de tickets.

• SRE é uma disciplina de confiabilidade. Entrega SLOs, orçamentos de erro e um processo de incidentes, e costuma falhar quando vira uma escala de plantão sem autoridade.

• Platform engineering é um time de produto interno. Entrega uma plataforma self-service e golden paths, e costuma falhar quando vira uma plataforma que ninguém usa.

Vale ler duas vezes a parte dos modos de falha. Uma equipe de plataforma que pega tickets e constrói o que for pedido é um time de operações com outro nome, e herda todos os problemas antigos de fila.

Quando vale a pena montar uma equipe de plataforma?

Pule essa etapa se você tem menos de cerca de 30 engenheiros e um ou dois serviços. Nesse tamanho, um bom repositório de templates e um módulo Terraform compartilhado resolvem o problema, e uma equipe de plataforma em tempo integral é só overhead. Algumas pessoas num time de dez vão acabar virando a plataforma sem alarde, e tudo bem.

Ela começa a se pagar quando os mesmos sinais se repetem:

• Novos serviços levam semanas para chegar à produção, principalmente esperando outras pessoas.

• Três times resolveram o mesmo problema de deploy de três jeitos diferentes.

• Integrar um engenheiro novo significa uma pilha de conhecimento tribal e muito "pergunta pra Priya, ela sabe".

• Revisões de segurança e de compliance acontecem no fim, por time, feitas à mão.

A versão mínima útil é o que o Team Topologies chama de thinnest viable platform: só o necessário para remover a maior dor repetida, bem documentada, e nada além disso. Comece pelo fluxo que mais consome horas entre os times, geralmente "criar um novo serviço" ou "ter um ambiente de preview".

Gerenciamento de feature flags é um bom exemplo de capacidade que sai mais barata como serviço compartilhado do que como dez versões privadas.

Um serviço de flags que todos os times podem chamar, com o mesmo histórico de auditoria e as mesmas regras de limpeza, poupa cada time de escrever o próprio sistema de toggles meio funcional. Comprando ou construindo, ele deve ficar na plataforma, e não em cada repositório.

O que uma plataforma tem a ver com leitura de código?

Mais do que os diagramas admitem. Uma plataforma só é tão útil quanto o conhecimento que a cerca. Quando um desenvolvedor pergunta "como o serviço A se autentica no serviço B?", a resposta está no código, na configuração e num runbook que pode ter seis meses.

É aqui que as equipes de plataforma perdem tempo sem perceber. São elas que recebem a pergunta no Slack que começa com "onde é configurado o X?" e respondem de memória, de novo, pela quinta vez nesta semana. O efeito aparece quando um repositório passa de 80 mil linhas e a equipe de plataforma vira um índice de busca humano.

Algumas ferramentas ajudam, e cada uma resolve uma metade diferente do problema. Ferramentas de docs-as-code mantêm a parte escrita perto da fonte.

Assistentes que entendem código respondem perguntas sobre o próprio código. O assistente da Sourcegraph é voltado a organizações grandes, com vários repositórios, e é vendido a empresas sob cotação. Por isso encaixa melhor em plataformas de estruturas grandes do que em um time de quinze pessoas.

Para o trabalho do dia a dia dentro do editor, um assistente generalista cobre bastante coisa, com a ressalva de que ele só conhece o contexto que você lhe entrega.

O padrão que recomendamos copiar: colocar os templates de golden path, o catálogo de donos e um índice pesquisável do código no mesmo lugar, e deixar os novos engenheiros fazerem perguntas ali antes de perguntar a uma pessoa. Isso também se mede em horas. Se a sua equipe de plataforma responder menos de dez perguntas do tipo "onde isso é configurado" por semana depois dessa mudança, funcionou.

Como começar sem construir uma catedral?

A maioria dos esforços de plataforma que fracassam começa pela ferramenta. A ordem melhor é: pessoas, depois caminhos, depois ferramentas.

1. Entreviste dez desenvolvedores. Pergunte onde eles perdem tempo entre um PR mergeado e uma funcionalidade rodando. Você vai ouvir as mesmas três respostas.

2. Escolha um caminho e entregue em um mês. Um único template de "novo serviço" que funcione de ponta a ponta vale mais que um portal com 40 blocos vazios.

3. Meça antes e depois. Acompanhe o tempo até o primeiro deploy de um serviço novo e o tempo até o primeiro PR mergeado de um contratado novo. Esses dois números dizem mais do que qualquer pesquisa de satisfação.

4. Publique um roadmap e um changelog. O trabalho de plataforma é invisível se você não o tornar visível.

5. Apague coisas. Aposente caminhos e ferramentas que ninguém usa. Uma plataforma menor em que as pessoas confiam vale mais do que uma maior que elas contornam.

Resista à vontade de comprar um portal primeiro. Um portal em cima de fluxos bagunçados entrega uma bagunça mais bonita, e um catálogo com 247 entradas, metade delas desatualizadas, é pior do que catálogo nenhum.

O que dá errado, e como perceber cedo?

Três padrões de falha aparecem repetidamente.

A plataforma helpdesk. Os pedidos chegam por ticket, a equipe os atende à mão e chama isso de self-service. Teste: um desenvolvedor consegue concluir a tarefa comum sem falar com ninguém?

A plataforma por decreto. A liderança obriga todos os times a usar a plataforma antes de ela estar boa. Os números de adoção parecem ótimos e o sentimento desaba. Deixe o uso ser conquistado nos primeiros seis meses.

A plataforma tudo-em-um. Cada pedido vira funcionalidade, a superfície cresce sem controle e a qualidade cai. Diga não, por escrito, com as razões.

Um alerta precoce útil é a proporção entre perguntas no Slack e respostas documentadas. Se a mesma pergunta aparece três vezes em um mês e não existe doc, template nem automação para ela, esse é o próximo item do backlog.

O que faríamos na segunda-feira?

Escolha a coisa que mais desperdiça tempo entre os times e torne-a entediante. Na maioria das empresas, é criar um serviço novo ou obter um ambiente de teste. Escreva o caminho, coloque-o onde as pessoas vão encontrá-lo, conte as horas que ele economiza e só então decida se você precisa de uma equipe maior.

Platform engineering não é um conjunto de ferramentas que você instala. É a decisão de tratar os desenvolvedores internos como clientes, e a prova de que você tomou essa decisão é uma distância menor entre o primeiro dia de um novo contratado e a primeira mudança mergeada por ele.