O time de plataforma da sua empresa cresceu. A infraestrutura amadureceu, o Kubernetes está estável, a observabilidade funciona. E, mesmo assim, toda semana chega o mesmo pedido no Slack: "preciso de um ambiente novo", "pode subir esse serviço pra mim", "como eu conecto isso ao banco de produção?". O time que deveria estar construindo plataforma virou uma central de atendimento.
Esse é o sintoma mais comum de Platform Engineering que parou na metade do caminho. A infraestrutura como código existe, mas o desenvolvedor ainda depende de alguém para usá-la. Este artigo explica o que são Golden Paths, por que eles são a peça que resolve esse gargalo, e como estruturar um caminho de autosserviço que os times realmente adotam — com os números de adoção que definem se uma iniciativa de plataforma dá certo ou vira prateleira.
Golden Path é um termo que vem da Spotify Engineering e hoje é padrão em Platform Engineering: é a rota opinativa e documentada para construir algo — do primeiro git push até o serviço rodando em produção, com segurança, observabilidade e compliance já embutidos no caminho.
Não é uma regra obrigatória. É a opção mais fácil. Um desenvolvedor que quer subir um novo microsserviço não abre um ticket para o time de infraestrutura — ele roda um template que já vem com CI/CD configurado, política de rede aplicada, dashboards de observabilidade criados e tags de custo corretas para o FinOps. Ele pode sair do caminho se precisar de algo diferente. Mas o caminho padrão é rápido, seguro e não depende de ninguém.
"The opinionated and supported path to build something" — a definição usada pelo State of Platform Engineering Report para descrever um golden path: o caminho com suporte oficial, mas nunca o único caminho possível.
A maioria das equipes de plataforma não fracassa por falta de tecnologia. Elas têm Terraform, Kubernetes, pipelines de CI/CD bem construídos. O problema é que esse investimento fica preso atrás de uma pessoa ou de um ticket. Sem um caminho de autosserviço, cada nova funcionalidade de infraestrutura vira mais um item na fila do time de plataforma — que devveria estar evoluindo a base, não atendendo demanda individual.
O State of Platform Engineering Report Vol. 4, que entrevistou 518 engenheiros globalmente, quantifica exatamente esse gargalo:
A diferença entre os dois extremos não é o orçamento de infraestrutura. É se o time de plataforma tratou o desenvolvedor como cliente interno — com uma experiência de uso pensada — ou como alguém que vai usar a plataforma porque não tem escolha.
1. Self-service com templates prontos, não documentação solta. Um golden path não é um documento no Confluence explicando o passo a passo. É um scaffold executável: funccloud new service gera o repositório, o pipeline, os manifests do Kubernetes e o dashboard de observabilidade já conectados. Documentação explica o caminho. Template constrói o caminho.
2. Guardrails automáticos, não aprovação manual. Segurança, LGPD e FinOps não devem ser um checklist que alguém revisa depois. Devem estar no template: rede já segmentada, secrets já cofrados, tags de custo já aplicadas, política de retenção de dados pessoais já configurada. O desenvolvedor não escolhe fazer errado porque o caminho fácil já é o caminho certo.
3. Developer Portal como camada de descoberta. Um golden path que existe mas ninguém sabe que existe não é adotado. É aqui que entram os Internal Developer Portals — Backstage (Spotify), Port, Cortex e ferramentas equivalentes — como catálogo central: todos os serviços, templates, donos e documentação em um único lugar, pesquisável, em vez de espalhados entre repositórios, wikis e conversas de Slack perdidas.
Dev abre ticket → espera na fila do time de plataforma → alguém provisiona manualmente → configuração inconsistente entre serviços → segurança revisada depois, se sobrar tempo.
Dev roda o template → ambiente sobe em minutos, já seguro e observável → time de plataforma foca em evoluir a base → consistência entre todos os serviços da empresa.
Golden Path não nasce como um portal completo com dezenas de templates. Nasce resolvendo o caminho mais repetido primeiro.
Mapeie o caminho mais pedido
Levante os 3 pedidos mais recorrentes ao time de plataforma nos últimos 3 meses (normalmente: subir novo serviço, provisionar banco, configurar ambiente de staging). Escolha o mais frequente para ser o primeiro golden path.
Construa o template com guardrails embutidos
Transforme esse caminho em um scaffold executável com CI/CD, observabilidade, segurança e tags de custo já configuradas por padrão. Teste com um time voluntário antes de anunciar para todos.
Publique no portal e meça adoção
Coloque o template no catálogo do Developer Portal (Backstage ou equivalente), comunique nos canais certos e acompanhe se a adoção é voluntária — não empurrada por mandato.
O relatório recomenda quatro métricas objetivas — e não opiniões — para saber se um golden path está de fato reduzindo o gargalo:
git push e o serviço em produçãoQuase um terço das equipes de plataforma não mede nenhuma dessas métricas. Sem elas, é impossível saber se o investimento em plataforma está reduzindo o gargalo ou só deslocando o problema — de "esperar o ticket" para "esperar o template funcionar".
Golden Paths não são sobre documentar processos. São sobre transformar o caminho certo no caminho mais fácil — de forma que segurança, observabilidade e FinOps deixem de depender de disciplina individual e passem a fazer parte da estrutura. O time de plataforma para de ser fila de atendimento e volta a fazer o que deveria: evoluir a base que sustenta todo o resto da engenharia.
A FuncCloud atua exatamente nessa transição: diagnóstico de maturidade de Platform Engineering, construção de golden paths e squads dedicados que aceleram sem virar mais um gargalo.
Falar com a FuncCloud →