本站文章大部分为作者原创,非商业用途转载无需作者授权,但务必在文章标题下面注明作者 刘世民(Sammy Liu)以及可点击的本博客地址超级链接 http://www.cnblogs.com/sammyliu/ ,谢谢合作

容器云平台企业落地之向左走和向右走

 

前不久,和一个朋友讨论了一些关于企业云平台的问题。我们所讨论的问题包括企业云平台的定位(上资源型平台还是PaaS平台?和公司的数字化战略是什么关系?)、技术选型(他们有VMware虚拟化平台,现在要上云平台,是上OpenStack云还是Kubernetes云?)、落地方式(谁来买、谁来建、谁来运营、谁来用、谁来统筹协调等)等。朋友的团队是研发团队的一部分,已经在做 CI/CD 的一些尝试,也有自己搭建一个基于Kubernetes的容器云平台,现在想进行推广,不想一开始就遇到很多的问题。朋友感叹他们单位IDC事业部的不配合,他们不接受容器云平台落到IDC;还感叹到其他研发团队的不配合,他们开发的应用不落到这个平台;还感叹公司领导想推动上云,但是一直没提出上云战略,因为很多原因,一直想招聘的技术负责人也没到位,还没想好来了后放在哪个层面,负责哪些事情。这个平台,仅仅在前期阶段,居然就牵扯到那么多部门之间的利益关系,实在是有些超乎他当初的想象。 

上周的某个下午,肖力和我去找陈沙克聊天。在现场观摩了他们正在实际使用的CI/CD流程后,我们有长达几个小时的讨论。 

两次讨论的问题,有很多的重合。我意识到,容器云平台、CI/CD、微服务等这些新的理念和技术已经被越来越多的企业所接受,但是,容器云平台的落地,似乎比想象中的要困难得多。本文在总结这些交流内容的基础上,结合自己的一些理解和思考,试图来对这个问题进行一些梳理。一家之言,仅供参考。

一些前提

本文中的一些名词的含义和范围如下:

  • 企业:代表非互联网大多数企业,不包括互联网公司,以及非常大型的公司。

  • 容器云:指基于Kubernetes或Openshift的容器云平台。

  • 企业IDC部门(数据中心部门):企业中管理和运营企业IDC基础设施以及云平台的部门。

  • 企业业务开发中心:企业各业务应用系统开发团队,通常有多个,分散在各业务单位之中。

  • 当前容器云平台在企业落地的状态:还处于早期阶段,主要是利用容器云平台来运行新开发的互联网应用,平台规模往往不是很大,一般不超过50台物理服务器节点,在其上运行的企业应用数目大都在一两百之内。

  • 企业的IT状态:大多都拥有 VMware + SAN 虚拟化环境,部分有OpenStack或者其它私有云环境,大部分企业尚不具有统一的基础云平台。 

当前企业容器云平台的主要应用场景 

目前,企业主要的容器云平台需求是运行新开发的互联网应用。这些应用的主要需求包括:

  1. 需要快速上线和迭代,需求变化快,上线周期短。

  2. 面向C类用户,应用有弹性伸缩需求,比如在大促销的时候。

  3. 往往都是新开发的,部分采用微服务架构。 

当前以资源为中心的容器云落地模式 

 

当前,企业要上容器云平台的话,采购和运营主体往往为IDC事业部。主要原因包括:

  • 企业IDC事业部作为一个独立的事业部,正在管理着企业的IDC和基础云平台,因此企业领导层认为该事业部就应该是容器云平台负责单位。

  • 把容器云平台看着以资源为中心的平台,而企业IT资源一直是IDC事业部在管理和运营。

  • 和IDC事业部相比,企业业务开发中心是分散的,并没有统一的开发中心,因为也就无法与供应商签署合同。 

这么做会导致一系列问题。 

一方面,对企业(甲方)来说:

  1. IDC 事业部为容器云平台的采购和运营方,但不是使用方,因此往往不了解该平台的需求。其结果就是在采购的时候,不得不提供非常大的需求,为避免犯错而求大求全。比如,要求能够支撑2000台物理机节点,要求支持复杂的网络环境,要求支持复杂的存储环境,要求各种集成和环境打通等。但是,实际上,根据前面的讨论,在早期阶段,这些需求过大过全,往往造成不必要的浪费,并且导致真正应该被关注的主要矛盾反而被忽视,而且后期要改动该平台的话代价将会非常大。

  2. IDC事业部运营容器云平台的主要方式是卖容器,按照资源(容器和存储)收费。因此,运管平台也是以资源为中心的,比如提供镜像仓库、卷、服务编排、代码打包、应用商店、日志和告警等功能。

  3. IDC 事业部采购的容器云平台,其目标是作为运行在容器中的应用的运行平台,这就要求业务开发部门能面向该平台进行开发。但是,因为部门之间的部门墙和利益关系,很多时候这个云平台得不到业务开发部门的支持和配合,从而导致云平台闲置。

  4. IDC事业部有可能与容器云平台存在一定程度的利益冲突。有了容器云平台之后,因为容器相比虚机和物理机的资源节省,IDC事业部能够卖出去的资源可能会有减少;同时,容器云平台要求对IDC的基础架构(比如网络架构)进行一些调整,这会破坏当前的稳定状态;导致一些新需求,比如需要新的运维人员等。这些问题在某种程度上会削减IDC事业部做这事情的动力。

  5. 企业业务开发部门,受到整个环境下CI/CD、敏捷、DevOps、微服务等新概念的持续熏陶,往往又有开发和运行新型的基于容器的应用的想法和动力。但是,IDC事业部主导购买的容器云平台,因为购买前没能充分与业务开发团队沟通需求,导致该平台又无法满足开发部门的要求。同时,由于平台一开始就做得很大,再要做修改就已经很困难了。结果就是业务系统开发团队得不到想要的容器云平台。 

