Em 2018, o Spotify tinha crescido para 200 squads de engenharia e um problema que nenhuma empresa de software havia resolvido antes: como manter produtividade e consistência operacional em escala sem centralização que cria gargalos? A resposta que desenvolveram — e open-sourceariam em 2020 como Backstage — era um developer portal centralizado que consolidava toda a informação que um engenheiro precisava: quais serviços existem, quem os possui, como fazer deploy, onde ver os logs, como provisionar um novo serviço. O insight do Spotify não era sobre ferramentas — era sobre tratar a experiência do desenvolvedor como produto, com product management, métricas de adoção, e ciclo de feedback.
Platform Engineering é a disciplina de construir e operar Internal Developer Platforms (IDPs) — o conjunto de ferramentas, processos, e abstrações que permitem que times de produto entreguem software de forma autônoma, sem precisar entender a complexidade de infraestrutura subjacente. É a resposta à pergunta: "como escalar DevOps além de um time pequeno?"
A evolução: de DevOps a Platform Engineering
A jornada típica de um time de engenharia em crescimento:
Fase 1 — Startup (1-10 engenheiros): todos fazem tudo. Não há separação entre "infra" e "produto". Qualquer engenheiro faz deploy, configura monitoring, e resolve incidentes. Funciona porque a complexidade é baixa e a comunicação é zero-custo.
Fase 2 — DevOps (10-50 engenheiros): surge um time de infraestrutura ou "DevOps" — mas o modelo é de serviço: squads de produto fazem tickets para o time de infra quando precisam de algo. O time de infra vira gargalo. "DevOps" se torna sinônimo de "operations renomeado".
Fase 3 — SRE (50-200 engenheiros): times de SRE ficam embedded em squads de produto. Melhor que tickets, mas o conhecimento fica fragmentado. O time de produto desenvolve competência operacional profunda, mas há duplicação de esforço em 10 squads resolvendo o mesmo problema de "como fazer deploy seguro".
Fase 4 — Platform Engineering (200+ engenheiros): um time de plataforma constrói ferramentas e abstrações que todo time de produto usa. Em vez de cada squad resolver "como fazer deploy", a plataforma oferece um botão de "criar novo serviço" que já inclui deploy pipeline, monitoring, alertas, runbook template, e integração com o cost dashboard. Squads de produto focam em valor de negócio; a plataforma absorve a complexidade operacional.
Internal Developer Platform (IDP)
Um IDP não é uma ferramenta — é um sistema composto por múltiplas ferramentas integradas que oferece uma experiência coerente para o desenvolvedor. Os componentes típicos:
- Developer Portal (Backstage): catálogo de serviços, templates para criar novos serviços, documentação, e integração com outras ferramentas
- CI/CD self-service: pipeline padronizado que o desenvolvedor usa sem precisar configurar do zero
- Secrets management: interface para acessar secrets sem precisar saber que estão no Vault
- Observabilidade integrada: logs, métricas, e tracing disponíveis automaticamente para qualquer serviço criado via plataforma
- Cost visibility: dashboard de custo por serviço, sem que o desenvolvedor precise configurar tags manualmente
A característica definidora de um IDP bem feito: o desenvolvedor cria um novo serviço, faz o primeiro deploy, e já tem todas essas capacidades disponíveis — sem precisar configurar nada ou abrir ticket para o time de plataforma.
Backstage — o developer portal open source do Spotify
Backstage (CNCF Graduated Project desde 2022) é o framework mais adotado para developer portals. Sua arquitetura é baseada em plugins: cada integração (GitHub, Jenkins, PagerDuty, Datadog, Kubernetes) é um plugin que adiciona funcionalidade ao portal central.
O componente central do Backstage é o Software Catalog — um catálogo de todos os serviços, bibliotecas, websites, e pipelines da organização, com informações de ownership, documentação, e status:
# catalog-info.yaml — cada serviço tem esse arquivo no repositório
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: api-pagamentos
description: API de processamento de pagamentos
annotations:
github.com/project-slug: minha-org/api-pagamentos
pagerduty.com/service-id: P123456
backstage.io/techdocs-ref: dir:.
tags:
- payments
- critical
- go
links:
- url: https://grafana.minha-empresa.com/d/pagamentos
title: Dashboard de Pagamentos
icon: dashboard
spec:
type: service
lifecycle: production
owner: team-financeiro
system: plataforma-financeira
dependsOn:
- component:banco-de-dados-financeiro
- resource:fila-pagamentosCom o Software Catalog populado, um engenheiro novo na empresa pode abrir o Backstage e encontrar: todos os serviços existentes, quem é responsável por cada um (sem precisar perguntar), o status atual de cada serviço, como fazer deploy, e links para documentação e dashboard. O onboarding que levava semanas passa a levar dias.
Golden paths — a opinião que reduz fricção
Um "golden path" é um caminho pré-configurado e recomendado para realizar uma tarefa comum — criar um novo serviço, adicionar um banco de dados, configurar autenticação. O conceito é deliberadamente opinionado: não é "faça do jeito que quiser", é "se seguir esse caminho, tudo funciona automaticamente e sem suporte adicional do time de plataforma".
No Backstage, golden paths são implementados como Software Templates:
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: novo-servico-go
title: Novo serviço Go
description: Cria repositório, pipeline CI/CD, namespace K8s, e monitoring
spec:
owner: team-platform
type: service
parameters:
- title: Informações do Serviço
required: [name, owner, description]
properties:
name:
type: string
pattern: '^[a-z][a-z0-9-]*$'
owner:
type: string
ui:field: OwnerPicker
description:
type: string
steps:
- id: fetch-base
name: Fetch template base
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
- id: create-repo
name: Criar repositório GitHub
action: github:repo:create
input:
repoUrl: github.com?owner=minha-org&repo=${{ parameters.name }}
defaultBranch: main
- id: register
name: Registrar no catálogo
action: catalog:register
input:
repoContentsUrl: ${{ steps.create-repo.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yamlO desenvolvedor preenche um formulário no Backstage, clica em "Criar", e em 2 minutos tem: repositório no GitHub com estrutura padrão, pipeline CI/CD configurado, namespace Kubernetes com RBAC, ServiceMonitor para Prometheus, e catálogo atualizado. Sem tickets, sem espera pelo time de plataforma.
Team Topologies — platform team como stream-enabling
Matthew Skelton e Manuel Pais em Team Topologies (2019) definem quatro tipos de times: stream-aligned (squads de produto), platform, enabling, e complicated-subsystem. O insight chave é que o platform team não é um time de serviço — é um time de produto que tem outros times como clientes.
A diferença prática entre "plataforma como serviço" e "plataforma como produto":
| Plataforma como Serviço | Plataforma como Produto | |
|---|---|---|
| Modelo de interação | Tickets e aprovações | Self-service com documentação |
| Como o time aprende | Volume de tickets | Métricas de adoção e feedback |
| Sucesso medido por | Tempo de resolução de tickets | Carga cognitiva reduzida nos squads |
| O que o time de produto faz | Aguarda a plataforma fazer algo | Usa a plataforma autonomamente |
| Evolução | Reativa (responde a problemas) | Proativa (antecipa necessidades) |
O objetivo do platform team é reduzir a carga cognitiva dos squads de produto. Cada ferramenta, processo, ou decisão que a plataforma absorve é carga cognitiva que os squads não precisam carregar. O time de produto não precisa saber que secrets estão no Vault, que o cluster usa Calico para NetworkPolicies, ou que os logs vão para Loki — eles só precisam saber que "funciona".
Como medir adoção e valor
Platform teams que não medem adoção constroem para si mesmos. Métricas relevantes:
- Adoption rate: % de squads que usam cada golden path vs os que configuraram do próprio jeito
- Time to production (novos serviços): tempo desde "ideia de novo serviço" até "primeiro deploy em produção" — deve reduzir à medida que a plataforma matura
- Support ticket volume: tickets abertos para a plataforma devem diminuir à medida que o self-service melhora
- Developer NPS: os squads acham a plataforma útil? Pesquisas trimestrais de satisfação
- Mean time to onboard: tempo para um engenheiro novo fazer o primeiro deploy de forma autônoma
Times de plataforma que constroem sem feedback dos usuários constroem a plataforma perfeita para si mesmos — que os squads de produto ignoram. O golden path que ninguém usa é pior que nenhum golden path: ele cria fricção para quem quer fazer do jeito próprio e não gera nenhum valor. O time de plataforma deve tratar squads de produto como clientes: entrevistar regularmente, medir adoção, e estar disposto a abandonar abstrações que não foram adotadas. O sucesso não é construir algo — é ter squads que escolhem usar o que você construiu.
Decisões de engenharia
Perguntas de entrevista
O que é platform engineering e como difere do modelo DevOps tradicional com time de infraestrutura?
Platform engineering é a disciplina de construir e operar Internal Developer Platforms — produtos de infraestrutura que times de produto usam de forma autônoma, sem intervenção do time de plataforma. O time de plataforma trata outros times como clientes: constrói abstrações, documenta, mede adoção, e itera com base em feedback.
O modelo DevOps tradicional com time de infraestrutura opera como serviço: squads abrem tickets quando precisam de algo (novo banco, novo pipeline, nova configuração), o time de infra executa, e o squad aguarda. Esse modelo tem dois problemas em escala: o time de infra vira gargalo (toda requisição passa por eles), e o conhecimento fica centralizado (squads não desenvolvem autonomia operacional).
A diferença fundamental é o modo de interação: serviço é síncrono e humano (tickets, aprovações, reuniões), plataforma é assíncrona e automática (templates, APIs, documentação). Em platform engineering, o sucesso é medido por ausência de interação — squads que nunca precisam abrir ticket para a plataforma porque tudo já funciona out-of-the-box. Isso é estruturalmente oposto ao modelo de serviço onde o sucesso era medido por velocidade de resolução de tickets.
O que é um golden path, por que ser opinionado é uma vantagem, e como balancear padronização com flexibilidade?
Um golden path é um caminho pré-configurado e recomendado para realizar uma tarefa comum — criar um serviço, configurar autenticação, adicionar uma fila. "Golden" porque é onde a maioria dos casos de uso se encaixa; "path" porque é um caminho, não um muro — squads podem desviar, mas há custo implícito em fazê-lo (sem suporte da plataforma para o desvio).
Ser opinionado é uma vantagem porque reduz a carga cognitiva do desenvolvedor. Um golden path que oferece 7 opções de banco de dados, 3 opções de messaging, e 4 opções de autenticação transfere o problema de escolha para o desenvolvedor — que agora precisa avaliar trade-offs que o time de plataforma já avaliou. A melhor abstração é aquela que o desenvolvedor usa sem pensar; a pior é aquela que exige que ele entenda a implementação para escolher corretamente.
O balanceamento vem com dados: um único golden path cobre 80% dos casos de uso. Para o restante 20%, você observa padrões de desvio: se 5 squads adicionaram PostgreSQL de forma diferente, é sinal para criar uma variante do golden path para esse caso. Cada variante adicional é um golden path a mais para manter — só adicione quando o caso de uso é frequente o suficiente para justificar o overhead.
Como o Backstage Software Catalog resolve o problema de descoberta de serviços em organizações grandes?
Em organizações com centenas de serviços, o problema de descoberta é sutil mas custoso: um engenheiro precisa de 2h para descobrir quem é o dono de um serviço que está causando latência, ou precisa de 1 semana para encontrar todos os serviços que dependem de um banco de dados que vai ser migrado. Esse tempo invisível se acumula: 200 engenheiros × 2h/semana = 400h de produtividade perdida por semana.
O Software Catalog resolve isso com um modelo de dados estruturado: cada serviço tem um arquivo catalog-info.yaml no repositório que declara owner, lifecycle, dependências, links para documentação e dashboards, e anotações para integrações (PagerDuty, GitHub, Datadog). O catálogo é então o único lugar que um engenheiro precisa consultar para qualquer questão sobre qualquer serviço.
O benefício não é apenas a busca — é a visão de mapa: "quais serviços dependem do serviço X?" (análise de impacto antes de uma migração), "quais serviços têm lifecycle deprecated?" (dívida técnica visível), "quem é o owner de cada serviço?" (sem precisar perguntar em Slack). O catálogo transforma conhecimento tribal em conhecimento estruturado e consultável.
Como um platform team deve medir se está gerando valor, e quais são as métricas mais importantes?
O erro mais comum é medir output (quantos templates criamos, quantos plugins instalamos) em vez de outcome (os squads de produto são mais produtivos?). Métricas de output são fáceis de coletar e enganosas — você pode ter construído muito sem gerar valor nenhum.
As métricas de outcome mais relevantes: (1) Time to production para novos serviços — quanto tempo desde "vamos criar um novo serviço" até o primeiro deploy em produção? Uma plataforma madura reduz isso de semanas para horas. (2) Adoption rate — quantos squads usam o golden path vs criaram do próprio jeito? Abaixo de 60% de adoção indica que o golden path não está servindo às necessidades reais. (3) Volume de tickets de plataforma — deve diminuir à medida que o self-service melhora; se está crescendo apesar de novos recursos, há um problema de discovery ou UX. (4) Developer NPS — pesquisa trimestral: "você recomendaria a plataforma para um colega?" Abaixo de 30 é sinal de problemas sérios.
O melhor feedback é qualitativo: entrevistar squads de produto mensalmente sobre suas maiores fricções. As métricas quantitativas confirmam tendências; as entrevistas revelam causas.
Qual é o papel de um engenheiro sênior em um platform team e como ele difere de um engenheiro sênior em um squad de produto?
Um engenheiro sênior em platform team tem um multiplicador de impacto diferente: em vez de impactar diretamente o produto final, ele impacta a produtividade de todos os outros engenheiros. Uma melhoria no golden path que economiza 2h de setup para cada novo serviço, multiplicada por 50 novos serviços por ano, economiza 100h de tempo de engenharia — invisível em qualquer métrica de produto, mas real.
As diferenças práticas: (1) Os clientes são internos — o platform engineer precisa entender as necessidades dos outros times, não dos usuários finais. Empatia com o desenvolvedor é tão importante quanto empatia com o usuário em um squad de produto. (2) Backward compatibility é crítica — uma mudança incompatível no golden path pode quebrar 20 squads simultaneamente. Platform engineers pensam muito mais em versioning e migração gradual do que engenheiros de produto. (3) Documentação é produto — uma feature que ninguém sabe usar não gera adoção. Escrever boa documentação e criar bons exemplos é tão importante quanto implementar a feature. (4) O incentivo é remover fricção, não adicionar features — menos código gerenciado pela plataforma é frequentemente melhor do que mais código.
Exercícios práticos
Instale o Backstage localmente (npx @backstage/create-app) e configure a integração com GitHub. Para três repositórios reais (ou criados para o exercício), adicione um arquivo catalog-info.yaml em cada um com: name, description, owner, tipo (service/library), lifecycle (development/production), e pelo menos uma dependência entre eles. Configure o Backstage para descobrir esses arquivos via um location YAML. Verifique que o catálogo mostra os serviços, seus owners, e o grafo de dependências entre eles.
Crie um Software Template no Backstage com scaffolder que, ao ser executado: (a) cria um repositório no GitHub com estrutura padrão de projeto Go (main.go, go.mod, Dockerfile, .github/workflows/ci.yml com lint e test); (b) cria o arquivo catalog-info.yaml preenchido com o nome e owner informados no formulário; (c) registra o novo serviço no catálogo automaticamente. O formulário deve pedir: nome do serviço (validado com regex), owner (usando OwnerPicker), e descrição. Teste criando um serviço real via o template.
Realize uma sessão estruturada de 60 minutos com um squad de produto real (ou simulado) para mapear a carga cognitiva operacional. Liste todas as tarefas que o squad executa que não são diretamente relacionadas ao produto (configurar pipelines, gerenciar secrets, configurar monitoring, resolver problemas de infraestrutura). Para cada tarefa, estime: frequência (diária/semanal/mensal), tempo médio gasto, e nível de frustração (1-5). Identifique as 3 tarefas com maior impacto (frequência × tempo × frustração) e proponha como um IDP poderia endereçar cada uma.
Critério: Documento com matriz de tarefas operacionais mapeadas com frequência e tempo; cálculo de horas/mês gastas em tarefas não-produto; as 3 propostas de IDP têm critério de sucesso definido (ex: "reduzir de 4h para 15min o setup de um novo serviço") e estimativa de adoção.Para uma plataforma hipotética (ou real) com um golden path de criação de serviços, defina o sistema de métricas de adoção. Implemente pelo menos três das cinco métricas discutidas: adoption rate (consultando quantos repositórios têm catalog-info.yaml vs total), time to production (analisando tempo entre PR de criação e primeiro deploy em produção via GitHub Actions logs), ticket volume (consultando um sistema de tickets ou Slack), Developer NPS (criando uma pesquisa em Google Forms), e mean time to onboard (entrevistando engenheiros recentes). Configure um dashboard (Grafana ou Google Data Studio) que consolida essas métricas.
Critério: Dashboard com pelo menos três métricas de adoção atualizadas automaticamente ou manualmente de forma reproduzível; baseline das métricas no momento atual documentado; metas definidas para 3 e 6 meses; processo definido para coletar as métricas mensalmente com responsável designado.Construa um IDP mínimo viável combinando: Backstage com Software Catalog e pelo menos um Software Template, integração com GitHub Actions para CI/CD self-service, e integração com um sistema de secrets (pode ser GitHub Secrets gerenciados automaticamente pelo template). O objetivo é que um desenvolvedor novo consiga, em menos de 30 minutos sem suporte: criar um novo serviço via template no Backstage, ter o pipeline CI configurado automaticamente, e ver o serviço no catálogo com links para repositório e pipeline. Documente o processo com screenshots e meça o tempo real do fluxo.
Critério: Um desenvolvedor sem experiência prévia com a plataforma consegue criar um serviço funcional em menos de 30 minutos seguindo a documentação; o pipeline CI roda automaticamente no primeiro commit; o serviço aparece no catálogo; o processo é repetível e documentado para que o próximo desenvolvedor não precise de suporte.Referências
- book Matthew Skelton & Manuel Pais — Team Topologies
- docs Backstage Documentation — Software Templates
- article CNCF Platforms White Paper
- article Humanitec — State of Platform Engineering Report 2023
- docs Backstage — Software Catalog Documentation
- article Charity Majors — Platform Engineering Is Not About Kubernetes
- video KubeCon 2022 — Building an Internal Developer Platform at Scale
- article Martin Fowler — Internal Developer Platform
- article InfoQ — State of Platform Engineering Survey 2024
- article Spotify Engineering — How We Use Backstage at Spotify
- docs Backstage — TechDocs Plugin
- book Luca Galante & Paula Kennedy — Platform Engineering on Kubernetes