3同行回答
在有了底层的各类虚拟化资源池之后，云管平台无论是统一资源层还是服务层，都是一种“软件”，所以对于云管平台的技术路线，简单讲就两种：
1.商用软件路线
专业的商用云管平台考虑的面比较广，往往以应用和用户为中心，支持各种高级功能，它的优点是：实施周期短，开箱即用，对于企业自身IT人员的素质要求不高，主要是用户和软件运维人员两种角色。并且对于商用软件的维保，可以通过商务的方式转嫁部分风险。它的缺点是：容易被厂商绑定，兼容性差，定制化差，随着规模的扩大，商用软件的成本也随之增加。比如EasyStack、东软Saca、云宏、IBM ICO+ICM、IBM StartCloud+SelectStack、IBM P4、Vmware Vrealize、RightScale RightCloud、Red Hat CloudForms、浪潮数据中心管理平台InCloud Manager等等，下图是Gartner对商用云管平台厂商能力的象限图：
2.png
而目前的一个事实是：云管平台市场的碎片化程度极高，各产商占有的市场份额都非常低，大部分在10%以下。这个市场呈现出显著的战国时代的特征，这预示着未来几年在云管平台市场的白热化的市场竞争。对于我们企业用户来说，倘若选择商用软件路线，选择与自身企业需求和规划相匹配的云管平台才是最佳选择。
2.研发软件路线
企业自身具备一定的研发实力，可考虑的技术路线，它的优点是：软件代码自助可控，平台兼容性、定制化能力强，十分贴切和匹配企业所需。它的缺点是：需要具有大量的人员和财务投入，并且是持续不断的投入，人员素质和财务需要跟上，项目周期长。同时另一方面，如果走的是开源技术研发路线，由于开源产品的版本迭代快，健壮性不够，方向性不明确，这样带来的纠错成本很高。并且整个开发、维护都由自身完成，无第三方风险转嫁。收起
简答：
约束条件：
1.确定整体发展路线（3-5年）
2.近期目标
3.资源现状
4.系统现状
5.人员和团队能力
6.管理流程
7.成本
8.安全
。。。
根据约束条件考虑：
1.开源架构为主还是商业架构为主，考虑上述1、2、5、7
2.自建为主还是采购供应商为主，1,2,5,7
3.CMP应当具备的BSS、OSS及云分析能力要求，12345678
4.对于异构资源的管理，。。。
5.对于组织流程的衔接，。。。
6.对于已有IT系统的对接，如LDAP、工单、CMDB等
。。。
浏览1873
简单的分析如下：
- 技术人员理想的云计算是什么?
- 理想和现实的鸿沟是什么?
- 云计算到底需要什么样的基础架构?
- 云计算基础架构可能的组成部分。
- 虚拟机和App Engine等云计算的关系。
强调一下——本文仅以开发人员视角出发！以大中型互联网公司、海量数据、多业务线运维为背景，围绕后台基础架构进行分析讨论。
我们到底要什么云
现在的麻烦
谈理想之前先回顾当前现实中RD（开发人员）和OP（运维人员）的工作场景。作为一个”过来人”，分析一下RD和OP在开发、测试、部署一个新应用时不得不做的那些麻烦事吧。
开发阶段面对的麻烦：
Ø 可用性问题——互联网应用作为在线服务都希望能永远在线；而从成本考虑，规模使用廉价PC SERVER、廉价硬盘、廉价路由器等必然就会出现相对较高的故障率，甚至可以说故障是常态，因此从应用设计上必须考虑故障切换，而且最好是自动透明的故障切换。
Ø 负载均衡问题——无论存储集群或者是应用服务集群等都可能出现负载不均匀情况。同一集群中因种种原因总是会有热点（因为访问压力大而造成的或磁盘空间不 够、或内存不足、或CPU负载太高、或网络带宽不足）出现，当热点出现时，就需要将热点的访问流量分流到比较冷的服务器上去。总之希望集群中的服务器冷热 均匀，服务才能稳定、高效。
Ø 扩容缩容——当你的应用用户越来越多时，就要有扩容要求（集群中补充新机器），扩容时最好能不停或者少停服务。
上面这些问题，其实是分布系统的普遍共性问题，解决办法无非是采用supervisor、主从热备、smartclient、状态报告、一致性哈希、数据分区等等技术，兵来降挡，水来土掩的case by case的解决。
作为一个在线应用RD（开发人员），很可能在处理上述问题花的功夫，比自己应用逻辑本身的还要多不少，这显然是一个不小的负担。测试阶段面临的麻烦
测试首先在于搭建环境和系统部署。这点说起来简单，其实现实操作中可够你折腾一阵了。因为你不得不做：
Ø 抢到足够多的机器——你很可能要排队、要求人、总之要费点点功夫。
Ø 搭建存储服务——应用开发人员对存储系统各种配置参数和部署方式的理解和摸索过程，绝对是一个常犯错误的窝工活。
这个过程对很多RD和测试人员来说，绝对比写代码要费时费力。沟通成本（公司大了，很多沟通都是跨部门的）不容小视呀。
部署的麻烦
Ø 容量规划——一个应用上线前肯定需要根据经验（或者拍脑袋）估算出未来一段时间内系统面临的负载。估算少了，肯定要面临扩容的风险，这无疑是自搬起石头砸自己脚。再加上一些好大喜功的人类天性，应用负责人肯定会满打满算的推算出最大可能的机器规模。
Ø 申请机器，搭建集群——申请机器意味着报计划、等审批、等机器、走麻烦的流程（这很多都是经理的事啦）。搭建集群则是RD和OP一起携手完成（RD出上线 步骤等，OP 实施），这个过程要小心谨慎，需要不止一个人反复检查（差劲点的应用会是实例配置不统一，每个实例的配置都有所区别），还常常需要RD陪同实施，总之绝对 是个体力活。
Ø 备机准备——很多应用为了防止意外机器硬件故障（硬盘、主板、网卡、电源等坏了）下，能快速进行故障恢复，还会搞一些备机，以防万一。这些机器纯粹是养兵千日用兵一时。
任何一个自认为重要的应用都希望自己单独占领一个集群，如果和别人混合部署，害怕资源征用，自己被拖累。鉴于此原因一个应用往往就意味者需要搭 建1个以上集群（很可能存储、或者其他服务都要单独搭建一个集群为其使用）。应用RD人员还好说，为自己应用搭建一次就OK了、存储等基础服务RD就要多 搭建几次，受点累了；而OP就更辛苦了，要不断重复这些体力劳动。
容量规划和备机准备多多少少会带来物理资源的闲置，容量规划意味着预先准备未来一定时期内都足以应付请求压力的足够机器，那也就是说初期用户规模还没上来前，压力还不大时，集群中多余的机器或者每个机器上的多数资源都会被闲置。
一言以概之，困扰我们是:
**系统分布化带来的麻烦
反复沟通带来的麻烦
搭建环境带来的麻烦
资源浪费**
浏览1914