另一方面,对容器云平台供应商(乙方)来说,这种模式的问题包括:

  1. 很难在早期阶段就从IDC事业部获取到真正的容器云平台需求,导致有力无处使;相反,却获取到大量的不必要的需求,不得不投入大量精力去满足这些需求。

  2. 费力搭起来的容器云平台不被甲方的业务开发团队认可,说平台怎么这么烂,功能怎么这么差,总之就是各种不满意。这反过来又会导致甲方对乙方的不认可。

  3. 平台卖不出好的价钱。容器云平台,同质化严重,竞争激烈,导致没法卖出好的价钱。

以应用为中心的容器云落地模式 

企业容器云平台的构建,不能单单只是容器云平台,而应该放在企业数字化转型的大框架内在公司层面进行。  

上图所要表达的一个中心点是,要从公司/集团CIO层面对容器云平台进行统筹规划:

  • 确定容器云平台的定位。是与IaaS平台类似的资源型平台,还是公司的PaaS平台?以及容器云平台在公司的数字化转型战略处于什么位置?

  • 确定各利益相关方,包括谁主导(CIO还是其它组织?)、谁是用户、有哪些需求、谁落地(采购和部署)、谁运维运营等(IDC团队,还是独立的云平台团队?)。

  • 确定组织结构是否需要调整。

  • 确定容器云平台上来后的各有关方面新的考核方式。 

结果:

  • 从公司层面对容器云平台进行统筹管理。

  • 容器云平台不能以资源为中心,而要以应用为中心,要覆盖到应用的全生命周期。

  • IDC事业部不再是容器云平台的主导方,而变成了落地的实施单位。

  • 各业务开发团队变成了容器云平台的主要需求提供方以及使用方。他们是平台真正的用户。 

这会带来一些好处:

  • 在采购前就能明确容器云平台的定位和需求,能做到有的放矢。根据实际需求,企业的容器云平台从小到大,周期性迭代,按需增长。

  • 业务开发团队将会获得他们想要的容器云平台,从而实现真正的CI/CD,实现企业数字化转型的目标之一,即快速发布应用并进行迭代。

  • IDC事业部有足够的时间来消化容器云平台,而不是一开始一下子就收到一个巨型的云平台。

  • 对企业来说,把容器云平台纳入到企业数字化转型战略之中,其价值将会被放大。

  • 对容器云厂商来说,企业的数字化转型是一个更大的蛋糕,而不只是在容器云平台的红海中拼刺刀。 

以应用为中心的 CI/CD 流程 

上面说过,当下的企业容器云,着眼于资源,而不是应用。从CI/CD角度,过于着眼于CD,也就是应用在平台上的部署和运行。市面上的大部分的容器云平台,都支持各种部署方式,比如支持镜像部署、支持从源代码仓库打包等。同时,着眼于弹性伸缩、网络架构、存储支持等等。这些东西是有价值的,但是,在发展的初期阶段,这些方面的需求其实倒没那么强烈,利用开源项目就能满足实际绝大部分的需求了。同时,这部分是开源社区的重点方向,因此,云平台供应商最好是在社区的协作框架下来做这些方面的工作。 

下图是沙克之前分享过的他们单位正在使用的CI/CD 流程图:

在这里,我也借此机会感谢沙克和他的团队,他们一直在无私地毫无保留地把好的东西分享出来。 

这图我觉得有点复杂,因此把它做了一个分层,也许有助于理解: 

 

细节不再重复,只有以下几点说明:

  1. 该流程已经在沙克所在的单位进行推广,有几个较大的研发团队已经在全部使用该流程。

  2. 对业务应用开发团队来说,跟之前相比,只有两个改动:(1)把配置从代码中分离 (2)把日志按要求输出到统一的日志平台而不是写到本地。

  3. 该流程还处于不断完善之中。基本的CI/CD 流程已经完全走通,插件式的功能模块在逐步添加之中。

  4. 基本上各种应用都可以容器化,换一种方式说,还没有发现不能容器化的应用。当然了,由于这项工作开展时间还不太长,现在还只是把优先级高的业务应用系统放到了容器云平台上。比如数据库和缓存这样的服务,还是放在私有云环境中。

  5. 容器云平台对底层资源有相当大的节省。

  6. 现在他们面临的一个挑战是,如何把这套东西推广到集团其它的开发中心,甚至集团外的用户。 

