当前位置:企业应用软件行业动态 → 正文

有关DevOps的5个问题

责任编辑:cres 作者:Christopher Tozzi |来源:企业网D1Net  2021-03-03 14:51:40 原创文章 企业网D1Net

自从DevOps在十多年前推出以来,DevOps对IT生态系统产生了巨大的积极影响。尽管DevOps有着出色表现,但仍然面临各种问题,这里所说的并不是DevOps工具或技术方面的问题,而是人们需要考虑在定义上困扰DevOps的问题,这些问题削弱了DevOps的目的或使其复杂化,因此难以将DevOps的理念转化为实践。
 
以下是当今大多数组织在使用DevOps时面临的五个主要问题。
 
1. DevOps缺乏明确的定义
 
DevOps的主要问题之一是其定义仍然有些模棱两可。不同的公司和分析师对DevOps的定义不同。
 
大多数DevOps定义的中心思想是,开发工作和IT运营工作应相互紧密协调。但是也有一些重要的例外,例如亚马逊公司对DevOps的定义没有提及开发人员和IT工程师之间的协作。相反,该公司将DevOps定义为“文化理念、实践和工具的组合,可以提高组织快速交付应用程序和服务的能力”。
 
此外在DevOps的定义中,并没有确切说明开发人员和IT运营团队之间应该如何进行协作。
 
“Doing DevOps”是否意味着组织需要构建一支独特的“DevOps工程师”团队,他们需要将开发和运营技能结合在一起?还是要教授开发人员如何进行IT工作或者教授IT工程师如何进行编程?或者,也许组织应该设立“DevOps联络员”这一职位,尽管他们的主要职责是编程或IT运营,但他们会主动与对方的团队联系,以培养开发人员和IT工程师之间的协作精神。
 
有人可能会争辩说,DevOps最终只是一种理念,而不是固定的实践,因此,组织应以对他们最有意义的方式实施DevOps。但这仍然使DevOps的含义和目的有些模棱两可。
 
2. DevOps创建了错误的二分法
 
DevOps的另一个问题是——在某种程度上,DevOps可以被定义为一种鼓励开发人员和IT团队之间协作的理念,它建立了一种错误的二分法。这个概念的前提是,开发人员对IT工程师的工作知之甚少或一无所知,反之亦然,除非DevOps介入并节省工作时间。
 
这是对开发与IT运营工作之间关系简化的观点,其实IT工程师并非对编程一无所知。实际上,许多部署和维护应用程序的IT专业人员都非常擅长使用开发软件,这不仅是因为他们编程、管理和更新了许多自定义脚本为他们的工作流程提供帮助。
 
同样可以肯定的是,如果说大多数开发人员完全不了解IT工作,那么他们一定不会认同。他们知道应用程序部署的含义,以及IT工程师在部署应用程序时通常面临的痛点。他们还了解日志记录和监视,这不仅是管理应用程序的重要过程,而且对于解决应用程序内部出现的问题也很重要。
 
开发人员与IT工程师进行更有效的沟通时,软件交付会更好吗?反之亦然?当然是。但这并不意味着在实施DevOps之前,这些小组之间不存在任何沟通或相互了解。
 
3. DevOps缺乏明确的指导方针
 
DevOps还面临着缺乏清晰明确的准则来确定工作状况的问题。它提出了高层次的概念,但没有具体说明它们的含义。
 
以持续交付为例。“持续”是一个模棱两可和有问题的术语。如果组织每周部署一个新的应用程序版本,是否算作持续交付?还是必须像Netflix或Google公司那样每天部署数千次?显然,很多组织并没有通过一个持续集成(CI)/ 持续交付(CD)管道实现这么多次,他们有很多渠道。但这不是重点。
 
人们也可以对其他与DevOps相关的过程提出类似的观点。在声称可以执行QAOps之前,需要运行多少次自动化测试?与单一的集成相比,有多少代码交付累计起来构成了持续集成?
 
同样,人们可能会认为DevOps没有定义特定的准则或指标,因为这是一种哲学,而不是严格的实践。这是一个很合理的论点,但这也是DevOps的问题之一,因为它可能被认为有些过分。人们需要在DevOps和Not-DevOps之间划清界线,而大多数DevOps的支持者在这方面做得并不好。
 
4. 声称DevOps对未发明的技术负责
 
