社区编辑申请
注册/登录
DevOps的尽头会是NoOps吗? 译文
开发 自动化 运维
在NoOps中,你不需要运营团队来监督你的生命周期,因为一切都将自动化。那NoOps真的会是DevOps的终点吗?要回答这个问题,你必须更好地理解NoOps。

开发世界中的事正在难以置信地快速发展,云上的自动化和扩展每天也都有新的高度。你几乎可以对任何东西进行 "作为一种服务"--无论是存储、网络、云中、计算还是安全。云供应商也在越来越多地投资于他们的自动化生态系统。这将我们引向NoOps,在那里你不需要一个运营团队来监督你的生命周期,因为一切都将自动化。

你可以使用自动化模板来配置你的应用程序组件,并自动进行组件管理,这意味着你的开销更少,人为干扰最小甚至没有。这听起来不是很好吗?

但这是一个明智的选择,实施它又有哪些优势和挑战呢?

NoOps:这是一个明智的选择吗?

你已经知道,DevOps的目的是使应用程序的部署更快、更顺利,重点是持续改进。NoOps是由Forrester公司的Mike Gualtieri创造的术语,其核心目标相同,但缺少专业操作人员。

在一个理想的NoOps场景中,开发人员永远不需要与运营团队的成员合作。相反,NoOps使用无服务器和PaaS,在他们需要的时候获得他们需要的资源。这意味着,你可以使用一套服务和工具来安全地部署所需的云组件(包括基础设施和代码)。此外,NoOps利用CI/CD管道进行部署。

运营团队对数据相关的任务非常有效,将数据的收集、分析和存储视为其职能的关键部分。然而,请记住,你可以将大部分的数据收集任务自动化,但你不一定能从自动化分析中获得同样水平的洞察力。

从本质上讲,NoOps可以作为一种自助服务模式,云供应商成为你的运营部门,使底层基础设施层自动化,不再需要一个团队来管理它。许多人认为,一个需要零人参与完全自动化的IT环境——真正的NoOps是不明智的,甚至是不可能的。

NoOps与DevOps:优势与挑战

DevOps强调开发人员和运营团队之间的合作,而NoOps则强调完全自动化。然而,他们都试图实现同样的事情——更快的上市时间和更好的软件部署过程。然而,在考虑采用DevOps与真正的NoOps方法时,存在着优势和挑战。

优势:

更多的自动化,更少的维护

通过使用代码控制一切,NoOps旨在消除支持你的代码生态系统所需的额外劳动。这意味着不需要人工干预,从长远来看,每一个组件都将更容易维护,因为它将作为代码的一部分被部署。但这是否会影响到DevOps的工作?

利用云的全部力量

有很多支持极端自动化的新技术,包括容器即服务(CaaS)或功能即服务(FaaS),所以领先的云服务提供商可以帮助NoOps的采用。这是一个极好的消息,因为运营部门可以根据需要增加云资源,与DevOps(开发和运营团队共同决定应用程序的运行地点)相比,导致更高的容量规划。

快胜慢

NoOps关注业务成果,将重点转移到为客户提供价值的优先任务上,消除对运营团队的依赖,进一步缩短上市时间。

挑战:

你仍然需要运营

从理论上讲,不依靠运营团队来照顾你的底层基础设施,听起来像是一个梦想。实际上,你可能需要他们来监控结果或处理异常情况。指望开发人员完全处理这些责任会使他们的注意力从交付业务成果上转移,考虑到NoOps的好处,这并不有利。

仅仅依靠开发人员也不符合你的最佳利益,因为他们的技能组合不一定包括解决运营问题。另外,你也不希望用更多的任务来压倒开发人员。

安全、安全、安全

你可以遵守安全的最佳实践,并使之与自动部署保持一致,但这并不能完全消除你对安全的微妙照顾的需要。攻击方法每天都在发展和变化,因此,你的云安全控制也应该如此。

例如,你可以为你的人工智能引入错误的规则或自动化有缺陷的流程,在你的自动化中招致错误或为数百或数千的基础设施组件或服务器创建有缺陷的脚本。如果你完全删除你的运营团队,你可能要考虑向安全团队投入额外的资金,以确保你为你的环境灌输最好的安全和合规方法。

考虑你的环境

考虑到NoOps使用无服务器和PaaS来获取资源,这可能会成为你的一个限制因素,特别是在数字化转型的时候。对于传统的基础设施和混合部署,自动化仍然是可能的,但在这些情况下,你不能完全消除人为干预。所以请记住,不是所有的环境都可以过渡到NoOps。你必须仔细评估转换的优点和缺点。

