前段时间,我们有发过一篇题为《炒了8年的概念,到底该如何理解DevOps这个词》的文章,文中作者就DevOps的概念、价值、目标、挑战做了梳理,如作者所说,实施DevOps的核心目标是加速团队、企业的IT精益运行,从根本上提升IT的生产效率,加速部门、企业的业务创新能力。

是的,DevOps的优势很明显。那为什么它这么好,但这些年下来实际落地的企业却这么少。除了作者提到的容器、微服务等相关的『环境因素』外,还有哪些内在因素?普元在这方面又有哪些经验和案例?InfoQ就这些问题对普元的主任架构师顾伟进行了采访。

InfoQ:请介绍下您的技术背景和目前负责的项目?能否回顾总结并阶段性地介绍下您的技术成长经历?

顾伟: 大家好,我是顾伟,专注于DevOps和云计算领域,擅长CI/CD、前端、OSGI、容器等技术,对各类自动化、智能化有着浓厚的兴趣。目前负责普元The Platform云平台产品的设计工作,兼顾DevOps、CaaS、IaaS等外部实施工作。

到目前,我的职业生涯中经历的领域和技术栈比较杂,大体分为以下四个阶段:

· 06年-07年:以项目实施为主,参与了华为BME项目的多期建设,熟练掌握了包括Java、Web、数据库等基本技能。

· 07年-10年:主要参与了两款产品研发,一款是基于Ext的所见即所得的UI产品,一款是基于Eclipse插件开发的IDE平台,熟练掌握了主流UI框架和Eclipse的大部分源码。回过头来看,学习优秀框架设计的经历,为今后的架构之路奠定了较好的基础。

· 10年-12年:以大型企业级平台实施为主,参与了工商银行、中信银行的统一平台项目,也主导过中航信RI等创新项目。在加固已有知识的同时,这段经历使我掌握了诸多企业级中间件(比如IBMMQ、ILOG、BMC CMDB等)的使用和扩展,同时也开始接触了如云计算、大数据领域的新技术。

· 13年-16年:从与阿里云ACE合作云产品开始,先后历经了普元IaaS(OpenStack),CaaS(Kubernetes + Docker),DevOps领域等产品设计及研发工作。这段时间,拥抱开源并实践于企业级产品中,算是正式走进了企业云计算领域。

InfoQ:您曾经提到过您很关注DevOps和自动化运维。能否简要介绍下您对这两者的理解和未来趋势的看法?DevOps给运维部分带来了哪些变化?

顾伟:在我的理解里,DevOps其实是包含了自动化运维的。只是现在这两种概念都很常见,所以我分开提及的。

大家肯定都能感觉到,DevOps、微服务、容器等概念已经越来越热了。这让我想到了3年前OpenStack的状态,各大社区、创业公司、传统企业,纷纷投入到OpenStack怀抱;而现在,虽然是有一些公司存活下来了,但总的来看谁也没赚到多少钱,也没有哪家公司如预想般把VMware给替代了。过热的后果是反而把市场秩序给弄得一团糟,产品低价竞争,人员漫天要价。

我觉得现在的DevOps也到了这个岔路口,有很多公司在热炒DevOps的概念,并纷纷宣布转型成功;而从实际市场、尤其企业市场的反馈来看,客户对此的评价几乎众口一词:“DevOps很好,但我们很难做到”。究其原因,最缺乏的是DevOps方案提供公司真正到深入到企业里面,沉下心来,结合实际情况进行实施实践,从而帮助客户切实地做到横向协作打通、纵向工具链打通。所以我觉得,市场到今年底前还是会充斥着很多概念炒作;但从明年开始,大家会逐步看到,这个领域中真正的脱颖而出的,将会是那些已经将DevOps实际落地的企业和服务商。

DevOps给运维带来的变化,主要体现在运维工具的打通,但是单单从这个角度看影响并不很明显。如果能够从企业、部门、团队多维角度结合来看,才能发现DevOps独特的地方。DevOps本质上是一个持续优化的过程,一般需要从组织、技术、流程三个维度考虑,目标是加速IT的精益运营。 DevOps推崇的是让开发、测试、运维友好协作,倡导大家都能为各自的上下游提供便利,形成演进回环,有效的支撑业务创新。

InfoQ:你提到,DevOps很好,但也很难落地。你认为难点在哪里?如果说要突破这些挑战,你认为团队负责人应该重点从哪些方面入手?

