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

 

前不久，和一个朋友讨论了一些关于企业云平台的问题。我们所讨论的问题包括企业云平台的定位（上资源型平台还是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团队统统纳入其中，不能指望一个团队就能实现或推动应用的全生命周期管理转型。

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

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

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

 

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