尽管DevOps并没有规定特定的方法,但DevOps社区作为一个整体仍与某些技术紧密相关。微服务(其中有人认为是DevOps的自然发展)就是一个例子。另一个是容器和无服务器功能,它们是“基于DevOps原理构建的”。
 
这样的争论的问题在于,容器在人们谈论DevOps之前就已经存在了很长时间。如果将类似Zimki的平台放在这一类别中,则无服务器功能也会如此。对于微服务,可以将它们视为与面向服务的体系结构(即SOA)(而不是DevOps的技术后代)密切相关并且更古老的概念的下一步发展。
 
从这个角度来看这是一个问题。可以很好地指出微服务和容器等技术如何加强DevOps目标(无论选择定义哪些目标),但是可以说DevOps实际上促成这些技术有更大的延伸。
 
5. DevOps的采用率很低
 
当今,DevOps面临的最大问题之一是,尽管围绕DevOps进行了更多的宣传,但组织实际采用的比率很低。不同的研究发现,尽管大多数组织表示他们希望利用DevOps作为加快软件交付的方式,但通常只有一半或更少的受访者表示成功实施了DevOps。在规模较小的组织中,DevOps的采用率似乎较高,但大型组织的采用率却相对较低。
 
也许有一天,DevOps最终会获得真正广泛的采用。但DevOps已经推出了10多年的时间,其采用率并不高。这个问题很少在DevOps社区内讨论,可能是因为采用DevOps的组织通常给出高度评价,而没有采用DevOps的组织却对此很少关注。
 
结论
 
DevOps是一个强大的概念,它确实改善了某些组织交付软件的方式。但是作为一个概念,DevOps也面临一些实际挑战。它没有一个很好的定义,并声称对未发明的技术负责,而且其采用率并没有像人们认为的那样广泛。
 
这并不是说DevOps是失败的或者将会消亡。与其相反,DevOps的支持者应该就上述DevOps的问题进行更进一步的讨论。这些问题是可以解决的,DevOps社区不应该对它们视而不见。
 
版权声明:本文为企业网D1Net编译,转载需注明出处为:企业网D1Net,如果不注明出处,企业网D1Net将保留追究其法律责任的权利。

关键字:DevOps

原创文章 企业网D1Net

x 有关DevOps的5个问题 扫一扫
分享本文到朋友圈
当前位置:企业应用软件行业动态 → 正文

有关DevOps的5个问题

责任编辑:cres 作者:Christopher Tozzi |来源:企业网D1Net  2021-03-03 14:51:40 原创文章 企业网D1Net

自从DevOps在十多年前推出以来,DevOps对IT生态系统产生了巨大的积极影响。尽管DevOps有着出色表现,但仍然面临各种问题,这里所说的并不是DevOps工具或技术方面的问题,而是人们需要考虑在定义上困扰DevOps的问题,这些问题削弱了DevOps的目的或使其复杂化,因此难以将DevOps的理念转化为实践。
 
以下是当今大多数组织在使用DevOps时面临的五个主要问题。
 
1. DevOps缺乏明确的定义
 
DevOps的主要问题之一是其定义仍然有些模棱两可。不同的公司和分析师对DevOps的定义不同。
 
大多数DevOps定义的中心思想是,开发工作和IT运营工作应相互紧密协调。但是也有一些重要的例外,例如亚马逊公司对DevOps的定义没有提及开发人员和IT工程师之间的协作。相反,该公司将DevOps定义为“文化理念、实践和工具的组合,可以提高组织快速交付应用程序和服务的能力”。
 
此外在DevOps的定义中,并没有确切说明开发人员和IT运营团队之间应该如何进行协作。
 
“Doing DevOps”是否意味着组织需要构建一支独特的“DevOps工程师”团队,他们需要将开发和运营技能结合在一起?还是要教授开发人员如何进行IT工作或者教授IT工程师如何进行编程?或者,也许组织应该设立“DevOps联络员”这一职位,尽管他们的主要职责是编程或IT运营,但他们会主动与对方的团队联系,以培养开发人员和IT工程师之间的协作精神。
 
有人可能会争辩说,DevOps最终只是一种理念,而不是固定的实践,因此,组织应以对他们最有意义的方式实施DevOps。但这仍然使DevOps的含义和目的有些模棱两可。
 
2. DevOps创建了错误的二分法
 
