平台工程需有强烈观点！告别DevOps的无序，拥抱标准化。构建Internal Developer Platform，精选工具和环境，提升DevEx。借鉴Twelve-Factor App，结合PaaS，优化Kubernetes部署，实现可观测性，保障安全，加速交付！
译自：Platform Engineers Must Have Strong Opinions
作者：Doug Sillars
我们正生活在开发者体验 (DevEx) 的黄金时代，开发者可以选择他们喜欢的工具、框架，甚至是编辑器。为代码创建或云部署拥有一个单独的堆栈很容易，并假设当它进入生产环境时，一切都会顺利进行。
然而，一旦组织达到规模和复杂性的临界点，工具的激增就开始导致比解决更多的问题。作为回应，组织倾向于组建平台工程团队，为以一致、可扩展的方式部署基础设施设定指导方针和期望。
平台团队必须拥有授权和权力来执行整个组织的标准，否则开发者最终会陷入两难境地——缺乏自主性和高摩擦的部署环境。
这种权力不仅仅是一种否定的权力，即说“这不符合指导方针”，而是一种积极的权力，可以创建、教授和迭代服务于整个组织的实践。要求平台团队执行他们认为没有帮助的事情不会提高你的组织效率。要求开发者遵守他们不理解的平台模型会使每个人更难遵守。
在 DevOps 革命之初，开发者被告知，“你构建它，你运行它。” 这意味着开发者有自主权和责任选择和部署他们想要的软件基础设施。毫无疑问，这些 DevOps practices 的广泛采用彻底改变了软件部署的敏捷性、速度和质量。也就是说，即使 adopting DevOps 实践具有所有优势，但也存在一些严重的缺点。
给予开发团队在基础设施上的完全自主权会阻止跨应用程序和团队的标准化。很快，组织的 инфраструктура 格局变得高度分散，通常导致云成本增加、可维护性问题和安全漏洞。
为了应对这些缺点，以及认为不应该将开发者时间花费在重复性工作中的看法，组织开始重新专门化为从事平台工程的团队。
Platform engineering 是一种设计、构建和维护开发团队用于部署其应用程序的基础平台和工具的实践。平台工程团队不是让开发者从无限的基础设施选项组合中进行选择，而是创建标准化的、预配置的环境供开发者选择。这通过减少决策疲劳和浪费的精力来 increases developer productivity。精心设计的开发环境可以减少部署后的问题。
平台团队的专业知识和经验推动了对最佳工具的强烈观点。
许多平台工程团队构建 internal developer platforms，这使开发团队只需点击几下即可部署其基础设施，并减少了减慢部署速度的问题数量。由于他们正在设计整个组织的基础应用程序基础设施，因此平台工程团队必须对他们的组织和开发者正在创建的应用程序类型有深刻的理解。这也是注入有关安全性、数据管理、可观测性和其他结构的标准的理想点，这些标准使管理和部署大型代码库变得更加容易。
在设计和构建这些环境时，平台团队的专业知识和经验推动了对最佳工具的强烈观点。组织知识、广泛经验和强烈观点的结合使平台工程团队能够提供满足开发者和组织需求的基础设施，同时提供安全性、性能和更易于维护的特性。
你可能听说过平台工程 just a rebranding of DevOps 或站点可靠性工程。事实并非如此，尽管它与此相关。这样想……
假设你来到 DevOps Pizza 店，菜单上列出了你能想象到的所有披萨选项——甚至更多。上面有一长串配料，但没有说明为什么肉桂糖可能不适合搭配奶油沙司。在 DevOps Pizza 店，你可以随心所欲地制作自己的披萨，不同的大小、酱料和配料可以进行看似无穷无尽的组合。大多数 DIY 披萨会没问题，其中一些甚至会很棒。不幸的是，当有无限多的选择时，有时会犯错误。“我要一个大披萨，底料是罗勒香蒜酱。配料我要菠萝、泡菜、墨西哥胡椒和凤尾鱼。”
相比之下，Platform Engineering Pizza Place 的菜单是一系列预先设计的披萨。这些选择由专家精心策划，厨房里的厨师确保口味和配料搭配得当，味道会很棒。更改标准部署有一个流程（“我要一个大份的肉食爱好者披萨。请加黑橄榄。”），但标准化的披萨选择提供了内置的保护，防止不明智的订单。厨师的意见很重要。他们知道如何制作美味的披萨。
平台工程团队构建内部开发者平台，为开发者提供精选的开发工具和部署环境菜单。这种精选提供了更快、更可靠和更安全的应用程序环境，从而降低了设计不良的应用程序基础设施的风险。
要构建成功的平台工程战略，平台工程团队必须对平台部署有明确的看法。就像披萨厨师根据专业知识和多年的披萨经验构建精选的披萨列表一样，平台工程团队运用其在部署软件方面的多年行业经验来定义组织内部的软件部署。
平台工程团队的经验和意见指导并塑造了内部平台的底层基础设施。他们将护栏纳入部署标准，以确保所提供的开发能力满足工程组织的需求，并满足更大的组织在安全性、可观测性和可维护性方面的需求。
平台工程仍然是一种成熟的实践。一些组织和软件提供商正在努力描述其内部或推荐的实践，以使遵循相同路径的其他人受益。
Twelve Factor App（十二要素应用）是一个描述良好架构部署策略的框架，这是一种旨在提高开发者生产力和应用程序可维护性的方法。最近由 Heroku 开源，Twelve Factor 方法概述了 Heroku 基于其多年客户部署经验的最佳实践观点，以帮助开发者团队避免失误。
这些观点也影响了 Heroku 如何设计其基于 Kubernetes 的现代平台即服务 (PaaS)。Heroku 多年来在 Web 上部署服务的经验促成了其关于将应用程序部署到云中的最有效方式的观点。这些观点可能与你的平台工程团队的观点不完全一致，但使用 Twelve Factor 方法 为你的团队提供了一个良好的起点，可以讨论你组织的需求和价值观。
鉴于 PaaS 平台和平台工程团队之间明显的相似性，一位注重成本的管理者可能会问：“我为什么不能解散我的平台工程团队，而让我的团队改用 PaaS 呢？”
PaaS 不能取代平台工程团队；相反，它是平台工程师工具箱中的一个工具，而不是一刀切的替代品。
基础设施、数据库、存储和网络部署对于 DevOps 和平台工程团队来说是例行但耗时的任务。PaaS 服务可以自动化、管理和扩展常用服务的部署，从而为平台团队提供额外的带宽，以专注于自定义部署、集成和应用程序。PaaS 以最少的团队参与来运营多年的部署和基础设施经验。
围绕标准化和优化部署创建结构可以带来集成环境、更快的部署和更好的组织内应用程序可维护性。为了减轻重复性任务的负担，平台工程团队可以使用 PaaS 工具来实现其为快速部署常用基础设施环境提供工具的总体目标。 Heroku 的 PaaS 帮助平台工程团队简化并加速部署具有良好预设的基础设施。通过立即试用 Heroku，了解更多关于 Heroku 如何帮助您更快地为客户交付价值的信息。