Blog/Artigos · Cloud e Plataforma
O IDP, os golden paths, o Backstage e a plataforma tratada como produto, com Team Topologies e a lição de carga cognitiva.
O profeta manda aplainar uma estrada no deserto: tirar a pedra, aterrar o buraco, endireitar o caminho para que a passagem seja possível sem sofrimento. É a imagem exata do que Platform Engineering faz pelo desenvolvedor. Sem estrada, cada time abre a própria trilha na areia: configura pipeline do zero, decifra a nuvem sozinho, reinventa o mesmo deploy que o time ao lado já reinventou. Com estrada aplainada, o desenvolvedor anda sozinho, rápido e seguro, sem precisar ser especialista em infraestrutura para subir um serviço. A plataforma não é para impressionar; é para que o caminho deixe de ser sofrimento e a entrega volte a fluir.
O DevOps prometeu que cada time cuidaria da própria infraestrutura, e a promessa cobrou uma conta escondida: carga cognitiva. Pedir que quem escreve a regra de negócio também domine Kubernetes, Terraform, rede de nuvem, observabilidade e pipeline é pedir demais, e o resultado é cada time reinventando mal o que o vizinho reinventou mal. O livro Team Topologies, de Matthew Skelton e Manuel Pais, deu nome ao remédio: um platform team cujo trabalho é reduzir a carga cognitiva dos times de fluxo, oferecendo o difícil como serviço fácil de consumir.
Platform Engineering é a disciplina que operacionaliza isso. Não é o velho time de infraestrutura com nome novo; é um time que trata a plataforma interna como produto e os outros times como clientes. O Thoughtworks colocou o tema no Radar como tendência dominante, e a pesquisa de mercado confirma: as empresas que entregam rápido não são as que deixam cada time se virar, são as que aplainaram a estrada para que o time de fluxo ande sem tropeçar na infraestrutura a cada passo.
O coração de Platform Engineering é o golden path, o caminho dourado: a maneira recomendada, pavimentada e testada de fazer a coisa comum. Criar um serviço novo, com pipeline, observabilidade, segurança e deploy já configurados, deveria ser um comando ou um clique, não uma semana de configuração copiada de outro repositório. O golden path é opinativo de propósito: ele escolhe as tecnologias, embute as boas práticas e entrega o serviço já nos trilhos, com o difícil resolvido por baixo.
A palavra que define o golden path é pavimentado, não obrigatório. O desenvolvedor pode sair da estrada quando o caso exigir, mas paga o custo de abrir a própria trilha, e a maioria não vai querer. É assim que a plataforma alinha o incentivo: o caminho seguro e padronizado também é o caminho mais fácil e mais rápido. Quando o certo é o mais cômodo, a padronização acontece por gravidade, sem imposição. Governança que depende de proibir cansa; golden path que depende de facilitar dura.
Sair da estrada é permitido, mas custa abrir a própria trilha. Quando o caminho seguro também é o mais fácil, a padronização acontece por gravidade.
A estrada precisa de uma porta de entrada, e essa porta é o IDP, a Internal Developer Platform, a plataforma interna de desenvolvimento. Ela é a camada de autosserviço onde o desenvolvedor pede o que precisa: um serviço novo, um banco, um acesso, um ambiente. O Backstage, criado pela Spotify e doado à CNCF, virou o portal de referência do mercado: um catálogo de serviços que responde quem é dono de quê, templates de software que materializam os golden paths, e documentação técnica que vive junto do código, o TechDocs.
O ganho do catálogo é o fim da pergunta que assombra toda empresa grande: de quem é este serviço, e o que ele depende? Sem catálogo, essa resposta mora na cabeça de alguém que já saiu da empresa. Com catálogo, é uma busca. O IDP não precisa ser o Backstage, e nem sempre precisa ser uma ferramenta única; o que ele precisa ser é uma porta onde o difícil está a um clique e o mapa de tudo está visível. A porta única é o que transforma uma coleção de ferramentas de infraestrutura numa plataforma de verdade.
O erro que mata Platform Engineering é tratar a plataforma como projeto de infraestrutura, construído uma vez e imposto. Plataforma é produto: tem clientes internos, que são os times de fluxo; tem que resolver a dor deles, não a que o platform team acha bonita; e vive ou morre pela adoção. Se o golden path é pior que abrir a própria trilha, ninguém usa, e a plataforma vira prateleira cara. A régua não é quantas features ela tem, é quantos times a escolhem por vontade própria.
Isso exige medir a experiência do desenvolvedor, a DevEx, com a mesma seriedade com que se mede uptime: quanto tempo do pedido ao serviço no ar, quantos passos manuais sobraram, qual a satisfação de quem usa. E exige a humildade do thinnest viable platform, a plataforma mais fina que resolve a dor de hoje, em vez do sonho de engenharia que resolve a dor imaginada de depois. A plataforma que tenta prever tudo entrega tarde e serve a ninguém; a que resolve a dor real de agora ganha adoção e cresce com ela.
| Aspecto | Plataforma como projeto | Plataforma como produto |
|---|---|---|
| Quem manda | o time de infra decide o que é bom | o time de fluxo, cliente, define a dor a resolver |
| Sucesso | entregue no prazo do projeto | adoção voluntária e DevEx que melhora |
| Escopo | tenta prever tudo, entrega tarde | o mais fino que resolve a dor de hoje, e cresce |
| Golden path | imposto, e contornado às escondidas | mais fácil que a alternativa, escolhido por gravidade |
| Evolução | congela após a entrega | roadmap vivo guiado pelo feedback do usuário interno |
Plataforma não nasce pronta; amadurece. No começo é um punhado de scripts compartilhados e boa vontade. No meio é um golden path real e um portal de autosserviço que tira ops do caminho crítico. No topo é uma plataforma tratada como produto, com DevEx medida, scorecards de saúde e a IA acelerando tanto quem constrói a plataforma quanto quem a consome. Pular etapa não funciona: portal bonito sem golden path por baixo é fachada, e golden path sem adoção é desperdício.
O sinal de que a plataforma venceu é silencioso: o desenvolvedor para de falar de infraestrutura. Ele sobe serviço, faz deploy, investiga incidente e nunca precisa pensar na estrada por baixo dos pés, porque ela está aplainada. Quando isso acontece, a carga cognitiva voltou para onde deveria estar, no problema de negócio, e a plataforma cumpriu o profeta: aplainou a estrada no deserto para que a passagem fosse possível sem sofrimento.
Platform Engineering aplaina a estrada no deserto para o time de fluxo andar sozinho, sem tropeçar na infraestrutura a cada passo. Team Topologies deu o porquê, a carga cognitiva; o golden path deu o como, o caminho pavimentado e opinativo que é mais fácil que a alternativa; o IDP e o Backstage deram a porta única; e tratar a plataforma como produto, com DevEx medida, deu a régua. A IA gera o scaffold e revela onde a estrada tem buraco. Mas decidir qual dor atacar primeiro, e resistir ao sonho de engenharia que serve a ninguém, continua sendo julgamento de produto de quem constrói a plataforma.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaכְּתָב
Infra criada no clique não se reproduz e ninguém sabe explicar. IaC escreve a infraestrutura como código versionado e revisável, e o que está escrito se materializa igual toda vez. O perigo mora no state, e a maturidade em tratar servidor como gado, não como bicho de estimação.
Cloud e Plataformaשׁוּב
GitOps faz do Git a única fonte de verdade do que roda, e um controlador puxa a realidade de volta ao que está escrito, sem parar. Deploy vira commit, rollback vira reverter, e o drift se corrige sozinho. O repositório declara, o laço reconcilia.
