前不久，和一个朋友讨论了一些关于企业云平台的问题。我们所讨论的问题包括企业云平台的定位（上资源型平台还是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，也就是应用在平台上的部署和运行。市面上的大部分的容器云平台，都支持各种部署方式，比如支持镜像部署、支持从源代码仓库打包等。同时，着眼于弹性伸缩、网络架构、存储支持等等。这些东西是有价值的，但是，在发展的初期阶段，这些方面的需求其实倒没那么强烈，利用开源项目就能满足实际绝大部分的需求了。同时，这部分是开源社区的重点方向，因此，云平台供应商最好是在社区的协作框架下来做这些方面的工作。