对企业来说 

  1. 不能以看待IaaS的以资源为中心的视角看待容器云平台。IaaS 平台,实质上是资源型平台,重点是将计算、网络和存储的云化,并以云资源形式提供给租户。它的出现,算不上质变,而更多的是一个量变的过程。而容器云平台的出现,应该被看着质变,它带来的不止是能够提供容器的资源平台。这里的质变,指的是容器云平台所能引起的质变,包括应用研发、运行、运维方式的革新,新应用为企业数字化转型带来的价值,对于企业业务中台的推动等。因此,需要从整个公司的高度来看待容器云平台,也要从全公司范围内来运营容器云平台。这就是前面图中,为什么要企业CIO来领导的原因。这应该是一个常设单位,而不应该是项目组那种做完了就撤了的那种单位。

  2. 从虚拟化环境到容器云环境之前,私有云环境阶段(OpenStack私有云或其它私有云)并不是必经阶段。容器云环境可以运行在虚拟化环境中,甚至物理机环境中。

  3. 正视容器云平台落地之困难。很多企业中,业务方和IDC事业部之间的距离很大,包括组织结构上和团队人员之间的物理距离上。特别是一些大型企业,往往都有一个独立的IT公司,为集团提供IT服务。过去,该公司提供的都是IT资源,因此往往有提供虚拟化或私有云环境,因此某种程度上可以看做集团的IDC中心。集团各业务开发中心分散在集团下属的各个公司。这些开发中心和IDC中心之间,在组织结构、业务关系、物理距离等方面都距离遥远。在这种情况下,容器云平台落地更是困难重重,甚至有时候会有容器云平台在IT子公司落地后闲置的情况发生。回忆当年,很多集团都是一纸红头文件,要求『必须使用虚拟机,要使用物理机请报集团审批』,来推广虚拟化或者私有云环境。现在,还能一纸红头文件,要求『应用必须上容器云平台、研发必须采用CI/CD模式』来推广容器云平台吗?我认为集团的CIO层面应该来好好考虑该问题。

  4. 思考容器云平台相关团队的考核模式。对IaaS这种资源型平台,往往以规模、利润、资源使用率、SLA等来考核,有些企业集团还会看上云比率。但是对于容器云平台,除了这些以外,还要看它作为PaaS平台产生了多少价值,比如有多少研发团队采用了CI/CD流程,应用的单元测试比例是否有提高,应用开发周期是否有缩短等等。 

对容器云平台创业公司来说 

如果容器云平台创业公司要采用上述模式,那么将面临几个挑战:

  1. 产品化困难。前述CI/CD流程中,涉及到非常多的组件和产品,流程上打通还较为容易,但是管理上是分散的。是否需要统一纳管,能否做到统一纳管,这是一个很大的产品和技术问题。

  2. 构建真正能够落地的CI/CD能力的困难。要提供能够被客户研发团队愿意接受的 CI/CD 咨询能力和产品,需要有丰富的应用软件开发和研发管理经验作为基础。而这些经验,往往是底层云平台研发团队所缺乏的。

  3. 构建企业数字化转型能力的困难。要从产品技术性质的云平台提供商,转型为咨询服务性质的企业数字化转型能力提供商,这里面有很大的鸿沟。也许,RedHat公司相对来说更具备这方面的潜力。我在写这篇文章的时候,突然传来IBM 340亿美金收购红帽的消息,难道他们真想着把IBM的企业咨询能力和RedHat 的容器云平台落地能力进行整合吗? 

而面对的机遇,则是从容器云平台的红海中脱身,转到企业数字化转型的赋能者。这是一个更广阔的世界,也有更多的机会等着去发现。

小结

对前面的主要观点进行一下小结,主要归纳为以下几点:

  • 容器云平台的目标应该是以应用为中心的PaaS平台,而不是以容器为中心的资源型CaaS平台。

  • 要从公司层面和高度来规划和运营企业/集团的容器云平台,要把开发、运维、IDC团队统统纳入其中,不能指望一个团队就能实现或推动应用的全生命周期管理转型。

  • 容器云平台的价值可以非常广阔,就看如何想、和如何做。

  • 企业的容器云平台应该是活的,而不是死的。它应从小到大,按需增长,而不是一上来就求大求全。

  • 对容器云平台创业公司来说,需要思考如何做以应用为中心的云平台,以及如何赋能企业的数字化转型。

 

谢谢您的阅读,也欢迎您关注我的个人公众号:

posted on 2018-10-30 08:42  SammyLiu  阅读(2979)  评论(0编辑  收藏  举报