那NoOps会是DevOps的终点吗?

答案是否定的。

NoOps不是一个放之四海而皆准的解决方案。你知道,它仅限于适合现有无服务器和PaaS解决方案的应用。由于一些企业仍然运行在单体的遗留应用上(需要完全重写或大规模更新才能在PaaS环境中工作),所以即使有一个遗留系统留下,你仍然需要有人来负责运营。

从这个意义上说,NoOps离处理运行专门流程的长期应用程序或具有高要求应用程序的生产环境仍有一段距离。相反,运营发生在生产之前,所以,对于DevOps,运营工作发生在代码进入生产之前。发布包括监控、测试、错误修复、安全、以及对每次提交的策略检查等等。

你必须让团队中的每个人(包括关键的利益相关者)从一开始就参与进来,以实现快速反馈,并确保自动化控制和任务的有效和正确。持续的学习和改进(DevOps团队的支柱)不应该只发生在事情出错的时候;相反,成员们必须一起合作,协同工作,解决问题,改进系统和流程。

此外,当你想到DevOps的时候,你会想到 "人"。与来自各个业务领域的团队成员(包括QA、市场、设计师、安全、产品经理等)一起,更快地构建更好的软件,将继续成为优越的选择,因为他们共同致力于一个共同的目标。请记住我们在构建高速度开发团队的文章中所说的,一个平衡的团队能让所有成员都参与进来,并为他们提供成长和相互学习的机会。

值得庆幸的是,NoOps符合一些DevOps的方式。它专注于学习和改进,使用通过持续和开放合作开发的新工具、想法和技术,而且NoOps解决方案消除了摩擦,增加了有价值的功能在管道中的流动。这意味着NoOps是DevOps的一个成功延伸。

换句话说,DevOps是永远的,而NoOps只是与DevOps一起进行创新的开始,所以说NoOps是DevOps的终结者就意味着没有任何新的东西可以学习或改进。

最后一站,目的地:NoOps

真正的NoOps涉及相当多的基础工作--你需要在无服务器或PaaS之间做出选择,并将配置、组件管理和安全控制考虑在内,才能开始。即便如此,你可能仍有一些松散的问题--比如遗留系统--需要更多时间来过渡(或者你根本无法过渡)。

但有一件事是肯定的。DevOps不会消失,自动化也不会让Ops被淘汰。然而,随着无服务器自动化的发展,你可能不得不考虑在某个时候采用新的开发和运营方法。值得庆幸的是,如果你选择转换,你有很多帮助,比如自动化工具和FaaS,可以让你的过渡更容易。


原文标题:Is NoOps the End of DevOps?

责任编辑:黄显东
相关推荐

2022-05-18 13:43:04

Devops应用程序开发

2022-06-03 09:41:03

DockerKubernetes容器

2022-03-11 18:30:39

DevOps软件开发

2022-03-29 09:21:21

DevOps开发

2022-06-07 14:38:40

云原生架构云计算

2020-12-24 07:29:32

云计算云基础云原生DevOps

2020-02-29 15:18:10

DevOpsNoOps运维

2021-01-15 18:03:51

云原生DevOpsALPD

2022-06-01 07:22:24

CloudOps云运维框架

2022-04-23 16:58:24

微服务微服务架构

2022-04-12 14:07:40

流程工程软件交付敏捷团队

2022-05-31 09:42:05

容器安全云原生安全

2022-06-07 09:15:42

神州数码

2022-06-28 09:44:21

DevOps软件开发

2020-04-11 11:27:56

DevOpsNoOps运维

2019-09-27 10:02:21

2022-03-10 08:24:17

Docker容器SaaS

2022-06-29 07:49:42

云存储架构DevOps

2022-06-09 14:28:49

深度学习AI

2022-05-30 07:48:11

DevOps测试策略

同话题下的热门内容

源码探秘:Python 中对象是如何被调用的?使用Java和Python进行数据统计和分析C++与Java“相爱相杀”:一个步步紧逼,一个节节败退GitHub这五个骚操作,99%的人不知道!裁员真能拯救中国互联网?吐血推荐17个提升开发效率的“轮子”哪个版本的JVM最快?Flask vs Django: 该如何选择Python框架?

编辑推荐

2017年9月编程语言排行榜:Java、C与C++三巨头还能统治排行榜多久?2017年最受欢迎的5个前端框架比较2017年11月编程语言排行榜:脚本语言怎么了?2017年3月编程语言排行榜:Swift首次进入前十最近租房有点烦!技术人如何用Python找到称心如意的“小窝”?
我收藏的内容
点赞
收藏

51CTO技术栈公众号