Platform Engineering e Internal Developer Platforms

Nos últimos anos, "Platform Engineering" deixou de ser um termo de nicho para se tornar uma das conversas centrais sobre como organizar times de engenharia em escala. Se você é dev ou SRE, provavelmente já sentiu o problema que essa disciplina tenta resolver: a quantidade de ferramentas, pipelines, configurações de Kubernetes, políticas de segurança e ambientes que um time precisa dominar só para colocar uma aplicação em produção cresceu a ponto de virar um gargalo. Platform Engineering é, em essência, a resposta de produto a esse excesso de carga cognitiva.

O que é Platform Engineering

Platform Engineering é a prática de projetar e construir ferramentas e fluxos de trabalho internos que permitem que desenvolvedores entreguem software com autonomia, tratando a infraestrutura e o tooling como um produto cujos clientes são os próprios engenheiros da empresa.

A mudança de mentalidade importante está nessa palavra: produto. Em vez de uma coleção de scripts e wikis mantidos de forma reativa, a plataforma tem um time dedicado, um backlog, usuários internos com necessidades reais e métricas de adoção e satisfação. O objetivo não é controlar o que os times fazem, mas reduzir o atrito entre escrever código e rodá-lo de forma segura em produção.

Internal Developer Platform (IDP)

A materialização concreta dessa prática costuma ser a Internal Developer Platform (IDP): uma camada de self-service, construída sobre a infraestrutura existente, que abstrai a complexidade e oferece aos devs interfaces consistentes para provisionar recursos, criar serviços, acessar logs e fazer deploy.

Vale separar dois termos que às vezes se confundem — e a própria sigla IDP é usada, de forma ambígua, para os dois. Internal Developer Platform é a plataforma em si: o conjunto de tools, automações e abstrações que sustentam o ciclo de entrega, acessível por UI, CLI, API ou fluxos GitOps. Já Internal Developer Portal é especificamente a interface/portal de acesso a essa plataforma. O portal é uma parte da plataforma, não o todo; inclusive, uma plataforma pode existir sem portal, com os devs interagindo direto por CLI ou repositórios de infraestrutura.

Uma IDP madura costuma combinar:

• Catálogo de serviços e ownership (quem é dono de quê);
• Self-service para criar novos serviços a partir de templates;
• Abstrações de infraestrutura (bancos, filas, clusters) provisionadas sob demanda;
• Visibilidade de pipelines, deploys, métricas e documentação em um só lugar.

Golden paths: o caminho pavimentado

O conceito de golden path (ou "paved road", caminho pavimentado) é o coração da experiência de uma boa IDP. Um golden path é a rota recomendada e bem suportada para realizar uma tarefa comum — criar um microsserviço, adicionar um banco de dados, publicar uma API — com as melhores práticas já embutidas. Vale notar que os dois termos têm origens distintas, ainda que hoje sejam usados quase como sinônimos: "paved road" é a expressão historicamente associada à Netflix, enquanto "golden path" ficou popular a partir da Spotify e do Backstage.

A ideia não é proibir alternativas, mas tornar o caminho correto também o mais fácil. Quando seguir o padrão da empresa exige menos esforço do que improvisar, a padronização acontece naturalmente. Um golden path bem feito já entrega observabilidade, segurança, CI/CD e conformidade "de fábrica".

Na prática, isso costuma aparecer como um template que gera o esqueleto de um serviço novo. Por exemplo, um descritor declarativo de um componente:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: pagamentos-api
  description: API de processamento de pagamentos
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: time-pagamentos
  system: financeiro

A partir desse descritor, a plataforma sabe quem é o dono, onde está a documentação e como o componente se encaixa no resto do sistema — sem que o dev precise configurar cada peça manualmente.

Relação com DevOps: complementa, não substitui

Há um mal-entendido comum de que Platform Engineering "substitui" DevOps. Não substitui. DevOps é, antes de tudo, uma cultura: aproximar quem desenvolve de quem opera, reduzir silos, automatizar e assumir responsabilidade ponta a ponta pelo que se entrega.

O problema é que a interpretação literal de "você constrói, você opera" sobrecarregou os times de produto. Esperar que cada engenheiro domine Kubernetes, Terraform, malha de serviço, políticas de segurança e pipelines não escala — e drena energia que deveria ir para o produto.

Platform Engineering complementa o DevOps oferecendo uma plataforma de self-service que preserva a autonomia do time, mas remove a parte indiferenciada e repetitiva do trabalho operacional. O dev continua dono do seu serviço; só não precisa reinventar a infraestrutura toda vez. Os princípios do DevOps continuam valendo — a plataforma é o que os torna sustentáveis em escala.

Por que ganhou tração

Alguns fatores explicam por que o tema cresceu tanto:

Complexidade acumulada. A adoção de containers, Kubernetes, microsserviços e ferramentas de cloud-native multiplicou o que um time precisa saber. A carga cognitiva virou um custo real de produtividade.

Team Topologies. O livro de Matthew Skelton e Manuel Pais popularizou o conceito de platform team como um dos quatro tipos fundamentais de time (ao lado de stream-aligned, enabling e complicated-subsystem), cuja missão é justamente reduzir a carga cognitiva dos stream-aligned teams oferecendo serviços internos com boa experiência de uso. Esse vocabulário deu nome e forma ao que muitas empresas já tentavam fazer.

Reconhecimento da indústria. Consultorias como a Gartner vêm destacando as plataformas internas de desenvolvedor como uma tendência relevante para acelerar a entrega de software, o que ajudou a legitimar investimentos na área. Se você precisar de números específicos para embasar uma decisão, vale conferir os relatórios diretamente, em vez de confiar em estatísticas repassadas de segunda mão.

Backstage: um exemplo concreto

Um dos exemplos mais conhecidos de portal de desenvolvedor é o Backstage, criado originalmente pelo Spotify, open-sourced em 2020 e doado à Cloud Native Computing Foundation (CNCF), onde é mantido como projeto open source (atualmente em nível de incubação).

O Backstage oferece, entre outras coisas, um catálogo de software centralizado (serviços, libs, sistemas e seus donos), um sistema de templates para os golden paths (o "Software Templates"/Scaffolder) e o TechDocs, que trata documentação como código. Ele é extensível por plugins, o que permite integrar CI/CD, monitoramento e ferramentas internas em uma única interface.

Vale a ressalva: Backstage é um framework para construir um portal, não uma IDP pronta para usar. Ele resolve a camada de portal/catálogo, mas a plataforma completa ainda exige integrar provisionamento, pipelines e políticas por trás dele.

Resumindo

Platform Engineering trata a infraestrutura interna como produto. A IDP é a plataforma de self-service que materializa essa ideia, e os golden paths são os caminhos recomendados que embutem as boas práticas. Nada disso substitui o DevOps — pelo contrário, é o que torna a cultura DevOps sustentável quando o número de times e a complexidade técnica crescem. Ferramentas como o Backstage mostram que o ecossistema já amadureceu o suficiente para que você não precise começar do zero.