下一代云管理平台？

在IT这个领域里面码农最喜欢做的事情，就是给做的各种东西起名字，起完名字以后还不忘记给他加个缩写，然后在跟别人沟通的过程中，冷不丁地冒出一个词，来判断对方到底是真懂还是假懂。比如Kubernetes这个词，原本是希腊语，κυβερνήτης，是舵手或者飞行员的意思，现在是火热大江南北的开源容器管理工具的名字。我们常常把它简化为k8s，因为从k到s中间有8个字母。各位翻译同学们不要吐血，闷骚的程序员基本上就是靠这个来刷存在感的。说实话，这的确是个非常有用的工具，是不是装懂，几句话就能看得清清楚楚明明白白，省了不少时间。

正因为如此，IT世界里充斥着各种各样神奇的名字。有古希腊神话的，有日文古董的，有用各种彩虹色来指代的，还有生造的新词。毕竟码农们主要的工作就是起名字，写代码的时候定义变量，随随便便就要起几十个甚至上百个名字，如果都用i, j, k, a, b, c的话估计会被人打死。所以我们有匈牙利命名法，驼峰命名法，帕斯卡命名法等等。就好像中国人叫张三到了西方就得叫三张一样，这玩意一点点都不能错，否则又免不得一番鄙视。

在起名字这个领域里面，最让人看不上的就是给原有的名字加上一个“代”字，比如下一代某某某，第X代某某。码农甚至都不高兴给自己的软件产品手工改辈分，连版本号都是在编译的时候自动增长的。如果有人跟码农说有个新东西，叫下一代啥，顿时会觉得矮上一头：“没个高大上的名字也好意思出来装X。”
 

今天我想吐槽的是最近听到的一个新概念：“下一代云管平台”。好吧，这个名字很通用，随便谁都可以说自己做的东西是下一代的，但是关键什么是下一代，没人知道。作为一个从业码农，我确实不知道下一代的云管平台是啥，所以做了一点研究。
 

现在的云管理平台是什么样子？

 
业界分析的扛把子Gartner对云管理平台（Cloud Management Platform）有这样的定义[1]：

云管理平台(Cloud Management Platform)是提供公有云，私有云和混合云的集成管理产品。这种产品的最低要求是包含自助服务界面，提供系统映像，启用计量和计费，并通过既定策略提供一定程度的工作负载优化。更高级的产品还可以与外部企业管理系统集成，包括服务目录，支持存储和网络资源的配置，允许通过服务管理器进行增强的资源管理并提供高级监控以改善性能和可用性。

当然这是一个比较老旧的定义了。在他的Peer Insights里的定义有点更新[2]：

云管理平台（CMP）使组织能够管理多云（即私有云和公共云）服务和资源。他在七个功能领域提供了治理、生命周期管理、代理和自动化等服务。这七个功能领域包括配置和编排；服务请求管理；库存和分类；监测和分析；成本管理和资源优化；云迁移、备份和灾难恢复；以及身份、安全与合规。

在2020年云管理平台魔力象限[3]里又加上了“打包和交付”的功能。
 
Gartner在2018年还有一篇文章：《市场洞察力：您应该构建云管理平台或组件吗？》[4]，提到了云管理平台需要提供的核心能力，包括：部署，自动化和编排；服务请求管理；治理和政策；监控和计量;多云代理;成本透明和优化;容量和资源优化;云迁移和灾备;服务等级管理;安全和认证;持续配置自动化。跟上面那个定义大同小异。作为码农还有幸和这篇文章的分析师Craig Lowery聊过天，我觉得我吹牛的段位也上升了一些。

云管平台这个市场是一个更大的“云管理平台和工具(Cloud Management Platform & Tools, CMPT)”的子集，按照刚才提到的2020新出的云管理平台魔力象限里的说法，全球CMP市场在2019年大概是3亿美金，到2022年年化的复合增长率约20%，即5.18亿美金。
 

和公有云服务提供商一样，上榜的供应商只有7家，包括CloudBolt, Morpheus Data, Flexera, Snow Software-Embotics, Scalr, VMware (CloudHealth)和HyperGrid。上榜的标准其实也蛮苛刻的，包括：

1，通过自己开发，收购或者集成其他平台。
必须拥有以下三个功能：清单和分类；成本管理和资源优化；认证，安全和合规。
拥有以下四个功能中的一半：部署和编排；服务请求管理；监控和分析；云迁移；备份和灾难恢复。
2，必须支持AWS, Azure以及私有部署。
3，GAAP收入从18Q3到19Q2必须超过5百万美元，不算所有额外的服务收入。
4，必须超过100个付费用户，来自于所有的大洲（美国，欧洲和亚太），且在生产环境中使用。
5，一半付费用户必须在公有云上消耗至少5千万美金。

