Baseado no livro "Engenharia de Plataforma", de Camille Fournier e Ian Nowland.

O paradoxo moderno

Nos últimos anos ficou absurdamente fácil construir software.
Com poucos cliques conseguimos provisionar:

• Bancos de dados
• Filas
• Armazenamento
• Sistemas de observabilidade
• Serviços de autenticação

A maior parte dessas capacidades já existe pronta através de provedores de nuvem e ferramentas open source.

Porém, essa facilidade também trouxe uma certa fragilidade quando o assunto é manutenção. Na prática, muitas organizações acabam entrando no que Camille Fournier e Ian Nowland chamam de Pântano Generalizado (Muddy Middle): criar é fácil, evoluir é caro.

O problema não são os primitivos

Serviços como:

• KMS
• S3
• Lambda
• RDS
• Kafka

não são o problema. Criam alavancagem e nos permitem nos preocupar somente com o necessário para a construção do produto.
Porém, cada vez que um time precisa utilizar um desses serviços, ele escreve um pouco de código para conectar sua aplicação ao serviço. Chamamos isso de cola.

A cola é inevitável. O problema está em não controlá-la!

A multiplicação da cola

Imagine uma empresa com vinte aplicações.

Todas precisam criptografar dados utilizando KMS.
Uma abordagem comum é:

Aplicação A → Helper próprio → KMS
Aplicação B → Helper próprio → KMS
Aplicação C → Helper próprio → KMS

Inicialmente parece uma ótima solução.
Cada equipe resolve seu problema rapidamente.

Meses depois surgem novos requisitos:

• Rotação de chaves
• Novo padrão de logs
• Novo contrato de auditoria
• Mudança de permissões

Agora existem vinte implementações diferentes para atualizar. O trabalho aumentou. Vamos tirar um bom tempo de algumas sprints para conseguir migrar totalmente essa cola dos projetos.

Centralizar a cola

Uma alternativa é transformar esse conhecimento em um ativo compartilhado.

Aplicação A ─┐
Aplicação B ─┼─> Crypto SDK → KMS
Aplicação C ─┘

Agora temos somente um ponto de cola. Quem desenvolve nossos aplicativos simplesmente não interage diretamente com o KMS.
Ao corrigir um bug, somente uma sprint é impactada, o lead time permanece pequeno e o WIP se mantém estabilizado, até mesmo em cenários de crise.

Nem tudo precisa ser uma feature

Gosto de partir de uma premissa simples:

Tudo que não tenha relação direta com a feature do produto

deveria ser chato, repetitivo e centralizado.
Alguns exemplos:

• Logs
• Observabilidade
• Criptografia
• Feature Flags
• Autenticação
• Pipelines
• Governança de repositórios

Nenhum desses componentes gera diferencial competitivo para a empresa. O valor está em executá-los de forma consistente. É nisso que a companhia ganha.

Governança também é cola

Esse mesmo raciocínio aparece fora do código.
Um exemplo clássico é a criação de repositórios. Em muitas empresas, o processo acontece assim:

• Repositório criado manualmente
• Permissões configuradas manualmente
• Pipelines configuradas manualmente
• Scripts adicionados manualmente Cada novo projeto se torna uma nova oportunidade para inconsistências.

Com o tempo surgem perguntas simples que ninguém consegue responder:

• Quem possui acesso?
• Qual padrão de pipeline está sendo utilizado?
• Quais verificações são obrigatórias?
• Quais repositórios estão fora do padrão?

Não existe nenhum problema na stack ou na solução em si, e sim na cola espalhada por todos os serviços da companhia.

Engenharia de Plataforma como alavancagem

A plataforma interna não existe para esconder a tecnologia. Ela existe para centralizar e filtrar ruídos.

O desenvolvedor da solução não deveria pensar em como a empresa lida com logs, mas sim naquela solução específica. Ele deve ter um ambiente seguro e produtivo para se preocupar o máximo possível com a entrega de inovação.

A Engenharia de Plataforma permite que um pequeno grupo de engenheiros consiga reduzir o trabalho de toda uma companhia, convertendo tempo de troubleshooting de ferramentas em entrega de valor para o produto.

Entender seus colaboradores e equipes como clientes

A plataforma deve ter como foco oferecer uma alternativa melhor para o usuário. Não deveria ser mais complexo utilizar a abstração corporativa de logs ou de criptografia.

Utilizar essas abstrações deve ser melhor e mais fácil do que usar diretamente a biblioteca do KMS, por exemplo.

Conclusão

O estudo sobre plataformas internas está sendo muito interessante e estou aprendendo muito sobre como grandes players conseguem manter serviços consistentes, mesmo em um momento de tantas novidades.

Além disso, esse tema me parece extremamente importante no cenário atual, onde código virou commodity e estamos cada vez mais enfrentando dificuldades para manter a qualidade diante de um volume tão grande de informação.

Uma plataforma focada e bem planejada, com abertura para inovações, me parece uma das melhores formas de gerar software corporativo de verdade na era da IA.

Sem plataforma, existe ruído.

E uma coisa que escala rapidamente é o ruído e dívida técnica.