Engenharia de Plataforma - Como justificar

平台工程：如何证明其价值

Baseado no livro “Engenharia de Plataforma”, de Camille Fournier e Ian Nowland. 基于 Camille Fournier 和 Ian Nowland 所著的《平台工程》（Platform Engineering）一书。

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. 近年来，构建软件变得异常简单。只需点击几下，我们就能配置数据库、队列、存储、可观测性系统和身份验证服务。这些功能大部分已通过云服务提供商和开源工具准备就绪。然而，这种便利性在维护方面也带来了一定的脆弱性。实际上，许多组织最终陷入了 Camille Fournier 和 Ian Nowland 所称的“泥泞中间地带”（Muddy Middle）：创建容易，演进昂贵。

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! 问题不在于基础组件。像 KMS、S3、Lambda、RDS、Kafka 等服务本身不是问题。它们创造了杠杆效应，让我们只需关注产品构建所需的部分。然而，每当团队需要使用这些服务时，他们就会编写一些代码来将应用程序连接到服务。我们称之为“胶水代码”（Glue code）。胶水代码是不可避免的，问题在于没有对其进行控制！

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. 想象一家拥有二十个应用程序的公司。所有应用都需要使用 KMS 加密数据。一种常见的方法是：应用 A → 自定义辅助工具 → KMS；应用 B → 自定义辅助工具 → KMS；应用 C → 自定义辅助工具 → KMS。起初，这看起来是个不错的方案，每个团队都能快速解决问题。几个月后，新的需求出现了：密钥轮换、新的日志标准、新的审计合同、权限变更。现在有二十种不同的实现需要更新。工作量增加了。我们不得不从几个冲刺（sprint）中抽出大量时间来彻底迁移这些项目中的胶水代码。

Centralizar a cola

集中化胶水代码

Uma alternativa é transformar esse conhecimento em um ativo compartilhado. Aplicação A/B/C → Crypto SDK → KMS. 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. 另一种选择是将这些知识转化为共享资产。应用 A/B/C → 加密 SDK → KMS。现在我们只有一个胶水代码点。开发应用程序的人员不再直接与 KMS 交互。修复 Bug 时，只会影响一个冲刺，交付周期（lead time）保持较短，在制品（WIP）也保持稳定，即使在危机场景下也是如此。

Nem tudo precisa ser uma feature

并非所有东西都需要是功能（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. 我喜欢从一个简单的前提出发：所有与产品功能没有直接关系的东西都应该是无聊的、重复的且集中的。例如：日志、可观测性、加密、功能开关（Feature Flags）、身份验证、流水线、仓库治理。这些组件都不会为公司带来竞争优势。价值在于以一致的方式执行它们，这才是公司获益的地方。

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. 平台应专注于为用户提供更好的替代方案。使用企业级的日志或加密抽象不应该变得更复杂。使用这些抽象应该比直接使用 KMS 库（例如）更好、更容易。

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. 关于内部平台的研究非常有趣，我学到了很多关于大公司如何在充满变数的时代保持服务一致性的知识。此外，在代码已成为商品的当前环境下，面对海量信息，保持质量变得越来越困难，这个主题显得尤为重要。一个专注且规划良好的平台，并对创新保持开放，在我看来是人工智能时代生成真正企业级软件的最佳方式之一。没有平台，就会有噪音。而噪音和技术债务是扩展速度最快的东西。