顾伟:我觉得DevOps最大的难点并不是所谓的文化或组织(因为这个不是说改变或打破就能改变或打破的),而是各家公司的流程和工具都是有差异的,每家都会有自己的特色与特殊部分,很难有所谓的通用产品能解决所有问题。举个代码库工具使用方式的例子,之前在我们微信群里还单独拿出来讨论的,有的企业是主干开发、分支release;有的企业是分支开发、分支release,接着再往下细,都是分支开发并release的企业,同一个产品版本,有的是开发环境、测试环境、生产环境对应的分支物理上是不同的,也有开发测试环境相同、生产环境不同的,还有从开发到最终上线就一个分支的。而且每家做法都有很充分的理由……

想突破这种问题,对于一个团队负责人来说,要能在一定的条件下,有效组织团队、逐步优化流程。这里说的“一定的条件”涉及很多方面,比如不要试图按理想情况去打通部门,这是永远不可能的,再比如想让团队每个人都有一样的高度、理解力、责任感也是很难实现的。所以对于一个团队负责人来说,想实施好DevOps,需要理清现状,统一概念模型,制定阶段性目标,激发团队热情,有效规避风险;而不是一上来就是要用什么技术,要有多好的理念之类。

InfoQ:你如何看不可变基础设施?

顾伟:看到这个问题,首先想吐吐槽:初次听到不可变的基础设施时,我当时不知道为什么,还想起了另外一个概念:基础设施即代码,虽然这两者没有特别的强关联,但第一感觉就是,现在市场上很喜欢拿基础设施来说事。我以前做过IaaS、PaaS,也参与过运维工作,基础设施在我的理解里是一个底层、重、固化的东西。随着一切皆服务、一切皆代码、无状态这些概念起来,让我觉得市场上的任何词,都可以变成“怎么说都有理”的理念。

回归正题,我认为要像不可变的基础设施的目标前行,有两点比较重要:

· 从使用者的角度来看,基础设施最好是无差异无感知的,所谓的无差异或无感知是说无论下面是什么样的异构硬件、不同系统等,对上层业务的服务提供方式都是统一的;

· 从提供者的角度来看,基础设施从建立之初就不要再变更,只有新建与替换,粒度很重要,这也是很多人甚至会提到消除SSH的想法的原因。

对于不可变基础设施的未来,我认为是个长期的目标。随着容器、DevOps能力的逐步落地,给了这个目标一个可实现路径,但真的要做到完全不变,我觉得是很难的,因为生态还没有起来,很多层的能力或接口还没有统一和规范,差异化永远是不可变的最大拦路虎。

InfoQ:这两天又有人提出了OpsDev的概念,你怎么看?

顾伟:这个我之前也看到了,看到第一句解释后我就没再看下去,因为从来没有人说过DevOps到底是Dev2Ops还是Ops2Dev,为什么?因为无论是Dev还是Ops,都应该将对方视为可标准的对象,同时为对方提供足够可规范的便捷(主动的尝试着去适应对方),这本来就不是一个单向的过程。

所以我认为无论是叫DevOps,还是叫OpsDev,大家的目标都是一样的,切勿认为词语上的谁先谁后,就意味着谁主动谁被动。在不失规范与流程的前提下,打通上下游、双向协作才是DevOps的真谛。

InfoQ:您即将在CNUTCon全球容器技术大会上和我们分享《基于微服务架构的容器云之实践》,可否先大概介绍下你们的容器云?

顾伟: 其实普元的主要目标是落地DevOps,在技术实现上,只是底层默认使用了CaaS作为支撑(当然平台也兼容IaaS)。平台在原有的基础能力之上,实现了容器+微服务的部分,并不断版本迭代演变至今。第一个版本花费约半年多时间。这次,为了契合容器大会主题,我选择了底层CaaS部分的实践进行分享。

目前我们的容器云既可以运行于私有云(OpenStack、VMware),也可以支持在公有云(阿里云)上运行。平台以微服务架构为支撑,使用了Kubernetes+ Docker的组合,以CoreOS、Flannel、SkyDNS等作为支撑选件,集成了包括MySQL、Redis、GIT、Nexus、Jenkins、Docker Registry等基础服务,形成了一款用于支撑企业DevOps的容器云平台。平台最终架构图(含DevOps能力)如下:

