作者：千山评论|赵云近年来，国外一些开发者公开表示DevOps是扯淡，开发根本不想做运维。更有什者，他直言“DevOps已死，平台工程才是未来”。随后不久，Gartner发布了2023年十大战略技术趋势，“平台工程”赫然在列。Gartner预测，到2026年，80%的软件工程组织将拥有平台团队，其中75%将包括开发人员自助服务门户。Platformengineering，即平台工程，作为一个流行的概念，迅速成为开发领域的后起之秀。但是对于某种营销策略，总会有人宣称平台工程是DevOps的终结。甚至一些从业者也在向大众描述这样一幅图景：DevOps行将结束，平台工程的未来可期。但实际上，DevOps和平台工程并不是这样的“生死”关系。两者并不矛盾。在某种程度上，甚至可以说平台工程可能会给DevOps带来新的生机。一、DevOps演进“三个问题”DevOps是一种文化，作为敏捷软件文化的一部分，其诞生土壤植根于两点：以敏捷开发为代表的持续开发方式的出现和持续开发带来的运维问题.从团队的角度来看，DevOps往往涵盖包容、协作、自治、责任共担等要素，弥合了开发与运维之间的矛盾；从过程的角度来看，DevOps旨在构建能够满足持续改进目标的敏捷开发实践；从工具的角度来看，DevOps通过拥抱自动化来创建快速反馈循环来提高质量和敏捷性。早在2006年，亚马逊CTO沃纳·沃格尔斯（WernerVogels）就首次提到了“Youbuildit,yourunit”的概念。“拥有”他们在.然而，当DevOps文化开始盛行，各大公司纷纷践行之时，各种挑战不断浮出水面。首先，当DevOps实践需要支持许多开发和产品团队时，就会出现扩展问题，每个团队都对技术堆栈、工具、流程、云服务提供商及其特性和功能做出自己的决策。这不仅导致效率低下，还增加了管理的负担。其次，随着云原生技术的推广和普及，工具环境无论是数量还是复杂度都在快速增长。在过去的几年中，开发人员负责软件交付过程中越来越多的部分。这种复杂性给开发人员带来了巨大的认知负担，并增加了新功能开发的启动时间。正如创业公司Humanitec的CEOKasparVonGrünberg在一次公开演讲中提到的那样，在微服务快速普及和多分布式部署的时代，有太多的人员需求是不现实的。他描述说，端到端所有权是“一个崇高的梦想，但这对个人贡献者不公平。我们要求开发人员一次做这么多工作。然后我们总是抱怨没有输出或交付不及时够快了。但事实是，我们并没有让他们轻易地兑现诺言。”第三，文化障碍。根据Puppet发布的2021年DevOps现状调查报告，83%的IT决策者表示他们的组织正在实施DevOps实践。但与此同时，绝大多数组织仍然卡在中间DevOps演进的各个阶段，其中，文化问题是阻碍DevOps成功的主要障碍，错位的激励和问责结构将成为成熟度的制约因素。可见，DevOps的兴起源于企业有意弥合运维和开发之间的差距，高级开发人员接管了ops的角色，导致开发逐渐不堪重负2.平台工程为何诞生的现实也导致了DevOps停滞背后的核心矛盾：开发人员不想处理基础设施，但企业在开发过程中需要专人管理自己的基础设施过程。在此背景下，平台工程应运而生。LucaGalante将平台工程定义为“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务能力。平台工程师提供的集成产品通常被称为‘内部开发者平台（IDPs)”，涵盖了应用整个生命周期的运营需求。”当然，目前平台工程还没有一个普遍接受的概念。而且由于每个企业的堆栈、文化、代码库和工具集都不同，也很难设定一个标准化的构建方式，正如ThoughtWorks的工程总监EvanBottcher所说，“这很难用语言表达。“平台”实际上是一个非常模糊的术语，我们用来描述对大规模交付速度和效率很重要的方法。”他更喜欢将“平台”描述为：“自助服务API、工具、服务、知识和支持被配置为一个高规格的内部产品。”简单来说，平台工程是面向开发者的一套自服务的内部开发者平台的机制和架构，用于构建和运营以支持软件交付和生命周期管理，主要目标是优化开发者体验，加快产品团队为客户创造价值的速度。通过构建这样一个企业内部开发平台，开发者可以以“自助式”的方式实现应用端到端的流程。Grünberg说，成功的平台团队创造了一条“黄金路径”，使开发人员摆脱不必要的认知负担，同时保留在需要时偏离路径的自由。而对于Ops工程师来说，采用平台工程还可以帮助他们摆脱一遍又一遍地做同样的任务。理想情况下，功能齐全的内部开发平台可降低系统复杂性、加快软件部署周期、提高开发人员生产力并减轻运营负担。从这个角度来看，平台工程与DevOps并不矛盾。平台工程将很多运维操作抽象出来，提供简单易用的操作界面，让运维不需要高深的专业知识，让DevOps的概念有了喘息的空间。以Kubernetes为例。在某些DevOps设置中，开发人员在每次接触与Kubernetes相关的交付设置时往往会有顾虑。如果你想提高效率，你需要为你的Kubernetes设置实现真正的自助服务。开发人员自助服务意味着工程师可以自行提供和使用测试、保护和部署应用程序和服务所需的技术，而无需等待Ops提供资源或启动环境。这就是平台工程的全部内容：通过内部开发人员平台进行抽象，提供易于使用的构建块，降低开发人员完成工作所需的Kubernetes专业知识水平，这样他们就可以花更少的时间摆弄基础设施，更多的时间专注于客户功能。此外，当涉及到重复性任务时，这种自助服务减少了许多瓶颈和关键的人员依赖性，节省了团队的时间和资源，并加快了交货时间和创新周期。一直在Google从事内部开发平台建设的ChrisStephenson曾在他的博客中提到：“一个有效的内部开发平台的关键在于能够很好地划分复杂的问题。每个人都有一部分复杂的问题他们擅长处理，其他人可以完全忽略这些问题。因此，忽略让DevOps消亡的噪音，专注于采用帮助企业在DevOps旅程中更快成熟的方法论，或许能成为更多人理解和实践的平台工程实践初衷。3.开发和运维，你可以开心地“玩”DevOps的核心理念是缩短流程的长度，实现敏捷运营。但矛盾的地方在于，开发和运维是有各自专业门槛的角色。即便是在一些真正践行的大公司DevOps，开发能做的就是部署和监控，更高层的运维操作，比如容器、替换等，还是应该交给云平台或者架构部门。更重要的是，试图让一人身兼两职的结果是，不仅会减少开发工作的投入，而且由于技能点和时间的限制，无法保证交付质量。平台工程的出现提供了一种新的解决方案。它不试图解决开发和运维之间的分工，也不试图干预运维过程。相反，它使用平台工程来抽象专业能力并提供更易于使用的工具。协助完成运维。当然，也必须遵循一些基本的分工边界。因为在DevOps上开发的痛点不仅仅是技能门槛，还有时间的分配。在运维领域，与开发紧密相关的工作（如部署、发布等）可以通过平台工程开放给开发。而一些耗时的周期性工作，比如监控、巡检等，应该交给专业的运维团队。总体而言，平台工程有助于弥合开发与运营之间的差距。内部开发平台和DevOps团队的工作会有一些交集，DevOps工程师也会有一定的机会过渡到平台工程师的角色，在整个组织中产生更广泛的影响，运用他们的专长为开发者提供开发。更好的体验。开发人员不必在基础架构和其他Ops任务上陷入困境，运营人员可以更多地关注向上游移动到更关键的任务。内部开发者平台，使开发者和运维人员能够聚焦各自工作的核心职责和优势，真正实现“技术专一”和“专人专事”。参考链接：https://img.ydisp.cn/news/20230119/mng2h5gcrmo.html
