随着软件开发的工作变得越来越复杂，现在可能是开发和运营专家再次分开的时候了。但这能做到不重复过去的错误吗？
2000年代末，随着敏捷方法论和云计算的兴起，Devops也随之出现，因为软件开始侵蚀世界。Devops是 "开发 "和 "运营 "的谐音，它试图将以前负责构建和部署软件的两个独立小组结合起来。它还与软件工程师需要收紧用户反馈回路并更频繁地将更新推送到生产中的需求相吻合，甚至无意中推动了这种需求。
虽然许多组织抓住了这个机会，将两组专家聚集在一起，以以前不可能的速度解决共同的问题，但其他组织将devops的兴起视为开发者承担运营任务的许可证，并试图建立一个由半神话般的全栈开发者组成的超级团队。
Devops for Dummies的作者和亚马逊网络服务的社区参与主管Emily Freeman在推特上说："在大多数情况下，开发人员不想处理运营方面的问题"。
弗里曼显然触动了人们的神经，数百名同样不想做运营工作的开发者纷纷回复了他。
快餐公司Chipotle的软件工程师Scott Pantall回答说："我是一名开发人员，我不想处理运营问题"。
"开发和运营应该紧密合作，同时有不同的角色。团队之间的共鸣才是真正的重点，"SUSE公司的开发者布道者Andrew Gracey认为。
虽然将更多的操作和安全问题 "向前 "转移并进入软件开发人员的领域的概念显然有其优点，但它也有可能创造一个危险的瓶颈。
人们开始意识到我们不会雇佣一个电工来做我们的水管。
责任的 "大规模 "增加
虽然企业软件开发人员的存量从未如此之高，但技术运营的专业知识在某种程度上已经淡出了背景，即使他们的工作量已经增加。
这些不断扩大的责任涉及到大规模的再培训工作，其中云工程和基础设施作为代码的技能变得非常重要。
这种压力可能已经开始显现了。
随着系统复杂性的增加和终端用户反馈的增加，人类越来越难以从逻辑上推理出可能对系统产生影响的根本原因。
认识问题
重要的是要记住，devops是一个连续体，其实施将因组织而异。开发人员现在可以做一些运营工作，但并不意味着他们总是应该这样做。
带有Kubernetes的容器编排正在成为这两个团队之间的层，将关注点分开，以便开发人员可以专注于他们的代码，而运营可以确保底层基础设施和管道被优化以运行它。
2022年Kubernetes状况 "报告，776名受访者中的54%表示，更好的开发人员效率是采用Kubernetes的关键原因，超过三分之一（37%）表示他们希望提高运营商的效率。
Devops已死
如果devops的时代真的要结束了，甚至如果光泽刚刚开始脱落，那么接下来是什么？
网站可靠性工程（SRE），在谷歌遭遇其自身与devops相关的成长痛苦时出现的，已被证明是一个受欢迎的解决方案。
以Vanguard和Morgan Stanley这两家大型金融机构为例，它们在向更多的云原生实践过渡时发现很难平衡开发和运营的责任。
在中央运营层面和个人开发者团队中插入一个SRE安全毯，帮助这两家公司建立信心，他们在开发者速度和运营稳定性之间取得了正确的平衡。
然而，SRE功能也引起了一些批评：建立SRE原则 "有时被误解为运营团队的改头换面"。
平台工程胜出
内部开发者平台的概念，或者说平台工程的学科，也作为一种组织方式出现，为开发者提供他们所需的工具，并配备适当的组织护栏，使开发者能够完成他们的最佳工作。
内部开发者平台通常由开发者将其代码投入生产所需的API、工具、服务、知识和支持组成，并将其整合为一个公司标准的平台，由一个专门的专家团队或产品所有者维护。
"Devops已死，平台工程万岁，"软件工程师和devops评论员Sid Palas在推特上说。"开发人员不喜欢处理基础设施，公司在发展过程中需要控制他们的基础设施。平台工程使这两个事实得以共存。"