图片描述

InfoQ:这套容器+微服务实现的DevOps方案,您认为哪类行业的企业可以借鉴参考?传统企业可以在哪种情况下,开展怎样的尝试?又该如何拆分传统应用?

顾伟: 这套方案相对来说,比较适合有一定规模的企业或互联网公司。因为如果团队较小、业务较简单(比如只有极少数量的App),那首要的问题还不在精益化上,通过人来做管理配置,也不会特别复杂。

对于传统企业来说,我的建议是尝试需要首先从这两方面开始:

· 持续发布能力:这是打通开发测试与运维的最佳着手点,也是业界目前方案成熟度较好的模块。

· 自服务能力:自助和自动,是打通上下游、提升运营效率的有效手段,自服务能力强调的正是这一点。

至于提及微服务化是如何进行单块应用拆分,我觉得是这之后的事情:没有配套的运营支撑平台,何谈微服务架构。

InfoQ:您提到过目前的这个方案在13年的时候普元就有提出过。当年是在什么样的情况下想到的呢?为什么当时没有落地这样的想法?

顾伟: 翻翻历史,这个点子是13年的时候,我们董事长刘亚东先生提出的,当时他指出:“数字化未来会将企业每个人、每台机器都变成一个节点,企业信息平台需要具备打通供应链、资金链、物流链、销售链、服务链等能力,这就需要企业在未来竞争中找到自己的位置,就必须用数字化企业云平台”。

至于为什么当时没有落实下来?我个人觉得,毕竟当时董事长提出的无论数字化、还是连接一切等概念还比较前沿,我们团队的积累和认知不是很够等种种原因吧,没有在当时真正执行起来。现在回过头来看,算是在给当时的愿景圆梦吧!

InfoQ:为什么微服务的架构要采用容器做默认承载?如果不采用容器技术,您认为微服务化会面临怎样的难题?除了微服务化架构的实现,普元还有在其他情况下使用过容器技术吗?

顾伟: 首先我的观点是,微服务架构和容器没有任何关系,大家也可去翻一翻MartinFlower的文章。那为什么现在大家看到的文章中,提到微服务就会提容器,或者提DevOps,本质上是因为以下两点:

其实很多公司的现状是仅仅实现了容器管理,但是又想接下来向微服务化靠拢,于是就出现了强关联的概念。

事实上,现在也确实存在很多企业把两者结合在一起使用。无意中让大家误会了两者的关系。

但是这只是说明了两者相伴相生的现象,并不意味着强因果关系。

容器的优势在于:轻量化、原子化、可移植性、快速集成等,而这与微服务所倡导的松耦合、高内聚有着异曲同工之处。 在实际使用中,往往容器+微服务确实可发挥 1+1>2 的功效。

容器可以作为默认承载,但要支撑企业级系统,不能只有默认承载。因为容器的相关技术完备性现在还不足以完全支撑业务,像容器的存储方案、有状态服务方案这些生态技术还并不太成熟。

如果不采用容器技术,传统VM技术、或者说IaaS,甚至纯物理机架构,照样可以支撑微服务架构,只是在管理上稍微复杂些。在普元,我们是通过统一的环境管理(内部系统叫SEM),来屏蔽底层基础设施差异的,大家可参考我们异构环境下的统一概念模型:

图片描述

目前容器技术的使用主要在这款数字化云平台里,其他地方用的较少,只在一些客户试点项目中有过尝试。

InfoQ:相比较历史系统的DevOps,基于容器技术的DevOps具有哪些特点和优势,适用于哪些情况?您是否认同“容器改变DevOps”这种观点?

顾伟: DevOps有时会让人觉得很遥远,也有很多企业会觉得先做到自动化运维就足够了,大家对于这个概念其实褒贬不一。技术方案上,也是层出不穷,近期看到一些微信群、公开课、沙龙在讨论DevOps实现:有用容器的;有基于Puppet、SaltStack延伸的;还有一些生于Cloud Foundry、OpenShift这些传统PaaS之上。换而言之,DevOps其实并不局限于任何具体技术,只是容器技术在实现DevOps时有一定的优势:

· 灵活:DevOps的一项重要工作是“编排”工具链,要求能够对“原子活动”进行快速串接,而容器本身对于原子化及编排能力就有很好的支撑。

