作者：王勇

云平台建设过程中普遍存在的两个主要误区有：

1） 唯产品论：这种情形下，以为导入一个云计算产品就能完全实现从传统IT架构到云计算架构的转型。

2） 唯框架论：这种论调往往认为组建一个不大不小的技术团队，捣鼓捣鼓开源框架，稍微封装一下，就能把云平台建设好了。

以上误区一的情形，仅仅是云平台建设的初级阶段，最多完成了从传统IT架构到资源池化的过程，附带一些简单的基础架构的管理功能，但是在实际的建设过程中，云计算产品厂商往往发现自己的产品功能无法覆盖各行各业用户的需求，如果仅仅交付一个标准化的产品，达不到用户的最终需求，需要持续投入一定量的定制化开发工作才能使云平台的建设最终落地。而产品厂商的定位是聚焦产品研发，消耗太多的资源去给用户做定制化是不明智的，投入产出比很低，所以一流的云平台产品厂商正通过逐渐完善自己的产品+开放平台，借助生态合作计划，与各领域的合作伙伴深度合作，提供标准的产品和开放平台API，专心卖好自己的产品而定制化部分交给集成商或合作伙伴去做，通过这种分工合作，实现了“双赢”。

误区二的情形，是云平台建设风险最大的方式，事实证明，没有充足的人力和财力的投入，是根本无法商业化应用的，业界有太多的失败案例，在此不再过多说明。

我们通过各种途径分析过不少云平台建设案例，在很多实际案例中，用户因为缺乏量身定做的UCMP导致云平台在落地使用过程中成为鸡肋，有些用户甚至抱怨“这跟我直接上一个虚拟化平台没太大差异”“云平台产品无法按照我们实际的业务需求进行定制化，用起来不太顺手！”

正如第二节所说，云平台建设落地之后，它并不是一个孤立的系统， 为了与企业现有的IT生态所融合，必然要和很多现有的业务流程或系统做集成或整合，做到IT资源统一管理、数据和业务流程、安全规范上的融汇贯通，这一步是必不可少的，是云平台建设的最终目标，这也是云平台建设中很容易被建设者们忽视的环节。如果缺少了这一步，那么企业建设云平台的意义又何在呢？虚拟化平完全就满足用户需求了。

通过生态建设的思路，这一部分的工作，由生态合作伙伴去完成无疑是最合适的选择，产品厂商和生态合作伙伴各司其职，在云平台建设中形成最有效的合力，所以，根据上述分析，基于“产品+生态”的建设模式，可以完美的规避以上建设误区，使得云平台的落地没有缺憾。

自下而上分别是基础架构层、产品层、生态建设层。

我们先从下往上看，由于云平台对于底层硬件的兼容性已经做得非常好了，所以底层硬件的选择按照既有的经验和套路基本上已经不会有什么问题了。

再看中间层，就是以IaaS为主的基础设施管理层，这一层承担着对底层计算资源的池化、资源调度和管理的重要职责，是云平台非常关键的一层，这也是厂商投巨资所打造的一层，这一层是否稳定直接关系到上层服务目录供给的可用性和有效性，为了降低风险和后期运维成本，这一层强烈推荐使用成熟的商业化产品，如果直接通过开源组件如openstack/cloudstack来构筑这一层则需承担极大的风险。

最上面一层，我们称为“UCMP（统一云管门户）或CMP2.0”，它不仅包含了传统CMP的部分功能，更是CMP的强化版或者说客户化版本，也是直接面向云平台用户的服务和管理门户（IT管理者、资源使用人、平台管理员、运营运维人员等），这一层是云平台落地的关键环节，如果把基础架构层和中间层比喻成汽车的底盘悬挂和发动机，那么这一层就是中控仪表台和变速箱，直接关系到用户体验，由于不同行业的IT生态不同、客户的使用习惯和集成需求也不同，这一层往往需要大量的集成定制化和客户化服务之后才能让企业用户用得得心应手，是云平台建设落地的最后一个环节，推荐在有经验的系统集成商或有客户化定制服务团队的厂商帮助下进行持续建设和优化，保持最高的性价比。

综上，在自下而上建设云平台过程中，标准的基础架构+产品平台支撑+上层门户建设就成了一套最佳实践，是风险最小、总成本（TCO）最低、扩展性最强的“产品+生态”建设模式。