对于orchestration而言 ALM和DevOps至关重要

日期:2016-8-12作者:Tom Nolle

ALM   DevOps   orchestration   

【TechTarget中国原创】

似乎大家开始越来越倾向于把DevOps拿来跟“orchestration”联系在一起。Tom Nolle解释了它们之间的共同点和区别。

云、软件的组件化以及对持续交付的需求,这几个因素加在一起对应用产生了深远变革。没有比在部署和运营生命周期领域变化更重大的环节,一度被称为“DevOps”的这个领域似乎正在演变为所谓的“orchestration”。

为了确保开发和运营能够持续同步演进,开发者需要理解这些趋势。这要求开发者理解DevOps与orchestration的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

orchestration究竟是什么意思

应用从开发到部署的演进总是多种实践的联姻。牵涉到应用的一共有4组不同的工具集。版本控制和开发管理加上开发过程一起再将其连接回企业架构模型。DevOps巩固然后把开发过程连接到部署和应用生命周期管理。

“orchestration”这个词迷惑了许多开发者和架构师,因为他们并不清楚发生了哪些改变。orchestration描述了一个范围很广的应用软件自动化的过程,有可能会涉及到应用开发和运营的四个实践领域。它很大程度上改变了已经自动化的工具,尤其是DevOps,改变之大以至于orchestration有时候纯粹被视为DevOps的演进。它还增加了一个覆盖开发部署剩余范围大部分的自动化维度。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

SOA基础>更多

  • 透明应用检查点将如何影响开发者?

    长时间运行的程序面临着大量导致失效的风险。尤其是如果是依赖多台计算机的大规模程序的话就更加容易,任何一台计算机都有可能在任何时间崩溃。

  • 你的微服务设计支持可重用并避免冗余吗?

    微服务是代码小型的功能捆绑,旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。

  • 对于orchestration而言 ALM和DevOps至关重要

    为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

  • 如何建立自己的UML图库

    没有适当的沟通,想法和计划的执行就会出错,或者被遗忘。统一建模语言经常用于各种睡吧样的蓝图中,来映射出系统计划。事实上,UML已经成为许多软件开发人员选项。

相关推荐

  • 你的微服务设计支持可重用并避免冗余吗?

    微服务是代码小型的功能捆绑,旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。

  • 开发运维一体化(DevOps):协作是成功的保障

    如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

  • 持续DevOps文档:是必需的

    文档和管控的流程仍旧是防止企业陷入困境,保证员工不丢掉工作的有效方式,让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。

技术手册>更多

  • BPM项目错误规避指南

    业务与技术的交叉点正是BPM关注的焦点,这也是大多数重大IT问题出现的地方,通过为业务分析员和软件开发人员提供通用的工具,BPM有希望使应用集成发生革命性变化。正因为这样,技术不能够单独支撑BPM的全部内容,也不能单独解决业务流程的所有问题。业务是BPM依托的另一方面。但是企业在进行BPM项目时却会遭遇种种问题,而有些问题是可以通过前期工作避免的,本期TT SOA技术手册介绍如何合理规避BPM项目中的错误,同时提供BPM技巧和工具信息。

  • 可扩展标记语言:XML

    XML即可扩展标记语言,是Extensible Markup Language的缩写。它与HTML一样,都是处于SGML,标准通用语言。Xml是Internet环境中跨平台的,依赖于内容的技术,是当前处理结构化文档信息的有力工具。扩展标记语言XML是一种简单的数据存储语言,使用一系列简单的标记描述数据,而这些标记可以用方便的方式建立,虽然XML占用的空间比二进制数据要占用更多的空间,但XML极其简单易于掌握和使用。 

    XML实际上是Web上表示结构化信息的一种标准文本格式,它没有复杂的语法和包罗万象的数据定义。XML同HTML一样,都来自SGML(标准通用标记语言)。SGML是一种在Web发明之前就早已存在的用标记来描述文档资料的通用语言。

  • SOA测试全面指导

    在SOA环境中,测试团队超越了传统的以应用程序为中心的功能和性能测试。SOA需要整合地测试界面和服务,这些界面和服务有助于组合利用不同的系统、平台以及相关安全标准。要测试这些应用程序时,就提出了独特挑战。那么如何应对这些挑战呢?下面我们来具体看一下。

  • JBoss实用技术手册

    JBoss是一个同时运行Web及EJB的J2EE应用服务器。它是开放源代码的项目,遵循最新的J2EE规范。从JBoss项目开始至今,它已经从一个EJB容器发展成为一个基于的J2EE的一个web操作系统(operating system for web),它体现了J2EE规范中最新的技术,无论是学习还是应用,JBoss为我们提供了一个非常优秀的平台。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【TechTarget中国原创】

