对于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以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。

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

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

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

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

  • 持续DevOps文档:是必需的

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

技术手册>更多

  • Gartner指南:赢在BPM

    Gartner公司的BPM专家在谈到重要方法论发展的预测时,坦率地说道:想要获取竞争优势?让BPM成为核心竞争力。而这个建议尤其是针对大型上市公司。很多相关行业的网友对此也表示强烈赞同。未来BPM会为企业交付价值并借由拥有卓越BPM的企业淘汰掉一些流程混乱的企业,这也许对于某些行业将会是一次洗牌,产业格局会有所变化。

  • 大型机数据迁移和遗留SOA集成向导

    大型机应用现代化对于保持原有系统至关重要,而且大型机在大型企业高性能企业计算仍旧处于核心地位。这也是SOA成功案例中,目前正在进行的革新中最为显著的内容。以前,遗留大型机应用抵制重建,开发团队通过为意大利面式的代码排序,试图改写系统并非易事。遗留系统是一个已经运行了很长时间的,对机构来说是很重要的系统,但是往往不知道如何处理的大的软件系统。它与平台相关,但不能在网络环境中直接访问。另外,遗留系统不能直接访问存储在各种数据库管理系统中的数据,但由于遗留系统所完成的是关键业务,所以不能简单丢弃。在这本向导手册中我们将着重为您介绍遗留SOA集成问题以及大型机的数据迁移问题。

  • 云应用性能管理和测试教程

    云里来雾里去的云计算讲了好多年,其实对于大众来讲对这个概念仍然是有些摸不着头绪。那么对于已经应用了云服务的企业而言,在实践中有哪些技巧可以参考或者有哪些经验可以分享呢?在这期技术手册中,我们将一起来关注云应用的可用性,如何进行云应用的监控,云服务中间件如何?同时我们将侧重于云应用性能管理以及云应用测试的内容。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

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的未来。