· 集约:DevOps的一大价值是资源集约管理,容器相对于传统VM,在资源利用上就有很大优势,其资源长短生命周期皆宜的特征,对于像开发测试云这样的需求尤其合适。

· 标准:以镜像为粒度的管理模式,相比于零散脚本、多变介质、各种小工具等规范度不高的传统开发运维,给了实施者一定的标准。伴随着配置、服务状态等生态技术的补充,容器实施DevOps的方案会变得更完善。

您提到的“容器改变DevOps”说法,我认为偏绝对;我更倾向于“容器让DevOps更容易”。

InfoQ:对于容器的运维,您认为有哪些需要特别注意的问题呢?能否详细谈谈的双模架构(模态1:传统技术,模态2:容器技术)的自动化运维?

顾伟: 我认为对于容器本身的运维,其实和传统的运维没有太大差别。要说容器运维有什么特别注意点,我觉的下面大家可关注以下3点:

选择一个合适的框架,不要什么都自己研发:目前业界很好的框架并不多,K8S、Mesos、Docker本身的一些,选择您觉得和你们理念最一致的,作为你的基础框架。

避免惯性思维:很多做过传统运维的同学,在遇到容器时,第一想法还是用既有知识和习惯管理,所以大家会发现,现在很多企业把容器当VM用,或者宿主系统一定要XXX,这个往往束缚了容器运维的优势。

要向上抽象:毕竟容器还不能完全替换企业既有,那资源、中间件、应用的运维和容器的运维是不是可以统一,这就要求在运维角度抽象一层模型,便于后续的一体化运营平台的建设。

对于双模架构的自动化运维,核心问题就在于能否抽象出一套兼容的模型,屏蔽各种异构差异化,可从以下四个方面考虑:

· 环境:主机、存储、网络、容器的差异化。

· 配置:应用配置与环境配置,动态配置与静态配置。

· 仓库:三方仓库、部署包仓库、镜像仓库等。

· 流程:编译流程、部署流程、故障流程等。

InfoQ:您说这个点子成功在于:”市场上的客户反馈和内部的能力驱动”。能否将这两个方面进行详细的展开论述?

顾伟: 不仅仅是这个点子,我认为任何点子的成功都离不开这两方面:

客户反馈:反馈的核心价值在于驱动产品向正确的方向演进,比如小米,从设计之初就笼络了一群发烧友,请他们来提建议,帮助做设计。换个时髦的词叫MVP,意思和快速推出试错试对,这与管理学中的PDCA质量环有着想通的理念。我们要做大设计小版本,进而通过Inside-out & Out-inside的有效配合,基于反馈快速迭代,才能推出符合市场需求的产品。

能力驱动:这个也可以讲成康威定律,我更倾向于称之为康威定律+,团队一定程度上决定了业务架构,拥有一个全栈的团队,对于一些创新类点子有着非常重要的作用。在一个点子形成之初,原型、场景、计划、设计、迭代模式、技术预研等,环环相扣,任何决定都对后期的发展有着的重要影响,所以我一直认为:有什么样的基因,做什么类型的事情。有什么能力的团队,做什么规模的事情。

InfoQ:最后一个问题:技术变革日新月异的今天,对于立志在技术领域中长久发展的年轻人,您有什么建议和忠告?

顾伟:忠告不敢当,结合我带新人的经验谈谈一些想法吧。

首先,技术是学不完的,以前是,现在更是。对于刚开始工作的同学,在精不在广。任何有一定规模的技术框架,都有很多值得深入学习的地方,别人为何这么设计,相比同类产品有什么优势。多思考,多总结。不要一味的只管调试代码,fix bug……

学技术之外,也要学做人。技术再牛,如果无法融入团队,那还是没用。此外,新同学必须要有自主性。现在很多新同学有个通病,遇到问题就问导师。不是说不能问,关键在于问之前你有没有真正的花精力尝试过,或者试着问题缩小到一定范围,不能说一遇到个坎就找人帮忙,会让团队的人觉得事情交给你很不放心。

最后就是执行力很重要。很多同学都会定目标定计划,但却很少有人制定对应的check计划,好像这都是部门经理的事情。说白了就是缺乏自我管理能力。现在的人确实受打扰太多,但这不是执行不力的借口。建议大家制定计划时,要短期不要长期,要实践而不是停留在概念。

普元云计算专区:http://primeton.csdn.net/m/zone/primeton/index#

普元公众号:
图片描述

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