Cover do episódio 172: Golden paths: o que são e por que o melhor código de plataforma é o que os devs não precisam escrever
#17211 de março, 20244 min leituraTecnologia sem HypeS7 · 2023–2024

Golden paths: o que são e por que o melhor código de plataforma é o que os devs não precisam escrever

A ideia mais contra-intuitiva de platform engineering: quanto menos código os times de produto precisam escrever para infraestrutura, melhor você fez seu trabalho.

Golden PathPlatform EngineeringDeveloper ExperienceAutomaçãoInfraestrutura

Existe uma frase que guia muito do que eu faço em plataforma: "o melhor código de plataforma é o que os desenvolvedores de produto não precisam escrever."

Quando eu conto isso para devs fora de plataforma, a reação geralmente é confusão. Se você não está escrevendo código, o que está fazendo?


Golden path é o conceito que responde a essa pergunta. Um golden path é o caminho de menor resistência para fazer algo corretamente. Em vez de cada time descobrir como fazer deploy seguro, como instrumentar um serviço, como autenticar entre serviços — você constrói esse caminho uma vez, da forma correta, e coloca no meio da vida de todos os desenvolvedores.

O resultado: os times de produto fazem a coisa certa automaticamente, não porque aprenderam a teoria correta, mas porque é o jeito mais fácil disponível.


O exemplo mais concreto: deploy. Em sistemas sem golden path, cada serviço tem seu próprio script de deploy, sua própria lógica de rollback, seus próprios checks de saúde. Isso funciona até aparecer um problema de segurança que precisa ser aplicado em todos os serviços ao mesmo tempo — aí você tem dezenas de scripts diferentes para atualizar, testados de formas diferentes, com comportamentos sutilmente diferentes.

Com golden path, o deploy é uma abstração: você descreve o que quer deployar, e o sistema executa da forma padronizada, segura, com observabilidade embutida. Mudar o golden path atualiza automaticamente todos os times que o usam.


A tentação de platform engineering é construir coisas genéricas e poderosas. "Nossa solução vai funcionar para qualquer caso de uso." Isso é uma armadilha. Quanto mais genérico, mais complexo de usar, mais documentação necessária, mais treinamento necessário.

Golden paths são opinionados por design. Eles dizem: "esta é a forma recomendada de fazer isso aqui". Não a única forma — se alguém tem um caso de uso legítimo que o golden path não cobre, eles podem sair do caminho. Mas para o caso de uso típico, o golden path é mais fácil do que a alternativa.


O que diferencia um bom golden path de um ruim é a fidelidade à experiência do desenvolvedor. Um golden path ruim é uma abstração que resolve o problema técnico mas cria atrito de uso — documentação confusa, erros de mensagem opacos, comportamento inesperado em edge cases. O desenvolvedor usa uma vez, tem dificuldade, e nunca mais usa.

Um bom golden path parece simples porque o trabalho difícil está escondido embaixo. A complexidade de segurança, observabilidade, rollback — está lá, mas você não precisa pensar nela para o caso típico. Você só percebe que está lá quando precisa.


Medir sucesso de golden path é diferente de medir sucesso de feature de produto. Você não mede linhas de código do golden path. Você mede adoção: quantos serviços estão usando? Satisfação: devs estão reclamando ou elogiando? Redução de incidentes: os problemas que o golden path previne estão diminuindo? Velocidade: times estão deployando mais rápido ou mais lento desde que começaram a usar?

Essas métricas são mais difusas do que "feature X tem N usuários", mas são o que importa para plataforma.


O que aprendi fazendo esse trabalho: platform engineering é empatia técnica. Você está construindo para outros desenvolvedores, não para usuários finais. Para fazer bem, você precisa entender a vida deles — o que os frustra, onde eles perdem tempo, o que eles já tentaram e abandonaram. Você descobre isso falando com eles, observando como usam o que você construiu, e tratando feedback como dado, não como crítica.

O melhor investimento que você pode fazer em plataforma não é técnico. É passar tempo com os times que usam o que você constrói.


Essa semana: se você mantém qualquer tipo de ferramenta interna ou abstração que outros devs usam, pergunta para três deles esta semana: qual é a parte mais frustrante de usar isso? O que eles te disserem vai ser mais valioso do que qualquer análise que você faça sozinho.