避开软件容器:如何探索DevOps

日期:2015-12-2作者:Valerie Silverthorne翻译:崔婧雯来源:TechTarget中国 英文

DevOps   软件容器   

【TechTarget中国原创】

Bert Jan Schrijver,荷兰JPoint Java软件工匠,也是JavaOne大会的演讲者,他回答了SearchSoftwareQuality的有关DevOps的问题,并且回答了为什么有时应该忽略传统习惯。他还讨论了他的JavaOne演讲,质疑了软件容器的需求。

什么让DevOps团队陷入困境?

Bert Jan Schrijver:一个DevOps团队不能依赖外部帮助。如果他们有所依赖,他们就无法负责生产环境。你怎么能够负责无法修复的东西呢?

当团队陷入困境时,需要改变什么?

Schrijver:团队需要能够在自服务的基础上工作。存在不同的团队不是问题。只有当团队依赖外部帮助时才会有问题。

你提到在生产新软件时,构建一个完全全新的团队。这怎么可能呢?

Schrijver:我们构建了新团队来领导公司向DevOps转变,这样现有团队才能以各自的步伐转向新的方式。新项目转向新技术会比已经进入生产环境的旧项目快。

做太多的测试会不会带来危险?

Schrijver:做太多的手动测试通常会带来危险,因为这会让你变慢。做太多自动化测试也可能会有问题:测试要花太多时间才能完成,因此你的反馈回路会更长,而且需要更多的维护时间。要找到优化测试数量的方法,在各种测试,单元测试、集成测试、端到端测试,和测试运行时间之间找到平衡。

开源工具Jenkins为什么,以及如何在开发中起着至关重要的作用?

Schrijver:我们选择将Jenkins放在交付流程的中心。因为Jenkins是一个万能的系统,它使得我们可以在统一的地方执行产品生命周期里的所有步骤——构建、测试、发布、部署等等,因此能通过将这些步骤连接到一起来创造出自动化的流水线。

你对于使用软件容器并不很兴奋。为什么对于企业而言Amazon弹性计算云(EC2)是更好的选择?

Schrijver:不要误解我:我热爱软件容器。但是它们不是所有事情的解决方案,而且可能会让事情更加复杂。因为我们在AWS上运行,硬件和虚拟服务器对于我们而言是可购买的商品。我们喜欢拥有可变的服务器,使我们可以在运行着的系统上快速执行小改动。我们不需要在单台机器里运行多个服务。因为这种情况下,机器被过度多维化了。通过使用EC2,我们不需要担心端口映射和容器间的安全。我们将EC2实例当成我们的容器。

是否存在容器适用的场景?

Schrijver:当然,我认为在短时间内,需要创建并且销毁多台服务器上的负载时,容器很有用。容器很轻量,并且启动的确非常快速。在我们的情况里,一天才创建并销毁环境一次或者几次。这时,等待稍长一些没关系,在新创建的系统启动并且运行之前,大概需要等待五分钟。

是不是某个领域的专家在你们的团队中没有位置?能否解释下为什么每个人能做所有事很重要?

Schrijver:我们需要专家。比如,我们团队有前端开发人员,后台开发人员和测试人员。但是对于重复性的运营任务,比如部署和查看日志,每个团队成员都能胜任这很重要。这样,当有人不在时,才不会阻碍整个团队的前进。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

作者>更多

Valerie Silverthorne
Valerie Silverthorne

Valerie Rice Silverthorne是SearchSoftwareQuality网站编辑、作家。

SOA实施>更多

  • 持续DevOps文档:是必需的

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

  • DevOps和敏捷相结合 改进软件质量

    DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。

  • AppDynamics引入应用集成平台

    AppDynamics的微服务架构应用集成平台(AIP)旨在对跨不同应用环境的应用进行统一监控,此前这一过程需要各种应用及架构相关的管理工具才能做到。

  • 五种办法提高安全降低移动风险

    规避风险的主管会明智地植入合适的治理策略,用于确定移动设备和移动应用如何在内部供员工消费,以及如何提供给外部客户。

相关推荐

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

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

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

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

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

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

  • 持续DevOps文档:是必需的

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

技术手册>更多

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • BPEL基础使用技术手册

    BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。在《BPEL基础使用技术手册》中,我们将介绍BPEL流程基础结构、BPEL可以用在哪些方面以及在在Oracle SOA套件中如何用BPEL创建复合服务。

  • XML安全教程

    XML是确保Web服务安全的一个重要因素。XML是因特网以及近来Web服务持续增长和开发的主要支持者。

  • SOA与敏捷开发实战演练

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

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算