好吧，看看我们自己的CMP，我发现还有很多没实现的功能。不好意思了甲方爸爸，剩下的我们只能帮助您定制开发了。在这么大的领域里，臣妾实在是做不到事无巨细，面面俱到。我还蛮喜欢刚才提到的那篇Craig Lowery和Brandon Medford写的《市场洞察力：您应该构建云管理平台或组件吗？》文章里的哲学调调。他说“云使传统系统管理套件的许多假设无效，这些假设是技术性的，也是哲学性的”。“供应商的战略要做如下选择：要么变成另外一个更全面的CMP的组件，或者成长得更完整”。

至于要怎么选，就不是这篇文章里要讨论的内容了，需要从市场规模和投资角度综合考虑，穷人家的孩子和土豪的玩法自然不一样。

下一代的云管理平台

 
其实我在网上并没有找到权威的对CMP分代的内容。有一篇来自于腾讯的关于云管平台的介绍[5]，说：

“云管平台从发展到今天，共经历了三代：
第一代是虚拟机阶段，主要是虚拟机的申请；
第二代是IaaS，主要是IaaS的监控和管理；
第三代是融合的云服务，主要是一体化的交付，不仅交付计算资源、存储资源、网络资源还有基础软件、数据库、中间件，还有混合云的交付和管理。“

另外一篇是来自于至顶网：《云管平台：一个正在兴起的市场》[6]：

“云管平台从发展到今天，共经历了三代：第一代是虚拟机阶段，主要是虚拟机的申请；第二代是IaaS，主要是IaaS的监控和管理；第三代是融合的云服务，主要是一体化的交付，不仅交付计算资源、存储资源、网络资源还有基础软件、数据库、中间件，还有混合云的交付和管理。”

 
看上去两篇文章应该是互相引用的，内容差不多，都是2017年的文章。VMWare今天已经推出了支持容器的Tanzu，不知道他们自己对这个有没有什么要更新的。
 

让我们再回顾一下Gartner对CMP的定义，和这个所谓的“第三代云管平台”的定义，内涵和外延高下立见。而Gartner的CMP的定义远远超过了这个粗糙的分代。我只能倾向性地认为，这只是一个市场说法，而不是一个完整的定义。
 

不过我倒是看到了另外一篇有趣的文章，是Cloudify的技术路线和愿景设计者Nati Shalom在2017年写的：《使用模型驱动的服务编排创建下一代云管理平台》[7], 跟我之前写的那篇《云管理服务的新演变》观点接近。他认为新一代的云管理平台应该满足三种用户的需求：应用程序开发者，超级用户和运维人员。

新一代的CMP应该采用模型驱动的业务流程优先的方法进行云的管理，而不是像传统云管平台那样采用基础设施优先的方法。

他的观点还是非常有道理的。三年后我对这个观点又更推进了一步：新一代的CMP应该和业务流程紧密结合，不仅满足IT专业人员的需求，还应该满足普通业务人员的需求。随着专业知识不断民主化，云的管理应该通过业务和数据模型来驱动，满足企业的数字化转型的需要。

Nati Shalom认为，新一代CMP和现在的区别在于：
 
在选择云，基础架构资源甚至应用程序框架方面赋予业务部门更高的灵活性。
提供容器支持，因为云本机应用程序是作为一组微服务而非单个应用程序构建的。
集成了用于监视，计费和记录的同类最佳的开源解决方案，为用户提供了即插即用的单一体验。
简化并加快了新框架和新应用的采用，从而消除了通过托管服务（例如，数据库即服务，报告即服务和应用服务器即服务）管理应用程序的复杂性。
使用通用工具将所有内容变为自助服务，从而使中央IT部门可以快速交付所需的服务。
提供应用程序驱动的关键性能指标（KPI）和活动监控，例如已部署的应用程序数量，每个云的实例数量以及每个部署的大小和状态-所有这些均可由业务部门中的应用程序用户轻松访问API。
分享有关可触发适当响应的成本和利用率的可行见解，例如故障转移，扩展或关闭未使用的资源。
将网络和应用程序管理结合在一起，以便网络跟踪应用程序，不仅由网络运营商而且由应用程序所有者进行配置和控制。
 
可以看到，这些观点在今天看来依然不过时。

我顿时对我们自己和市场上现有的CMP的提供商感到万分同情。按照这个说法，大多数公司的CMP还得再重头做一遍。如果这个市场到2022年真的如预测只有5亿美元的话，选择一个更加利基的方向发展才可能成功，否则要么是吹牛，要么就会血本无归。

市场的确是非常残酷，无论现在做得多好，每隔一段时间，都会有新出现的软件公司把旧有的产品和工具打得没有还手之力。我还记得去年10月在硅谷访问一家早期投资公司的时候，创始人就跟我们讲了这个原则，他在做早期天使投资的时候，也是按照这个原则进行投资的。所以干我们码农这一行的，必须持续学习，持续深度思考，避免“学而不思则罔，思而不学则殆”的坑。这么玩下去，头发还会剩下多少？

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！