摘要：告别无效平台！本文揭示Platform Engineering成功的关键：加速数字化转型，提供如Netflix般丝滑的开发者体验。诊断工具碎片化，强调业务对齐，开源整合。未来平台即生态，拥抱DevOps，构建以用户为中心的内部平台，体验至上！
告别无效平台！本文揭示Platform Engineering成功的关键：加速数字化转型，提供如Netflix般丝滑的开发者体验。诊断工具碎片化，强调业务对齐，开源整合。未来平台即生态，拥抱DevOps，构建以用户为中心的内部平台，体验至上！
译自：To Fix Platform Engineering, Build What Users Actually Want
作者：Shweta Vohra
我曾与一家汽车客户合作，他们的工程团队有一个雄心勃勃的目标：快速构建新的微服务和一个外部合作伙伴平台。但“快速”说起来容易做起来难。
虽然团队对交付功能感到兴奋，但他们不断被基础设施决策的细节所牵扯。开发人员需要兼顾太多的计算选项，试图说服架构师他们的选择，并且在仍然需要一个接一个地交付 sprint 的同时，还要努力学习另一种工具，这让他们感到焦虑。
最突出的是两位技术组负责人之间激烈的争论。一位坚决认为使用带有 Fargate 的 AWS ECS 是正确的道路：简单、无服务器且易于管理。另一阵营则强烈主张使用 Kubernetes 生态系统的 AWS EKS：用于可观测性的 Prometheus、Grafana 仪表板、GitOps 工作流程等等。
每个选项都有优点。但争论没完没了，决策速度减慢，交付也受到影响。
所以我悄悄地做出了决定：我们将推进托管的 Kubernetes 平台。我优先考虑开发人员体验、可维护性和未来的可扩展性。然后我们就开始构建了。
那一刻对我来说是一个转折点——不是因为我们选择的特定工具，而是因为它暴露了当今许多团队面临的核心问题：当平台复杂性成为阻碍而不是推动因素时。
当今组织面临的最大挑战之一是技术的复杂性——它支离破碎、发展迅速且不断变化。再加上平台业务模式的加速，保持领先地位变成了一种无情的追求。
五年前，数字化转型还是一种选择。今天，这是一种必然。
这就是平台工程的用武之地。从本质上讲，平台工程应该充当一个抽象层——至少解决两个关键的痛点：
管理支离破碎的技术栈。跟上快速的技术变革。通过这样做，它可以使企业专注于交付价值，而不是与基础设施作斗争。平台工程应该减少摩擦，提高敏捷性，并使技术成为无缝的推动者，而不是负担。但我们如何知道它是否有效呢？
平台工程的成功不仅仅在于有多少团队使用该平台，而在于它如何有效地推动成果。一个成功的平台应该：
加速数字化转型，而不是延迟它。提供像任何出色的外部产品一样无缝的开发者体验。提供直观的集成解决方案——而不仅仅是将复杂性转移给开发人员。通常，“左移”被误解为将所有事情都推给工程师。但是，平台工程师、设计师和架构师有责任创建直观的系统，使开发人员能够专注于创新。如果这种情况没有发生，开发人员就会脱离——平台就会变成货架软件。
想象一下注册 Netflix，兴奋地狂看你最喜欢的剧集。但是：
需要六个月才能学会如何使用它。每次登录时导航都会发生变化。看电影的感觉与看电视剧的感觉完全不同。你可能会退出。现在将此应用于内部开发者平台。
如果开发人员和工程师需要几个月才能提高工作效率，那么你的平台不是在帮助你，而是在阻碍你。一个伟大的平台应该像消费级产品一样流畅和直观。
内部平台必须能够立即提高生产力。如果你的平台提供计算能力，它不应该仅仅是原始能力——它应该是集成的、易于采用的，并且在后台无缝演进。让我们不要制造不必要的认知负担。开发人员正在迅速适应生成式人工智能和新技术。真正的价值在于解决真实的、有形的问题——而不是虚构的问题。
这让我们更深入地了解哪些地方不起作用——以及为什么如此多的努力尽管有最好的意图却仍然失败。
平台工程 仍在发展中，这一点显而易见。许多工具和实践正在被组装起来，但并没有完全理解现实世界的行业痛点。
大多数企业本质上是混合的——遗留系统、孤立的流程和复杂的工作流程是常态。真正的挑战不仅仅是技术上的；而是将平台工程整合到这些混乱的现实中，而不会使其变得更糟。
今天，没有单一的产品可以端到端地解决这个问题。我们仍然缺乏一个整体的解决方案，可以在不增加摩擦的情况下管理内部工作流程、治理和混合复杂性。
我们需要的是一种思维方式的转变——从组装开源工具到构建集成的、以采用为中心的、与业务对齐的平台。而这种转变必须以工具和团队结构的明确趋势为指导。
开源仍然强大，但仍然是分散的。虽然它具有巨大的潜力，但缺乏整合和标准仍然会带来集成挑战。
作为回应，许多组织正在倾向于 DIY、开发者主导的平台。工程师越来越希望控制——对工具、集成和自动化。这种趋势将会持续下去。
与此同时，软件机会仍然广阔。市场仍在等待一个真正的平台产品，该产品可以在灵活性和可用性之间取得平衡。如果构建得当，这可能会重新定义平台工程。
当然，工具只是其中的一部分。同样重要的是组织如何构建其平台团队。
内部平台会对外部性能产生影响。当内部工具笨拙或缓慢时，面向客户的创新就会受到影响。
太多的平台是以技术至上的思维方式构建的。我们需要业务至上的思维方式。
加速创新。抽象复杂性。提供无缝体验。内部平台应被视为客户产品——具有投资、用户研究和可衡量的业务成果。展望未来，我们如何发展整个学科将决定其未来。
可能会发生什么？平台工程将遵循 DevOps 的轨迹：从概念到必然。采用率将会增长，工具将会成熟。
应该发生什么，以及我更希望看到什么？两个关键转变：
开源整合：Cloud Native Computing Foundation、OpenUK 和其他此类开放组织可以在创建降低复杂性的标准方面发挥关键作用。平台即生态系统： 就像 Netflix 上的创作者或 Amazon 上的合作伙伴一样，开发人员应该帮助平台有机地增长——贡献、适应和随着时间的推移发展它们。最重要的收获是什么？
明确您的平台的用途和商业模式。没有它，你只是在构建工具。
让你的战略——而不是你的技术栈——驱动决策。优先考虑体验。全面思考。
我将以我的书“Decoding Platform Patterns”中的一段话与您分享，以激发更多的想法和创新：平台的未来将青睐那些建立信任、公平并提供卓越体验的人，而不是那些行动最快的人。
来源：小羊说科技