一些前提
本文中的一些名词的含义和范围如下：
企业：代表非互联网大多数企业，不包括互联网公司，以及非常大型的公司。
容器云：指基于Kubernetes或Openshift的容器云平台。
企业IDC部门（数据中心部门）：企业中管理和运营企业IDC基础设施以及云平台的部门。
企业业务开发中心：企业各业务应用系统开发团队，通常有多个，分散在各业务单位之中。
当前容器云平台在企业落地的状态：还处于早期阶段，主要是利用容器云平台来运行新开发的互联网应用，平台规模往往不是很大，一般不超过50台物理服务器节点，在其上运行的企业应用数目大都在一两百之内。
企业的IT状态：大多都拥有 VMware + SAN 虚拟化环境，部分有OpenStack或者其它私有云环境，大部分企业尚不具有统一的基础云平台。
当前企业容器云平台的主要应用场景
目前，企业主要的容器云平台需求是运行新开发的互联网应用。这些应用的主要需求包括：
需要快速上线和迭代，需求变化快，上线周期短。
面向C类用户，应用有弹性伸缩需求，比如在大促销的时候。
往往都是新开发的，部分采用微服务架构。
当前以资源为中心的容器云落地模式
当前，企业要上容器云平台的话，采购和运营主体往往为IDC事业部。主要原因包括：
企业IDC事业部作为一个独立的事业部，正在管理着企业的IDC和基础云平台，因此企业领导层认为该事业部就应该是容器云平台负责单位。
把容器云平台看着以资源为中心的平台，而企业IT资源一直是IDC事业部在管理和运营。
和IDC事业部相比，企业业务开发中心是分散的，并没有统一的开发中心，因为也就无法与供应商签署合同。
这么做会导致一系列问题。
一方面，对企业（甲方）来说：
IDC 事业部为容器云平台的采购和运营方，但不是使用方，因此往往不了解该平台的需求。其结果就是在采购的时候，不得不提供非常大的需求，为避免犯错而求大求全。比如，要求能够支撑2000台物理机节点，要求支持复杂的网络环境，要求支持复杂的存储环境，要求各种集成和环境打通等。但是，实际上，根据前面的讨论，在早期阶段，这些需求过大过全，往往造成不必要的浪费，并且导致真正应该被关注的主要矛盾反而被忽视，而且后期要改动该平台的话代价将会非常大。
IDC事业部运营容器云平台的主要方式是卖容器，按照资源（容器和存储）收费。因此，运管平台也是以资源为中心的，比如提供镜像仓库、卷、服务编排、代码打包、应用商店、日志和告警等功能。
IDC 事业部采购的容器云平台，其目标是作为运行在容器中的应用的运行平台，这就要求业务开发部门能面向该平台进行开发。但是，因为部门之间的部门墙和利益关系，很多时候这个云平台得不到业务开发部门的支持和配合，从而导致云平台闲置。
IDC事业部有可能与容器云平台存在一定程度的利益冲突。有了容器云平台之后，因为容器相比虚机和物理机的资源节省，IDC事业部能够卖出去的资源可能会有减少；同时，容器云平台要求对IDC的基础架构（比如网络架构）进行一些调整，这会破坏当前的稳定状态；导致一些新需求，比如需要新的运维人员等。这些问题在某种程度上会削减IDC事业部做这事情的动力。
企业业务开发部门，受到整个环境下CI/CD、敏捷、DevOps、微服务等新概念的持续熏陶，往往又有开发和运行新型的基于容器的应用的想法和动力。但是，IDC事业部主导购买的容器云平台，因为购买前没能充分与业务开发团队沟通需求，导致该平台又无法满足开发部门的要求。同时，由于平台一开始就做得很大，再要做修改就已经很困难了。结果就是业务系统开发团队得不到想要的容器云平台。
另一方面，对容器云平台供应商（乙方）来说，这种模式的问题包括：
很难在早期阶段就从IDC事业部获取到真正的容器云平台需求，导致有力无处使；相反，却获取到大量的不必要的需求，不得不投入大量精力去满足这些需求。
费力搭起来的容器云平台不被甲方的业务开发团队认可，说平台怎么这么烂，功能怎么这么差，总之就是各种不满意。这反过来又会导致甲方对乙方的不认可。
平台卖不出好的价钱。容器云平台，同质化严重，竞争激烈，导致没法卖出好的价钱。
以应用为中心的容器云落地模式
企业容器云平台的构建，不能单单只是容器云平台，而应该放在企业数字化转型的大框架内在公司层面进行进行。
上图所要表达的一个中心点是，要从公司/集团CIO层面对容器云平台进行统筹规划：
结果：
从公司层面对容器云平台进行统筹管理。
容器云平台不能以资源为中心，而要以应用为中心，要覆盖到应用的全生命周期。
IDC事业部不再是容器云平台的主导方，而变成了落地的实施单位。
各业务开发团队变成了容器云平台的主要需求提供方以及使用方。他们是平台真正的用户。
这会带来一些好处：
在采购前就能明确容器云平台的定位和需求，能做到有的放矢。根据实际需求，企业的容器云平台从小到大，周期性迭代，按需增长。
业务开发团队将会获得他们想要的容器云平台，从而实现真正的CI/CD，实现企业数字化转型的目标之一，即快速发布应用并进行迭代。
IDC事业部有足够的时间来消化容器云平台，而不是一开始一下子就收到一个巨型的云平台。
对企业来说，把容器云平台纳入到企业数字化转型战略之中，其价值将会被放大。
对容器云厂商来说，企业的数字化转型是一个更大的蛋糕，而不只是在容器云平台的红海中拼刺刀。
以应用为中心的 CI/CD 流程
上面说过，当下的企业容器云，着眼于资源，而不是应用。从CI/CD角度，过于着眼于CD，也就是应用在平台上的部署和运行。市面上的大部分的容器云平台，都支持各种部署方式，比如支持镜像部署、支持从源代码仓库打包等。同时，着眼于弹性伸缩、网络架构、存储支持等等。这些东西是有价值的，但是，在发展的初期阶段，这些方面的需求其实倒没那么强烈，利用开源项目就能满足实际绝大部分的需求了。同时，这部分是开源社区的重点方向，因此，云平台供应商最好是在社区的协作框架下来做这些方面的工作。
下图是沙克之前分享过的他们单位正在使用的CI/CD 流程图：
在这里，我也借此机会感谢沙克和他的团队，他们一直在无私地毫无保留地把好的东西分享出来。
这图我觉得有点复杂，因此把它做了一个分层，也许有助于理解：
细节不再重复，只有以下几点说明：
该流程已经在沙克所在的单位进行推广，有几个较大的研发团队已经在全部使用该流程。
对业务应用开发团队来说，跟之前相比，只有两个改动：（1）把配置从代码中分离 （2）把日志按要求输出到统一的日志平台而不是写到本地。
该流程还处于不断完善之中。基本的CI/CD 流程已经完全走通，插件式的功能模块在逐步添加之中。
基本上各种应用都可以容器化，换一种方式说，还没有发现不能容器化的应用。当然了，由于这项工作开展时间还不太长，现在还只是把优先级高的业务应用系统放到了容器云平台上。比如数据库和缓存这样的服务，还是放在私有云环境中。
容器云平台对底层资源有相当大的节省。
现在他们面临的一个挑战是，如何把这套东西推广到集团其它的开发中心，甚至集团外的用户。
对企业来说
不能以看待IaaS的以资源为中心的视角看待容器云平台。IaaS 平台，实质上是资源型平台，重点是将计算、网络和存储的云化，并以云资源形式提供给租户。它的出现，算不上质变，而更多的是一个量变的过程。而容器云平台的出现，应该被看着质变，它带来的不止是能够提供容器的资源平台。这里的质变，指的是容器云平台所能引起的质变，包括应用研发、运行、运维方式的革新，新应用为企业数字化转型带来的价值，对于企业业务中台的推动等。因此，需要从整个公司的高度来看待容器云平台，也要从全公司范围内来运营容器云平台。这就是前面图中，为什么要企业CIO来领导的原因。这应该是一个常设单位，而不应该是项目组那种做完了就撤了的那种单位。
从虚拟化环境到容器云环境之前，私有云环境阶段（OpenStack私有云或其它私有云）并不是必经阶段。容器云环境可以运行在虚拟化环境中，甚至物理机环境中。
正视容器云平台落地之困难。很多企业中，业务方和IDC事业部之间的距离很大，包括组织结构上和团队人员之间的物理距离上。特别是一些大型企业，往往都有一个独立的IT公司，为集团提供IT服务。过去，该公司提供的都是IT资源，因此往往有提供虚拟化或私有云环境，因此某种程度上可以看做集团的IDC中心。集团各业务开发中心分散在集团下属的各个公司。这些开发中心和IDC中心之间，在组织结构、业务关系、物理距离等方面都距离遥远。在这种情况下，容器云平台落地更是困难重重，甚至有时候会有容器云平台在IT子公司落地后闲置的情况发生。回忆当年，很多集团都是一纸红头文件，要求『必须使用虚拟机，要使用物理机请报集团审批』，来推广虚拟化或者私有云环境。现在，还能一纸红头文件，要求『应用必须上容器云平台、研发必须采用CI/CD模式』来推广容器云平台吗？我认为集团的CIO层面应该来好好考虑该问题。
思考容器云平台相关团队的考核模式。对IaaS这种资源型平台，往往以规模、利润、资源使用率、SLA等来考核，有些企业集团还会看上云比率。但是对于容器云平台，除了这些以外，还要看它作为PaaS平台产生了多少价值，比如有多少研发团队采用了CI/CD流程，应用的单元测试比例是否有提高，应用开发周期是否有缩短等等。
对容器云平台创业公司来说
如果容器云平台创业公司要采用上述模式，那么将面临几个挑战：
产品化困难。前述CI/CD流程中，涉及到非常多的组件和产品，流程上打通还较为容易，但是管理上是分散的。是否需要统一纳管，能否做到统一纳管，这是一个很大的产品和技术问题。
构建真正能够落地的CI/CD能力的困难。要提供能够被客户研发团队愿意接受的 CI/CD 咨询能力和产品，需要有丰富的应用软件开发和研发管理经验作为基础。而这些经验，往往是底层云平台研发团队所缺乏的。
构建企业数字化转型能力的困难。要从产品技术性质的云平台提供商，转型为咨询服务性质的企业数字化转型能力提供商，这里面有很大的鸿沟。也许，RedHat公司相对来说更具备这方面的潜力。我在写这篇文章的时候，突然传来IBM 340亿美金收购红帽的消息，难道他们真想着把IBM的企业咨询能力和RedHat 的容器云平台落地能力进行整合吗？
而面对的机遇，则是从容器云平台的红海中脱身，转到企业数字化转型的赋能者。这是一个更广阔的世界，也有更多的机会等着去发现。
小结
对前面的主要观点进行一下小结，主要归纳为以下几点：
容器云平台的目标应该是以应用为中心的PaaS平台，而不是以容器为中心的资源型CaaS平台。
要从公司层面和高度来规划和运营企业/集团的容器云平台，要把开发、运维、IDC团队统统纳入其中，不能指望一个团队就能实现或推动应用的全生命周期管理转型。
容器云平台的价值可以非常广阔，就看如何想、和如何做。
企业的容器云平台应该是活的，而不是死的。它应从小到大，按需增长，而不是一上来就求大求全。
对容器云平台创业公司来说，需要思考如何做以应用为中心的云平台，以及如何赋能企业的数字化转型。
CIO之家 www.ciozj.com 公众号:imciow