微服务,容器和运维:猜猜现在谁来担责
贯穿软件生命周期共享相同的容器是 容器化 DevOps带来的优点之一,它简化了开发与运维团队之间的关系。这个共享能力与传统裸机(bare metal)或是虚拟环境下的开发工作是如此的不同。并且,如此一来也改变了代码迁移到生产环境时的最终责任人。
在传统的开发场景中,很多IT组织不能为开发和QA团队提供与生产环境相同的基础设施,因此他们会在精简版本上测试,即使它们一点都不同。例如,在VMware商店,开发者也许会使用 Vagrant工具 来编写和测试代码。
当开发团队将代码交付给运维,以便在生产环境中部署,然而它却未能正常工作时,挑战就出现了。“在我的机器上明明能工作的啊”,这句话已经成了此类场景的惯用语,但这对决解如何让正常工作的代码更快地从开发者迁移到生产环境的问题没有任何帮助。在DevOps和容器的新纪元里,开发者必须对最终产品承担更多责任。
容器已经重定义交付
容器已经改变了业界动态(dynamic)。这是第一次,开发者的代码和环境可以被未经变动地交付给运维。实际上,在 为云重新设计IT组织 一文中,这种敏捷构件是下一代IT组织的前提。将代码和环境打包交付带来的好处正是大家对容器技术如此狂热的原因之一。在最佳实践中,关于这个现象的属于是“非易变代码”,意为一旦应用离开开发团队,就不会再实施代码变更。如果为了修复一个问题或者改变一项配置,需要改动代码,你就需要创建一个新的代码发布上游部门,然后将之推向下游部门使用。
这是一个强有力的范式。运维仅专注于将交付的容器部署到生产执行环境,而不是为了能够正确部署而改动应用。许多人褒奖容器,因为它允许运维不必再为应用的正确部署担负责任,使得他们可以确保容器运行环境的稳定。
但这并不像听起来的一样简单。事实上,将下一代应用作为容器部署是具有挑战性的。应用自身的动态性,不断迁移的执行拓扑,以及难以避免的基础设施故障,都意味着提供可靠的容器运行环境并不只是一项小的功绩。此外,消除应用执行的运维责任也引起了其他问题:总得有人为确保应用正确部署负责。如果运维不扮演这个角色,那么谁来“接锅”?
开发者承担更多的运维责任
它就是开发组织。非易变设施的逻辑意味着,任何需要改动代码的运维问题都会被送至开发部门,他们需要修改并创建一个新的构件。在很多方面,这都是说得通的。毕竟,谁能够比开发者更好地理解应用问题?并且,在开发者需要为其代码问题承担责任的认知,可能会使得他们更加仔细。Netflix称这种应用运维责任的转变为“NoOps”,这意为着不再需要运维来保证视频流服务元素运行。应用部门“接锅”了。在DevOps和微服务的时代,理想的应用部门为其代码提供支持,在问题发生时解决问题,并发行新的构件来修复它们。然而,将责任划归创建容器的应用运维团队并不是解决应用问题的万灵药,微服务应用场景下尤是如此。
还记得在忍者刀的广告里,叙述者会说,“ 等等,还有更多(内容) ”,然后陈述购买刀的其它好处吗?微服务应用的运维亦是如此。相比于将问题提交给问题容器的负责部门,基于容器的应用运维拥有更多的好处,因为很多微服务组建需要依靠其他服务才能正确执行。例如,有一个微服务用来计算货运费,它可能需要依赖其他微服务来获取货物(会被分发)的履行中心到客户所处位置的距离。
谁来为应用的启动、可用性以及正确响应负责?如果你认为应该有其他的应用团队,那么你离答案就比较接近了。
任何团队都必须为其代码负责
如果一个问题在某个应用团队里被开发者发现,那么在识别问题的起因,并发现责任实际上在别的团队后,这个问题就需要被提交到那个团队来修复。这就是微服务能够对你如何运维应用产生一系列改变的原因。运维责任的分布引起了一些重要的挑战:应用问题如何被跟踪、修复和锁定(fixed)。
绝大多数IT组织需要着力于如何为应用问题“遗留”转移责任,或者向上交予开发团队。这个运维模式的基础是能够加速代码变更落实到生产环境的自动化DevOps的能力。它需要使用非易变构件,并且它也要求应用团队能够使用和生产环境类似的环境。
大多数基于微服务的应用组件都会调用其它服务,这就意味着开发团队必须持有应用在生产中会使用的服务的可用版本。那些服务可能并不需要是可扩展的或是全功能的,只要具有开发团队所需的最小功能即可。
此外,为了提供软件问题和跨组织边界的关联问题的根源分析,良好的监控和日志功能也是必不可少的。如果一个问题关联到一个应用部门,那么该部门必须有能力来定位服务中出现问题的位置。如果引起问题的原因位于另一个服务中,那么第一个部门应该能够为第二个部门提供数据,以使得他们能够追踪其服务内的问题,并创建补丁来修复问题。
消除开发-运维的划分
开发者必须承担更多的运维责任已是板上钉钉,我们亦可断言,容器会为开发和运维提供清晰的分界点,并使得后者能够集中精力于提供优秀的容器运行环境,有种过度简化的意味。相对于传统的方式,将代码部署到生产环境而言,转向非易变代码和共享构件是一次巨大的进步,但这并不能掩盖一个事实:总得有人承担应用运维的责任。这就如同容器并不能避免应用问题一样。它仅仅意味着责任可以被划分给那些标记着最适合解决问题的团队。是的,开发者会承担更多责任。但是有如此多的责任需要处理。
唯一合理的解决方案是,向前看,分而治之——每个团队必须承担的应用生命周期的部分职责。但是,并不像“丢到墙外,让他们解决”的旧应用世界,这种处理事情的新方式也需要跨团队协作。最后,我们将会看到运维职责变得像航空母舰甲板上的船员一样——每个小组有自己所承担的职责, 但所有的团队为同一个目标而协作 。
原文链接:Microservices, containers, and operations: Guess who's responsible now(翻译:孙科)
原文发布时间为:2016-06-21
本文作者:孙科
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:微服务,容器和运维:猜猜现在谁来担责

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一文让你迅速读懂Serverless
本文讲的是一文让你迅速读懂Serverless【编者的话】Serverless架构,或者称为无服务器架构,是最近几年新冒出来的一种架构风格。本文主要介绍的是Serverless下包含的两个概念:FaaS、BaaS。 【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。 什么是 Serverless Serverless架构,或者称为无服务器架构,是最近几年新冒出来的一种架构风格。这究竟是一种什么样的架构?无服务器,就是真的没有服务器了么?其实,对于 Serverless 来说,只是用户不用更多的去考虑服务器的相关内容了,无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题了;同时,也无需再对服务器进行运维了,无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。 但是没有服...
- 下一篇
CoreOS容器编排之路:从Fleet到Kubernetes的转变
本文讲的是CoreOS容器编排之路:从Fleet到Kubernetes的转变【编者的话】近两年分布式应用的组织和管理水平大幅提升。CoreOS集群管理始于fleet,fleet是2014年发布的一个简易的分布式服务管理框架。而社区上Kubernetes被广泛应用,并逐渐成为了开源容器框架的事实标准。基于技术应用和市场占有等原因,Kubernetes成为大规模容器架构集群最优秀的自动化编排工具,CoreOS也因此而改变技术选型。本文讲述了CoreOS公司集群编排框架的前世今生,描述了从fleet到Kubernetes的转变。 【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。 目前,CoreOS计划于2018年2月1日从Linux的容器平台上替换fleet技术,对fleet的支持也即将截止。fleet进入了维护期,仅负责安全及补丁修复的升级。此项变动代表着集群编排和管理技术将转移到Kubernetes技术上。此转变也简...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- Hadoop3单机部署,实现最简伪集群
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Linux系统CentOS6、CentOS7手动修改IP地址