似乎大家开始越来越倾向于把DevOps拿来跟“orchestration”联系在一起。Tom Nolle解释了它们之间的共同点和区别。

云、软件的组件化以及对持续交付的需求,这几个因素加在一起对应用产生了深远变革。没有比在部署和运营生命周期领域变化更重大的环节,一度被称为“DevOps”的这个领域似乎正在演变为所谓的“orchestration”。

为了确保开发和运营能够持续同步演进,开发者需要理解这些趋势。这要求开发者理解DevOps与orchestration的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。

orchestration究竟是什么意思

应用从开发到部署的演进总是多种实践的联姻。牵涉到应用的一共有4组不同的工具集。版本控制和开发管理加上开发过程一起再将其连接回企业架构模型。DevOps巩固然后把开发过程连接到部署和应用生命周期管理。

“orchestration”这个词迷惑了许多开发者和架构师,因为他们并不清楚发生了哪些改变。orchestration描述了一个范围很广的应用软件自动化的过程,有可能会涉及到应用开发和运营的四个实践领域。它很大程度上改变了已经自动化的工具,尤其是DevOps,改变之大以至于orchestration有时候纯粹被视为DevOps的演进。它还增加了一个覆盖开发部署剩余范围大部分的自动化维度。

orchestration的共同驱动力是更加敏捷性和个性化应用的需求。这一点在基于移动的前端过程、移动后端及服务以及基于微服务的应用中已经体现出来。这些趋势跟虚拟资源和云计算集合创造出两个维度的变量。这就是为什么需要在加快过程和减少错误中利用自动化的原因。

新的开发和部署结构

最好把现代开发和部署形象地描述为二层架构。顶层是同意开发过程软件开发的敏捷或持续交付层,现在这一层已经嵌入到应用生命周期管理中。底层是DevOps的现代化形式,旨在为高度组件化(如果你愿意的话也可以称为“微服务化”)应用以及虚拟化资源服务。

要想让这一新结构发挥作用,最关键的一点是在整个应用生命周期ALM工具跟DevOps工具是完成集成在一起的。这类集成一直都会有好处。但如果通过软件自动化进行持续交付和创新是目标所在。在现代应用模型中,持续交付的努力以及敏捷开发必须直接在服务本身以及部署和维系它们的DevOps框内进行。这就是orchestration要明确的东西。

过程变得像服务

持续交付和DevOps必须集成的概念对很多人来说似乎并未深入人心。毕竟,DevOps总是意味着要定义开发和运营的关系。问题在于在云和敏捷开发的世界里,DevOps过程几乎必须当作服务或组件来考虑。这类关系在IBM、微软以及Oracle等集成软件供应商以及Red Hat等开源形式的工具包中已经有所体现。

有了持续开发和DevOps集成,DevOps模式或者每一ALM阶段相关的菜谱必须遵循ALM流程进行设计。然后再用DevOps语言编写出来。当应用、组件或服务进行开发变更时,不仅要对变更进行应用功能测试、安全测试以及合规性测试,而且还要测试变更对ALM与DevOps间集成的影响。

持续交付要求的开发、ALM以及DevOps之间的紧密耦合已经改变了DevOps。两个最受欢迎的工具,命令式的Chef以及陈述式的Puppet均已演进为支持资源的模块化声明。这反过来又支持了组件和服务部署的虚拟化以及模块化定义,从而有利于重用和模块化部署。第二代额DevOps工具,比如Ansible或者SaltStack从一开始就支持这些能力。

集成方面的考虑

连接DevOps、持续开发与ALM相关的API问题或者集成并不是一个很大的挑战,但是这些问题一定不能忽视。

“模块化”这个词很有魔力。DevOps模型或者脚本永远都应该基于组件级或者服务级元素来构建应用。ALM无论哪个阶段需要混合模型,这些模型都应该以简单的方式与产品部署模型连接起来。

事件控制

另一个关键的考虑是生命周期管理的事件控制。没有事件控制,资源过程就不能将条件传送给生命周期管理和部署过程,从而无法进行自动化处理。

DevOps工具中的事件处理至关重要,如果orchestration中被用到的话。一般而言,支持新兴“基础设施即代码”模型(Chef和Puppet均支持)的DevOps工具都会处理事件,但你也可以看看其他一些工具有没有事件处理自动化的能力。

放眼未来

orchestration就是自动化一切与持续交付、敏捷开发相关的东西,这个概念可能最终会把当前的所有工具都归并到一个持续生命周期流程里面。实际上,似乎这是可真正确保未来软件开发实践能跟上业务节奏的唯一结果。

提供所有合适工具的供应商也会拥有最好的机会,即便你目前依赖的是其他工具。最起码,它们会有助于构建一个关于orchestration的未来。