作者 | Daniel Bryant
策划 | 言征
在云原生开发领域，“DevOps死了吗？”、“云上DevOps太难了！”类似的问题网上有很多种提法。但答案很明确：并不是。随着平台工程的兴起，这类问题的答案也发生了变化——DevOps正在改变，但不会很快消失。DevOps角色发生了变化，它将成为提高开发者体验的助燃器，帮助每个人用更少的成本，做更多的事（Doing More with Less）。在各行业的公司都面临不确定的经济风向时，“花小钱办大事”正成为一个指导性原则。
众所周知，云的出现，给DevOps带来了沉重的认知“包袱”：开发者的精力似乎更多被分摊到学习使用一堆基础工具上。
而诸如Ambassador Labs等开发者平台的悄然出现，也许正在为开发者铺设了一条清晰的道路。开发者平台旨在帮助开发人员实现更高的生产力，减少认知负荷（“要学习的东西多而杂”的负担），同时安全地快速维护软件。 平台工程作为一门学科，虽然还没有定义，也很模糊，但随着更多的包装和商业选择的出现，这一点也开始发生变化，已经成为缓解云原生开发之旅的工具。
虽然 “平台工程”的定义仍有待解释，但其方向是全速前进，专注于塑造和改善开发人员的经验。实现这一目标的最有效方法之一是调整现有DevOps团队的工作重点，使之事半功倍，成为支持开发者经验的类似于 “平台工程”的东西。
1、一场云原生挫败感导致的的演变
有两件事情可以佐证平台工程和开发者平台的兴起、未来的主导地位和商业化。
首先，开发人员的挫败感是公认的。Kubernetes开发者有理由对引入微服务和云原生开发所带来的一些新挑战感到沮丧。开发模式的完全改变，加上突然期望开发人员应该能够“左移”，对他们的代码承担端到端的代码运行责任，造成了额外的、抱怨四起的认知负担。
其次，还有一系列常规的、重复性的任务突然落到了开发人员身上——在许多情况下，他们没有任何类型的路线图或一套抽象概念来弄清使用什么工具。包括缺少可视化的服务，来加快他们所需的反馈回路。这些都相当于放慢了产品和功能的实现。Garden的一项开发者生产力调查发现，开发者平均每周需要花费15个小时在非开发任务上。
这不仅是一个糟糕的开发者经验的难言之隐，而且还拖累了生产力，严重拉低下限。第二，虽然有些开发者喜欢自由地试验和尝试新的工具（1%），但绝大多数的开发者（99%）希望，甚至可能需要，有明确的“护栏”和“黄金通道”来维护和运行他们的代码。大多数开发者希望把他们的时间集中在写代码上——而不是运行基础设施和试图弄清楚那些为了生产力而应该工作的事情，比如维护工具、建立开发环境、自动化测试等等。
推而广之，大多数企业需要标准化、可复制性和一致性的安全和稳定。能够满足客户需求、控制成本和确保安全是优先事项，虽然本质上并不反对创新，但关键业务的要求阻止了太多的创造力，并依赖于流程、自动化和每个人以相同的标准和工具工作。
这才是DevOps继续发光发热的地方。DevOps，也在不断发展，但并没有消失。相反，DevOps正在向平台工程（又称PlatformOps）的支持模式发展，通过创建开发者平台，清扫这些障碍，降低开发经验的复杂度，消除开发者日常工作中的摩擦。
平台工程建立在传统的DevOps实践的基础上，并利用这些知识和经验来识别和实现新的效率，并以更少的资源做更多的事情。或者，正如就像之前所提提到的，“你可以说平台工程采用了敏捷和DevOps的精神，并在云原生世界的背景下进行了扩展”。
2、开发者平台是个中间地带
给开发者更多的控制权和洞察力，以提高速度和建设效率，这样能鼓励开发者对自己的软件进行全生命周期管理的驱动力，出发点是好的。但是，基础设施并不是，而且可能永远不会是开发者的主要关注点——或者说是开发者引导其精力的最有效的地方。
然而，在云原生空间中，开发人员需要更多地了解基础设施，以及在发布代码后会发生什么。如果出了问题，开发人员仍然需要对代码负责，并了解它的依赖关系，以帮助解决和识别（并修复）下游问题。
但对于服务、环境和云本身来进行组织和决策，则不然。这就是要求一个学科的专家尝试在某个完全不同的学科中快速专业化，这既有悖于提高速度和开发人员经验的最初想法，也否定了用更少的资源做更多事情的想法。有时，让非专业人员承担专业责任的想法，认为这会缩小资源足迹——用更少的资源获得更多的资源——会产生更多的问题。
因此，开发者平台的最佳选择应该中间地带，以更少的成本实现更多的收益。基本上，开发者平台可以：
为所需的工具和可见性提供开发人员自助服务，铺平道路，但足够灵活，可以容纳不同类型的开发人员。它既适用于新的开发人员，也适用于希望实现可靠、高效生产的经验丰富的开发人员。
使DevOps/PlatformOps能够支持和增强自助行动，增加他们在战略改进和项目上花费的时间和精力，减少救火时间。
允许更好地衡量性能、法规合规性和安全性，因为运营和资源数据集中在平台内。
多行业公司的预算紧缩的一剂舒缓针。开发人员平台是“确保本地开发环境设置良好，没有人坐等构建完成的一种方式。所有这一切都依赖于平台工程团队能够促进的快速反馈和透明度。”
3、开发者平台比旧式DevOps靠谱
开发者平台比基础设施靠谱多了！多位开发人员、平台工程师、DevOps和站点可靠性工程师也表达了同样的观点，前云原生计算基金会（CNCF）生态系统副总裁，前谷歌软件工程师Cheryl Hung，此前就强调了开发者平台的重要性：“基础设施可能不可靠；它会失败；它是不可预测的。与每次运行方式几乎相同的软件相比，基础设施的操作确实棘手多了。”
如果开发者平台是为了提高效率和生产力，那么现实中到底是否可用，才是决定其能否流行的关键。利益相关者（开发人员）使用该平台能实现价值才是第一位的。创建开发者平台，以解决阻碍开发人员安全、快速地维护软件的典型挑战。平台必须解决开发人员在工作中需要知道、看到和经常做的事情，并定义出无缝实现这一点所需的抽象。
所以，从开发到运维：基础设施如此难用，那么工具和可视化是全周期开发人员的关键。也就是说，基础设施上的DevOps变了：变化到开发者平台层面。这样，开发者更为接受，于企业而言也更为有利。
关于“开发者经验”的反复谈论，可能听起来有点言过其实，但它的确一个永恒的主题。如果开发人员的经验以及支持开发人员的工作，对于实现业务目标和明智地使用资源这两件事情至关重要，那么从这个层面讲，DevOps、PlatformOps也好，平台工程也好，都是一样的，都是为了持续保护和改善开发人员的体验。
4、写在最后
云原生环境下的DevOps让开发者狼狈不堪，已经成为公认的事实，虽然这并非DevOps的初衷，但不确定性的背景，显然已经让这种趋势冷静了下来，“Doing More With Less”的准则映射到开发运维层面，取法于“平台工程”的开发者平台似乎正在迎来兴起时刻。
原文链接：https://thenewstack.io/platform-engineering-in-2023-doing-more-with-less/