DevOps的另一个问题是——在某种程度上,DevOps可以被定义为一种鼓励开发人员和IT团队之间协作的理念,它建立了一种错误的二分法。这个概念的前提是,开发人员对IT工程师的工作知之甚少或一无所知,反之亦然,除非DevOps介入并节省工作时间。
 
这是对开发与IT运营工作之间关系简化的观点,其实IT工程师并非对编程一无所知。实际上,许多部署和维护应用程序的IT专业人员都非常擅长使用开发软件,这不仅是因为他们编程、管理和更新了许多自定义脚本为他们的工作流程提供帮助。
 
同样可以肯定的是,如果说大多数开发人员完全不了解IT工作,那么他们一定不会认同。他们知道应用程序部署的含义,以及IT工程师在部署应用程序时通常面临的痛点。他们还了解日志记录和监视,这不仅是管理应用程序的重要过程,而且对于解决应用程序内部出现的问题也很重要。
 
开发人员与IT工程师进行更有效的沟通时,软件交付会更好吗?反之亦然?当然是。但这并不意味着在实施DevOps之前,这些小组之间不存在任何沟通或相互了解。
 
3. DevOps缺乏明确的指导方针
 
DevOps还面临着缺乏清晰明确的准则来确定工作状况的问题。它提出了高层次的概念,但没有具体说明它们的含义。
 
以持续交付为例。“持续”是一个模棱两可和有问题的术语。如果组织每周部署一个新的应用程序版本,是否算作持续交付?还是必须像Netflix或Google公司那样每天部署数千次?显然,很多组织并没有通过一个持续集成(CI)/ 持续交付(CD)管道实现这么多次,他们有很多渠道。但这不是重点。
 
人们也可以对其他与DevOps相关的过程提出类似的观点。在声称可以执行QAOps之前,需要运行多少次自动化测试?与单一的集成相比,有多少代码交付累计起来构成了持续集成?
 
同样,人们可能会认为DevOps没有定义特定的准则或指标,因为这是一种哲学,而不是严格的实践。这是一个很合理的论点,但这也是DevOps的问题之一,因为它可能被认为有些过分。人们需要在DevOps和Not-DevOps之间划清界线,而大多数DevOps的支持者在这方面做得并不好。
 
4. 声称DevOps对未发明的技术负责
 
尽管DevOps并没有规定特定的方法,但DevOps社区作为一个整体仍与某些技术紧密相关。微服务(其中有人认为是DevOps的自然发展)就是一个例子。另一个是容器和无服务器功能,它们是“基于DevOps原理构建的”。
 
这样的争论的问题在于,容器在人们谈论DevOps之前就已经存在了很长时间。如果将类似Zimki的平台放在这一类别中,则无服务器功能也会如此。对于微服务,可以将它们视为与面向服务的体系结构(即SOA)(而不是DevOps的技术后代)密切相关并且更古老的概念的下一步发展。
 
从这个角度来看这是一个问题。可以很好地指出微服务和容器等技术如何加强DevOps目标(无论选择定义哪些目标),但是可以说DevOps实际上促成这些技术有更大的延伸。
 
5. DevOps的采用率很低
 
当今,DevOps面临的最大问题之一是,尽管围绕DevOps进行了更多的宣传,但组织实际采用的比率很低。不同的研究发现,尽管大多数组织表示他们希望利用DevOps作为加快软件交付的方式,但通常只有一半或更少的受访者表示成功实施了DevOps。在规模较小的组织中,DevOps的采用率似乎较高,但大型组织的采用率却相对较低。
 
也许有一天,DevOps最终会获得真正广泛的采用。但DevOps已经推出了10多年的时间,其采用率并不高。这个问题很少在DevOps社区内讨论,可能是因为采用DevOps的组织通常给出高度评价,而没有采用DevOps的组织却对此很少关注。
 
结论
 
DevOps是一个强大的概念,它确实改善了某些组织交付软件的方式。但是作为一个概念,DevOps也面临一些实际挑战。它没有一个很好的定义,并声称对未发明的技术负责,而且其采用率并没有像人们认为的那样广泛。
 
这并不是说DevOps是失败的或者将会消亡。与其相反,DevOps的支持者应该就上述DevOps的问题进行更进一步的讨论。这些问题是可以解决的,DevOps社区不应该对它们视而不见。
 
版权声明:本文为企业网D1Net编译,转载需注明出处为:企业网D1Net,如果不注明出处,企业网D1Net将保留追究其法律责任的权利。

关键字:DevOps

原创文章 企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^