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

 

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

• 容器云平台的价值能够很是广阔，就看如何想、和如何作。

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

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

 

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