欢迎关注原创公众号：
前言导读
大数据、人工智能、云计算是现代企业在IT方面听闻最多的名词概念。有的企业从中受益，业务快速增长，盈利大幅提高；有的企业投入巨资，但未有本质改变，没有达到预期效果，不得不中断投入进行止损。在国内大多数中小型企业甚至部分大中型企业，对上述名词仍停留在概念阶段，高处不胜寒，都知道对企业经营是有益的，但是如何落地，是最关键、最难以解决的问题。
大数据、人工智能和云计算三者的关系是什么样呢？
云计算平台作为基础服务平台，下接硬件基础设施和数据中心机房等，上面承载大数据分析、人工智能以及公司业务系统、办公系统等。云计算平台虚拟化基础设施硬件，形成计算资源池、存储资源池、网路资源池和安全资源池，以资源池的形式为上层系统提供服务载体。企业IT最终的目的为了持续盈利，所有的云计算、大数据、人工智能都是作为企业盈利的一种手段，一种工具，都为同一个目标服务，企业进行信息化或是数字化，最终目的都是以最少的成本，实现最大的盈利，最持续的盈利。
第一章、全面详解云计算
一、企业IT建设发展的痛点解析
在介绍云计算的定义及相关内容之前，建议先从企业IT建设和发展的痛点入手，因为任何一项新技术的出现都是围绕解决老问题、提高效率、降低成本提高营收三个主题进行的，云计算也不例外。
企业（尤其是大部分传统企业）在进行信息化、数字化建设的时候，往往面临很多制约因素，我们称之为IT痛点。企业IT是为企业快速、高效经营服务的，或提高效率、或提高营收、或节省成本。大多数企业的信息化规划和发展整体是滞后于企业业务发展的，信息化建设的速度难以匹配业务快速增长的速度；当然也有不少企业（很多中大型传统企业转互联网化是该类企业的典型）的信息化发展过快，远远超过了业务的规划和发展，而IT设备的生命周期一般五年左右，过度超前的IT规划和发展不但造成了投资浪费，也造成IT资源的浪费，进而增加企业经营成本，违背企业IT信息化建设的初衷。所以企业IT的规划和发展最关键的是不能脱离业务、不能滞后业务，要有一定的前瞻性，但步子又不能太超前，需要在业务、技术、投资等几个方面进行均衡考虑。整体来讲，IT的规划发展和业务的规划发展要同时在企业的整体战略框架下，同时IT规划发展要基于业务规划发展并且超前业务规划发展，为企业业务的快速发展提供助力支持，杜绝超前规划和滞后发展。
除了IT规划和发展之痛外，IT投入和成本一直居高不下，但又缺乏科学准确的数据分析解释，进而导致企业在IT信息化建设的日常过程中，逐渐在高层和业务部门失去信心。通常还会面临采购制约、性能问题、管理复杂和网络安全等痛点,往往这些痛点制约着企业IT信息化的发展建设也直接或间接的增加了企业IT成本。
1、采购痛点
痛中之痛选最痛，应该是就是采购方面的痛点了。就笔者和身边的朋友来讲，IT发展尤其是在设备和服务采购方面，最头疼就是公司的采购，这包括资金预算方面的制约和冗长的流程审批节点，甚至还包括繁杂的招标文件和招标流程。
1.1、资金预算制约
很多企业中，一般是年底12月份的时候做下一年的IT预算，而在IT作为非主营业务的企业中，往往IT的年度预算是最容易被公司砍减的部分。就个人经验，很多时候会被砍掉预算金额的30%左右，有时甚至更多。IT部门在做IT预算的时候，可能是基于程序员诚实这一基本特性吧，一般都是根据实际需求进行预算，几乎不会过度虚报预算，而恰恰是这种根据实际适度预算得出的数字被砍掉部分之后，新一年的IT发展就会略显紧张，倍受制约。随着企业所处环境的激烈竞争和大环境的快速变化，企业的IT在一年发展中经常会遇到一些临时性的紧急需求：如公司的新兴战略、企业网络安全大面积瘫痪、公司的兼并实施等，这些需求往往会被忽视，或是IT部门被动接受，同时不得不主动的申请增加预算。
1.2、流程审批制约
大多企业都在做简化、优化流程的事情，这说明企业中存在很多复杂、冗长的流程。涉及IT相关，除了与公司的领导、财务有关系之外，往往跟公司的业务使用部门也有很大的关系，所以整个流程就会比较复杂，涉及节点多，流程进展缓慢。以采购IT设备为例，整个采购流程可能要包括：呈批、招投标和竟比价、结果呈批和合同预审、采购签署合同等，除了IT主管和分管领导、财务部门、采购部门（可能有）和公司高层参与审批之外，可能还有关系比较密切的业务部门的审批，例如销售系统的IT设备采购可能需要销售部门的领导审批等。繁杂的审批节点走完之后，直接有定点采购单位的还好，没有的话，则需要进行招投标、竞比价等，采购完之后，可能会有审计部门的审核等等一些列流程和审批的制约，一套流程下来快则俩周，慢的有半年，机会窗口早已关闭。
2、性能痛点
系统的性能也是制约企业IT规划发展滞后于业务规划发展的重要因素之一。系统运行缓慢、数据库性能低下、页面打开慢等等，都不同程度的制约业务的飞速发展。增加硬件设备和提高系统配置，是提高性能的一个重要途径，这需要提前做好备品备件的准备和硬件设备的冗余，否则临时采购可能会有漫长的流程审批制约。但是对于突发性事件，如市场部的促销、秒杀等活动，短时间内系统大流量、高并发，需要快速的在线扩容，高峰过后，需要在线收缩，而这在传统IT的意义上，几乎很难实现，即使准备一堆物理机应对高峰活动可以勉强度过（前提是网络问题也要解决），但高峰过后大部分时间都是处于浪费、空转状态。
同时系统的架构也影响着整体的IT性能，如经典的、传统的IT三层架构：应用服务器-数据库服务器-存储，除了成本不低这一缺点外（FCSan光纤存储每次扩容除了硬盘费用外还需要支付授权费用、服务费等），集中式的数据存储和部署，做不到细粒度的调优，也可能存在单点故障的问题。
网络性能问题是另一重要性能问题点。鉴于国内特殊的网络环境，电信、移动、联通之间的网络互访，往往会有性能延迟甚至不可达的问题产生，如部署在电信环境下的网站系统，在联通和移动的访问明显慢于电信环境，省内用户访问慢于省外用户等。自己解决跨运营商的性能问题几乎不可能，往往需要借助于CDN、智能DNS、多地部署等手段解决，不只是增加IT投入的问题，还增加了IT的管理复杂度。
作为IT管理者，性能问题是一个不得不重视的关键性问题之一。因为这涉及到其他业务部门和客户对IT系统的评价。糟糕的用户体验必将削弱高层对IT部门信心，进而在资金投入和政策支持上大打折扣，IT部门再次陷入资金预算的死循环中。
3、管理痛点
企业IT管理的痛点除了上面在做资金预算审批和性能瓶颈之外，还存在着缺少资产管理和CMDB、对所有设备缺少数据分析和报表展示导致IT投入和产出不可视，以及标准缺失、IT流程不完善、人工运维低下等管理方面的痛点。
3.1、CMDB缺失
以IT资产管理为核心的CMDB的缺失，导致IT管理缺少基础运维数据，进而影响实际使用数据分析和自动化运维等。IT资产管理是CMDB的基础重要部分，但是CI之间依赖关系才是CMDB的精髓，即：系统与系统之间、系统与设备之间、设备与设备之间的数据内容和流向以及依赖关系等。本文不探讨CMDB的建设，但是建议在依赖关系的存储上建议以Neo4J图数据库为主，依赖关系展示建议如下两种方式：
企业IT元素之间的依赖关系是最难梳理和存储的，同时其实时准确性有非常难以保证，这需要企业根据自身实际情况选择比较好的技术方案进行落地实施。
3.2、数据分析缺失
详细的数据分析是对企业IT实际运行最好的阐述，是企业CIO/CTO和管理高层迫切需要的数据，透过数据可以直观详细的看到IT的投入和产出。但往往在企业IT实际运营管理中，这是最容易缺失的。
常见的数据分析包括IT投入年月度分析、IT资源利用率、空置率、IT资源性能监控、IT系统耦合度等。但对于大多数中小型企业甚至部分中大型传统企业来说，IT数据分析是一个比较困难的事情，这需要持续的系统监控和数据收集、数据整理和数据分析以及数据存储等。IT管理中在报告年度预算和进行项目资金申请的时候，最头疼的可能就是被领导问为什么要买，为什么现在不满足，缺多少，诚然，缺少数据这一强有力的支持，任何语言描述都显得苍白无力。
3.3、运维标准和自动化缺失
管理方面的另一痛点就是效率低下。造成效率低下一般来说有两个原因：过度重复的人工操作，缺少自动化、智能化的工具或方法来提高效率；标准化和流程化不完善导致实际工作混乱，拉低整体工作效率。
自动化、智能化与标准化、流程化这二者其实是有一定必然关系的。自动化是建立在运维的标准化和流程化的基础上，缺少标准化和流程化的支撑，自动化难以建立和完善，智能化更是如空中阁楼，难以落地。只有夯实完善的标准化和流程化的支持，运维的自动化和智能化才会快速、完美的落地实施，进而提高整体的工作效率。效率的提高往往意味着成本的节省和收益的提升，从整个IT管理来看大有益处。
很多时候，因为CMDB的缺失、运维标准化和流程化、自动化的不完善往往会导致运维的监控、运维的备份以及运维安全等都不可控、不完善、有遗漏，管理层面的数据分析更是残缺不全、难以可信。
4、安全痛点
企业在进行IT建设和日常工作中，网络安全是一个不得不面对的关键环节。尤其是国家大政策和国内外复杂的网络安全环境，让网络安全真实的来到我们的身边：自2017年《网络安全》的颁布到2018年三月份习总书记提出没有网络安全就没有国家安全，再到网络安全等级管理保护条例等一些列法规和政策的颁布，网络安全已经提升至国家战略的高度；网络安全就在我们身边，前几年看到的企业遭受网络攻击，中病毒可能主要出现在媒体和网络上且大多是大型集团企业，但最近这三年以来，尤其最近一年，自己的企业、周围朋友的企业大多都遭受过不同程度的网络攻击，常见的有木马、挖矿、勒索病毒、钓鱼邮件等等。企业所处的环境往往也决定企业不得不重视网络安全：以青岛为例，2018年上半年上合峰会的召开，各个主要企事业单位基本都是网络安全重点防护的对象，不同层级的监管督查单位以及整体的行政任务都决定了企业不允许出现网络安全事件，必须重视并且能够做出快速反应。
网络安全的攻防不对等一定程度上也决定了大多数企业在网络安全处于被动的地位。资金、技术和内外风险威胁都是网络安全建设所面临的严重问题。而在实际企业中，网络安全部门或网络安全人员往往是最容易缺少、被忽视和最受委屈（受委屈的前提是努力、负责的完成工作）的角色。根据不太精准的调研（咨询周围朋友和同事），以青岛、济南和南京这几个二线城市为例，中小型企业绝大多数是没有网络安全专职人员，中型和大多数的大型传统企业会配备一至两名网络安全专职工程师，这还往往专职网络安全的同时兼职其他打杂工作，只有少部分的大型企业，尤其是大型国有企业会有专门的网络安全部门，设立CSO角色。在网络安全设备方面，更多的是只有防火墙，一些中小型企业甚至边界防火墙都没有（这样的企业真不少），中大型企业的网络安全设备会相对丰富一点，但是大多都是独立的防护，缺少整体的联动。根据我咨询的九家企业，在最近一年里，都出现过网络安全事件，遭受不同程度的损失，另外大多数很头疼的一点事不知道企业所面临的风险和威胁，不管是对内还是对外，虽然有网络设备的告警提示，但是海量的告警信息和网络安全信息孤岛导致很难精准把控企业网络安全情况，此乃网络安全至大痛。
5、其他痛点
企业在进行IT建设和管理中，除了上面介绍到的一些痛点之外，还存在着系统备份缺少或是不完善、不准确的问题；同城或异地灾备建立成本高，难度大的问题；企业应急演练缺少系统的计划和管理；作为集团型企业，各个分子公司在租用集团资源时的准确计费问题；等等一些列的问题。总结归纳，一个是钱之痛，一个是活之痛：花钱投入多但未见效果，花钱投多少，实际效果更差，投入与产出难成正比。
但是这里必须要提前说明一点的是，云服务可能会解决部分痛点，但绝不是全部。新的技术和工具只是辅助手段，企业IT经营的最终目标还是降低成本，提高效率实现公司的最大化盈利和持续盈利。
上面介绍了企业IT的一些痛点，这些痛点很多时候会制约IT的快速发展，导致IT的实际情况和发展速度匹配不上业务的需求，那么怎么解决掉这些痛点，为企业的IT发展提速增效呢？企业上云，通过云服务助力业务发展，可能是一条不错的路子，但这只是可能，还得根据企业自身的情况和业务发展，具体问题，具体分析。
二、云计算的标准定义
云计算这一理念和概念起源很早，早至二十世纪八十年代就有SUN公司提出“网络是电脑”的思想，用于描述分布式计算技术带来的新世界，今天的云计算正在将这一理念变成现实。但介绍冗长的科技史往往用途不大，特将一篇介绍云计算历史的文章分享如下：
http://www.360doc.com/content/19/0106/07/61653391_806831128.shtml
云计算、云服务、云平台等概念名词非严格来讲都是指的同一事情。百度百科是这样解释云计算的：云计算 （Cloud Computing）是基于互联网的相关服务的增加、使用和交互模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。对云计算的定义有多种说法，对于到底什么是云计算，至少可以找到十几种解释。现阶段广为接受的是美国国家标准与技术研究院（NIST）定义：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问， 进入可配置的计算资源共享池（资源包括网络，服务器，存储，应用软件，服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。可以从定义中提取一些关键词：按量付费、资源池、快速提供、少管理工作等。关于云计算可以提炼出一个“5+3+4”模型，即：
5个基本特征：按需自助服务、广泛的网络访问、资源池、快速弹性、测量服务；
3种服务模型：云软件即服务（SaaS）、云平台即服务（PaaS）、云基础设施即服务（IaaS）；
4种部署模型：私有云、社区云、公共云、混合云。
对于云计算的理解，从简单类比来说，常用的比喻有水电、水果等日常场景，但从技术角度来看，云计算实质性就是将资源池化：包括计算资源、存储资源、网路资源和安全资源甚至包括管理资源和人力资源等。这些池化的资源可能是部署在自己的机房供其他人使用（此时你是云服务供应商），也可能是你不再需要购买硬件设备和建立机房，直接租用别人的资源（此时你是云服务客户）。这样做有什么好处呢？对于云服务供应商而言，将池化的资源进行使用并且加以利用对外界提供服务，既提高资源利用率又能够获得额外的收益；对于云服务使用客户而言，不再需要建立机房和购买物理设备，直接使用池化资源，更加快速、便捷。
云计算的主要特点有如下：按需服务、快速部署、弹性伸缩、自助计费、持续可用、超大规模计算能力、成本低（成本是否真的降低有待进一步探讨）。
三、云平台分类
3.1、云计算与虚拟化
可以说虚拟化是云计算的技术基石，同时云计算也是虚拟化技术的进一步发展、变革和升华。通过对物理设备进行虚拟化，包括计算虚拟化、存储虚拟化、网络虚拟化等技术，对IT基础资源进行池化，对上层应用屏蔽底层物理设备，进一步提高资源利用率和系统的稳定性。常见的虚拟化技术有基于vmware商业化的vsphere和开源的kvm，从这二者演化而来的云平台有vmware商业化的vCloud和OpenStack以及其他等。对企业来说，建设云平台有商业和开源两种技术思路可行，但选择哪一种或是如何结合，这需要结合企业自身的技术实力和投入成本，我之前做过针对某企业云平台技术选型的调研报告，大致请参考《附件一、某企业云平台技术选型调研报告（简）》（仅供参考，不代表任何商业观点）。
虚拟化最早的使用场景多为企业内部使用，这也是企业私有云得以快速推广实施的重要原因之一。但是相比虚拟化，云计算在弹性伸缩、租户管理、按需调配及编排、自助计费、IT运营等方面得到了长足的补充、提高和完善，并且可以支持超大规模的计算和存储，跨区域的网络架构等。
虽然云计算最早是基于虚拟化这一技术基石，但随着近几年的快速发展， 云计算已经完美支持ironic裸设备、docker容器化等技术，并且相互补充、相互完善，共同促进了整个云计算生态圈的发展和完善，为不同的应用场景提供不同的最佳技术实践。
3.2、云计算与容器化
容器化是最近几年呼声很高、讨论很热的一种技术解决方案，大有取代云计算、云平台的风头，网上也有类似的论调。对此，我切以为容器化应该是云计算的组成部分之一，跟虚拟化技术一样，可以成为云计算的技术基石之一，并且二者在某种程度（稳定性、安全性以及主机隔离性）上，二者应该是可以相互补充、相互完善的。
容器化比较适合轻应用部署，其对微服务具有天然的支持，通过工具链构筑DEVOPS持续交付平台，可以大大的提高交付效率，特别对于需求多变、迭代频繁的业务场景，可以极简地缩短交付时间、提高交付效率，同时也可以快速应对访问量陡增陡减情况下的快速伸缩。
图一
图二
但是，对于传统的中大型系统（微服务拆分后，比较适合容器化部署，但收益不是很大，因为其系统需求和访问都相对比较稳定，变化不大）以及数据库应用不是很适合，就关系型数据库不适合容器部署方面，有如下几点原因：
（1）数据安全方面的问题：由于容器底层技术的限制性和数据库底层开发兼容方面的考虑，容器运行数据库会存在数据安全的问题，特别是容器异常或是崩溃，数据库未完全关闭的情况下，会损坏数据；
（2）数据库性能方面的问题：追求关系型数据库或数据仓库的高性能时，我们往往会采用裸金属的方式部署，屏蔽操作系统的一部分瓶颈，或是直接在优化之后的OS上部署，同时数据库的性能大多数出在IO方面，采用容器部署运行数据库，层级复杂、IO负载进一步提高，会大大影响数据库的读写性能，与数据库高性能最佳实践相悖。
（3）天然的对立面：容器技术特别适合部署运行无状态的服务，并且其数据持久化依赖于外置设备，而数据库是典型的有状态的持久化的服务，二者存在对立的情况，强行在容器跑数据库需要考虑状态持续性以及数据持久化两大因素。
（4）资源隔离方面：容器技术在资源隔离方面较虚拟化计划差不少，Docker是利用Cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。如果其他应用过渡占用物理机资源，将会影响容器里数据库的读写效率。需要的隔离级别越多，获得的资源开销就越多。鉴于资源隔离方面的先天不足，在容器整体规划方面，如果产生统一服务器上既有应用又有数据库，那么其在性能方面会相互影响，而在数据库的最佳实践中，应用和数据库是要分开部署，其二者对服务器资源的需求也是大不一样的。
但是仍有部分企业将数据库部署在容器中，特别是mysql，我认为这也是有一定业务场景支持，也是比较合适的。如：对负责系统进行微服务拆分和数据库拆分，每个服务对应相应的数据库，二者绑定较深，这种情况下为了便于管理和扩展，是适合容器部署的，但是在扩展方面需要结合数据库的高可用和读写分离架构进行；另外还有一种是比较适合运行的，如数据库本身就是分布式的数据库且所存储的数据并不敏感，安全性要求不高，如网站的流量分析、搜索的索引词存储等，可以利用分布数据库的分片来增加实例数，从而增加吞吐量。
3.3、IaaS、PaaS、SaaS等
从系统的组成架构方面来看，其构成关键从物理底层到应用数据的参与因素有3个部分：
（1）基础设施：底层物理设备包括机房、网络、存储、物理机以及虚拟化和操作系统等。
（2）操作平台：系统运行时的中间件、中间设备等。
（3）软件和数据：应用代码包和数据等内容。
按照自己管理和云平台管理的范围简单划分IaaS、PaaS和SaaS,具体如图：
其中IaaS成为基础设施及服务，解决的是运维人员的主要问题，面向运维主题。主要通过云平台技术对数据中心机房、网络、存储以及计算等物理设备（包括安全设备）进行资源池化，为上层应用提供底层的资源支持，并且围绕池化后的资源提供租户管理、自助申请、弹性伸缩以及相应的运维辅助等服务，进而为IT建设和管理屏蔽掉底层的复杂性，使其可以更加专注关心上层建设。
PaaS为平台即服务，多面向于开发者，为系统运行提供必要的开发组件和中间件的支持。通过PaaS平台可以为开发者提供快速的环境支持和能力沉淀，大大提高开发效率。
SaaS为软件即服务，面向业务人员，通过SaaS服务直接提供企业业务所需的系统和数据，不需要本地运维部署和开发，所见即所得，按需申请和使用服务。常见的有Google的DOC服务、salesforce的CRM、有赞云商城、钉钉办公、问卷星、金数据等。使用SaaS服务可以为中小企业大大的降低IT资金投入，同时有效地借鉴厂商的最佳实践，可以尽快的验证和辅助业务的快速增长，但是随着业务的发展，特性化和差异化的需求越来越多时，SaaS厂商不一定能够快速响应。不过SaaS服务市场仍然有着巨大的潜在价值。
除了上述的IaaS、PaaS、SaaS三种服务外，常见的还有CaaS、DBaaS、FaaS等,这些大多是从某一技术类型而言的，如CaaS容器及服务，通过容器云平台的建设，结合DEVOPS工具链充分发挥容器的部署、编排等优势打造持续高效的交付平台；如DBaaS,通过构建统一的数据库平台为业务系统提供稳定、高效、快捷的数据库服务，并且统一管理、统一监控、统一备份，对性能方面提前优化和持续优化，可以有效地降低数据库的运维成本提高数据库运行效率。
3.4、私有云、公有云、专有云、混合云和多云
上述云计算的标准定义中讲到，按照部署模型来看，云计算分为私有云、公有云、专有云以及混合云四种模式。其实四种模式的理解也比较容易，私有云即企业内部实施部署、管理和运营，仅供企业内部各业务部门或是各个分子公司使用，具备云的基本属性；公有云为大型IDC厂商或云服务商承建和运营，企业作为用户或是租户，不需要本地实施建设，租用其资源或服务；专业云多具备行业属性，是对某一行业进行业务系统沉淀、共通抽取进而建设的一种主要服务于某行业的公有云服务，如医疗云、金融云等。
在实际企业IT建设和发展中，很少只使用某一种云模式，大多根据其业务属性、分布地域以及业务需求，选择几种云模式共同承载其系统和数据，即混合云的模式。同时为了进一步提高系统的持续可用性，杜绝把鸡蛋都放在一个篮子里规避单一云（特别是单一公有云）故障导致的系统中断，多采用云上、云下互备或是多云混合的模式，即混合多云平台。
四、云计算优劣势分析
云计算的优势主要基于其自身的特点：
（1）按需服务、快速部署、自助计费。一切所需要的资源和服务都可以根据自身的需要在云计算提供商处获取，因为云计算供应商强大的技术支持能力和PaaS、SaaS的快速发展，使得部署更加简单快捷。云计算提供的资源和服务皆可自助计费，对于所投资源和成本有较好的数字化展示。
（2）弹性伸缩、快速大规模计算能力
云计算另一最重要的优点便是弹性伸缩和能够快速的进行大规模的计算能力。这对有对外发布系统的企业非常重要。以下场景举例：企业在自己的电商平台或销售平台对用户或客户进行促销活动或秒杀活动。传统方式这对IT部门是一个蛮大的挑战，可能需要准备不少的服务器和网络资源以便应对高并发和大流量的场景，且不说准备的资源能够顶住高峰的压力，峰值之后，很多资源会处于空闲状态。而云计算平台则基于按需服务、按量计费以及弹性伸缩的特性，可以根据系统负载情况进行动态调整，按需、按量计费，不会造成额外的资源浪费和资金浪费。超大规模的计算能力除了可以帮助企业应对业务高峰之外，还可以帮助企业进行大规模的计算处理能力，如大数据的处理、复杂业务的计算等，这在一些实验室会有相应的场景。
（3）云生态资源的共享共用
云生态资源的共享共用主要体现在以下即可方面：
a)、优秀先进的技术、经验和高性能的设备资源。采用云计算平台最直观的的就是在技术、经验和设备方面的收益。不管是公有云服务商还是私有云供应商，其大多基于自身或行业的先进技术、经验完成。例如计算、存储的高可用部署，网络的高并发、高带宽，应用、数据库的集群和分布式部署方式，操作系统性能优化、安全加固，数据库性能优化、安全加固等等，采用云计算平台，可以直接将这些技术和经验拿过来使用，避免重复研究，再造轮子。另一方面，采用云计算平台，可以不需要单独投入资金购买价格昂贵的高性能设备资源，按需使用，提高性价比。
b)、行业数据和大环境分析数据。
云计算规模发展到一定程度之后，相应的行业数据分析和大环境数据分析会在云平台处逐渐成形，这部分数据可以为企业经营提供借鉴意义，同时企业本身也可能是数据生产者一员（具有两面性，贡献数据促进行业数据分析；云环境下数据安全性不可控）。
c)、云生态资源的高度利用。这个主要是针对PaaS和SaaS层。依托优秀企业的PaaS、SaaS的服务经验，对其进行产品化对外提供使用，如国内用友云、国外的salesforce、Googledoc等。对这类资源企业只需关注自身的业务即可，无需关心底层硬件架构，而且业内领先的设计方案能够为企业自身发展提供建设性指导意见。
云计算因为其自身按需服务、自助计费、快速部署、弹性伸缩、超大规模计算能力等一些列特性，相比传统的IT架构和部署方式有着非常多且非常显著的优势。但也恰恰相比传统部署的这些特性也带来系列的风险和不稳定的因素，主要集中在数据安全性、云服务稳定性以及云服务关闭的善后等问题。
（1）数据安全性问题
相比传统封闭部署的方式，企业采用云服务之后，其自身的系统、数据便不再由自身自主可控，而是放在云平台，其数据的隐私安全一直是业界讨论的重点之一。绝大多数的存有敏感数据的企业在选择云平台方面还是非常低调保守，大多只是边缘性业务上云。对于数据安全性问题还是要一分为二看待：首先规模比较大、比较正规的云服务提供商，其在数据安全保护方面的技术和策略上一般是大大优于传统企业部署方式，不管是在受攻击检测防护还是数据防篡改防泄漏等方面；另一方面，对于频频爆出的云安全问题，从企业经营者角度来看，放在本地，物理隔离才是最安全的方式，不信任云厂商，尤其在国内企业非常盛行。但有一点不得不承认，云平台受攻击的可能性和遭受攻击的频次是远远高于企业自身的攻击可能性和频次的且云平台在遭受攻击之后，云供应商很难讲重点放在某一企业的恢复上，大多聚焦于整体的云平台修复。
（2）云供应商的稳定性问题
其实2018年是云服务商比较痛苦的一年，也是用户对云计算信心值比较低的一个年份。
2018十大云宕机事故盘点：主流公有云无一幸免！
1 月 18 日：谷歌云自动化失效导致宕机
3 月 2 日：AWS 宕机致部分 Alexa 失声
5 月 31 日：AWS 北弗吉尼亚地区数据中心出现硬件问题
6 月 17 日：微软 Azure 爱尔兰数据中心宕机
6 月 27 日：阿里云故障
7 月 20 日：腾讯云云硬盘故障
7 月 24 日：腾讯云宕机
Prime Day：亚马逊 AWS 故障
9 月 4 日：微软 Azure 数据中心遭雷劈宕机
11 月 9 日：谷歌公有云下的 Kubernetes 服务（GKE）宕机
随着2018年的逝去，2019年，云服务提供商在稳定性和安全性方面必将加大关注，重塑用户信心，同时多云部署也将逐渐成为2019年企业上云一个不得不关注的的问题。多云部署除了规避单云部署故障的同时，也可以一定程度上规避下面的云服务关闭后的善后问题。
（3）云服务关闭后的善后问题
正所谓未雨绸缪，云服务关闭后，我们在云上部署的资源该如何处理，这是企业在做云规划的时候必须要面对和正视的问题。云计算作为一门相对新兴的技术，除了知名的大厂外，还有很多不知名的中小企业在提供服务，可以预见在不久的一段时间后，这个市场将面临着洗牌，那我们部署在云上的应用和数据怎么处理呢？虽然各个厂家都提供了方案，但是作为企业经营者必须重视，毕竟云供应商面对的是成千上万的厂家，我们自是其中之一，但是作为企业自身，其应用和数据则是全部。在这方面除了考虑云服务关闭之后，系统持续运行的方案外，还应考虑云上的数据资产如何安全平稳的下线，尤其是数据的安全隐私性保障不外泄。这一方面也印证了2019年，企业在设计云平台的时候要着重关注多云平台的架构。
云计算、云服务的优劣势大多都是基于其自身特征的两面性展示。任何事情都没有绝对的完美，只能在自身实际情况的基础上，进行相互平衡，选择最优方案，同时做到趋利避害，将风险降至最低，可能引发的损失减至最少。
云计算的优势还有：管理便捷
云计算的中性特征：价格实惠、稳定性强等
五、企业规模、业务类型与云平台
云平台的选型、设计、建设及迁移等与企业其自身的发展规模、业务类型、技术实力以及系统架构等密切相关，科学合理的选型、设计是企业实施云平台的关键第一步。从经验论大量真实案例的角度来看，大致有如下的建议：
对于传统的小型企业（100人以下、业务比较单一、信息系统数量少、使用率低），可能只需要1-2台物理机即可承担其信息系统的企业，完全不需要数据中心机房和专业的供电保障等，这类企业按照既有模式部署即可，最多在物理部署的基础上增加虚拟化，提高一点资源利用和高可用。但是随着公有云及SaaS服务的快速发展，建议这类企业的管理人员多使用敏捷的云服务代替传统的服务，如钉钉办公、腾讯视频会议、云ERP、Salesforce等，简便快捷、功能全面，关键是投入成本较低。
中小型企业特别是互联网企业多适合选择公有云来承载其自身的系统及数据，成本较低、简单高效，且暂不需要专业的运维人员。另外该类企业多处于业务发展的快速增长和业务方向的快速转变时期，其系统的更新迭代非常快，采用公有云服务，可以让企业IT有更多的研发精力以及公有云的借力（借的力有计算存储弹性资源、高效快速的网络资源、组件化的系统架构如消息队列和日志服务等、运维支持保障等）来支撑业务的快速发展和快速转变。这类企业IT的主要任务是支持和验证业务方向及实践的及时准确性，系统的稳定性和安全性可能不是第一要务。但是在这个过程中往往会欠下较多的“技术债”，这需要在前期的系统架构和数据库架构的时候，适当的进行技术前瞻（系统架构分层、前后端分离、动静分离、微服务拆分及数据库拆分、公共基础服务的中台积淀、架构简洁、系统进一步解耦等），尽量降低还债的成本和压力。
中大型企业或集团型企业其自身业务系统多比较固定、业务发展速度及方向也大多进入到稳定期，这类企业可能对着自身的自身的发展沉淀了比较多的信息系统、物理设备甚至是数据中心机房等。这类企业的IT建设和发展多以保障系统的稳定和安全为主，从系统分类上来说，大致可以分为：核心生产类系统（负责产生产品或是产生效益）、市场营销类系统（负责销售产品推销服务）、办公业务类系统以及其他类系统。其中市场营销类系统多面向公共用户，具备互联网系统属性，适合借助公有云的弹性扩展、CDN多节点异地快速访问、云安全等来应对大流量、高并发的业务场景；核心生产类系统以稳定可用为主，适合私有云环境部署，为核心系统运行提供稳定的、便捷的基础环境；办公业务类系统多面向企业内部人员，且随着移动办公的快速发展，适合公有云部署或是SaaS服务的选择，本地部署加外网访问的方式也可，但是安全性有待提升；其他类系统如安防门禁、录音电话、运维管理平台等，多属于内部应用，建议私有云单独划分区域进行部署。集团性企业，分支机构、分子公司较多的情况，特别适合混合多云的架构，通过混合多云平台整合全集团的IT资源及能力，将IT部门逐渐转变为运营部门，进一步提升IT部在集团板块中价值。
最后，从我自身的实际工作经历，简单介绍4家企业的云平台建设情况：
1、某制造业
该企业主要以生产汽车车桥、零部件、专用车制造为主，公司主要业务系统有：MES制造管理系统、WMS物流仓储系统、CRM客户关系管理系统等，由于偏家族企业的关系，财务系统和人事系统较为独立，有专门的供应商提供支持和服务不对信息部开放，办公方面使用钉钉办公。10台左右的物理机放置在非专业机房（临时仓库、普通用电、家用空调）中，全国5个分基地通过vpn连接使用总部系统，较为卡顿。由于系统稳定性不高（系统运行正常率为99.3%），核心系统问题频发，根据统计测算，MES和WMS宕机一小时各损失资金约50万元和35万元，由于分基地使用系统卡顿，工作效率降低，单位时间内生产效益较总部低10万元。
经分析，首先需要解决企业两大问题，一个是系统稳定性的问题，另一个是各分基地访问系统的网络性能问题。按照云平台架构思路来看，该企业典型的适合私有云或是超融合的架构，或是为了进一步降低成本，可以采用物理服务器虚拟化，构建信息系统和数据库的高可用架构降低系统单点故障。对于机房的问题，可以通过云灾备的方式解决，结合公有云的网络专线资源，构筑企业云网，既解决分基地访问慢的问题，又实现云上云下互为备份，规避机房的灾难性故障问题。
经过改造，年投入约在30万元左右，有效地解决了企业关键棘手问题，并且真实的实用了一次云下机房停电故障，10分钟内拉起云上系统为各基地提供系统服务的实战经历，一次故障经历挽回的损失足矣让几年的建设投入变的非常值得。
2、某电商初创企业
该企业为某大型家电集团的小微企业，主要负责建设集团线上B2B和B2C业务，早期由于2B还是2C业务方向不定，电商平台的开发迭代非常快、新老系统并行也很普遍。创业半年，服务器的需求量已经从一开始的39台快速的扩张至113台，但是系统的用户量、访问量以及并发量并未出现如服务器数量般持续快速增长，网站PV、UV等经过1个月的猛涨期之后，逐渐趋于稳定。早期主要租赁IDC机房和自采购服务器，服务器激增时，走过多次紧急采购、紧急上架，但耗时仍以天为单位，为此系统出现卡顿、响应缓慢的情况持续时间超过2个周，用户体验较差，2C的客户最终几乎流失。一年后，经过试水，公司决定只专注于2B业务，砍掉2C的业务，随之技术架构相应调整。经评估，17台物理机可以较为宽裕的支撑集团企业的2B业务，多余的服务器进行折旧抵现，用于继续支付IDC的租赁费用。受限于IDC区域影响，2B用户在全国部分区域访问缓慢，国外2B用户访问极其缓慢，当时有延迟时长估量。
随着集团与某云厂商战略合作的签订，集团内实施混合云部署的策略，结合该企业的业务熟悉，该企业将系统、数据库等都迁移至公有云上，使用云数据库、云主机、CDN、云安全以及云网络（集团专线交互），经过云改造，承载该企业的2B平台在云平台一年的花销大致在60万左右，较IDC租赁和运维的费用大大降低，同时国内外用户访问速度明显提升。但该企业后来出现过一次因为公有云故障导致业务停顿的一级事故，停机时间3小时左右，业务营业额损失在760万元左右（上云之后，IDC的业务未做备份保留，故云故障之后，只能等待和安抚客户），因为2B业务，对客户影响较大，目前正改造为多云支持的架构，避免鸡蛋都放在一个篮子里的情况。
3、某集团型民航企业
该企业为面向国内、日韩及东南亚的区域性航空公司，作为民航交通类企业，其业务系统大致可以分为几大类：运行业务类系统，主要负责航班运行控制管理、人员资质管理、飞机维修管理、人员排班管理等核心重要系统；市场营销类系统，主要包括官网售票系统、呼叫中心系统、OTA系统、旅客服务系统等围绕售票和旅客产生收益类系统；办公自动化类系统，包括OA、财务系统、人力系统、考试系统等。几大类系统中，运行业务类系统稳定性和安全要求最高，行业惯例多内网部署，符合私有云的使用场景；市场营销类系统面向旅客和互联网公众，且需要支持海外访问，符合公有云的使用场景；同时生产运行和市场营销又联系比较密切，生产运行类系统要是根据旅客和行李的数量计算飞机载重和航油配备，市场营销类系统有依赖航班承载旅客，二者联系较为密切；办公自动化类系统主要承载公司全员的办公，因为分基地以及地服、机务人员分部各个机场，所以对移动办公要求较多。同时该企业拥有几家分子公司、分支结构及集团关联板块企业，各自也有一部分数量的系统和数据。
经过分析，结合集团公司的战略规划和业务情况，决定规划设计集团企业的混合多云平台：私有云承载公司核心运行系统和办公自动化系统，公有云承载市场营销类系统和移动办公系统，鉴于公有云的持续稳定性和国际业务的需求，计划建设2朵公有云与本地1朵私有云互通。私有云的选择以稳定、安全为主，同时适当的考虑信创要求，整合多家兄弟单位和分子公司的数据中心组合多数据中心架构，规避单数据中心的故障。通过多云管理平台CMP&MSP整合各类资源池，并且对集团内兄弟企业和分支架构提供IT租赁服务，大致架构如下：
目前该混合多云架构正在实施建设中，在这个过程中也出现了比较多的问题，一是成本核算的问题，因为前期的投入较大，且与其他单位整合、租赁方面存在标准不统一等问题，投入产出计算较为复杂且准确度低；二是网络架构方面的复杂性，特别是多活数据中心和多云的对接方面，存在比较大的难度，前期对网络架构缺乏重视，后期对接时，问题较多；三是花费了大量的时间理顺的IT运维和运营的流程，落地推进阻力较大；四是最头疼的问题，即负责混合多云实施的组织支持力度较弱，缺乏管理层的大力支持。对于这几个问题目前正在着力完善问题一的数据支持为公司战略支持提供依据，提升该项目和组织的战略地位，赢取集团公司一把手的直接推动和督办，统一公司高管和兄弟单位高管的意识和认识。道路还是比较长，但可以预见的是系统稳定和性能都得到了进一步的提高、IT逐渐有营收进来、人力成本出现了降低等。
六、企业上云流程简析
最后，对企业上云的全流程做一个简单的介绍。企业上云大致包括上云前、上云和上云后三个阶段，其中包含资产梳理、上云评估、架构设计、方案计划、上云实施、云后运营等几个子阶段，每个阶段的主要内容有：
（1）资产梳理
①系统数量
②服务器、虚拟机数量
③计算 存储 网络资源使用量
④系统关系图 数据流图等
（2）上云评估
①评估上云需求点包括评估上云需求和可行性
②确定上云范围
③评估上云成本和效益(3\5\8年)
④评估上云风险和规避策略
（3）架构设计
①选择上云类型
②选择上云厂商
③执行上云架构
④执行上云后已有资源处置
（4）方案计划
①制定上云的方案和计划
②上云方案要求尽量多云
③上云采取保守策略，尽量避免业务中断
④上云计划中实施运行阶段遵循以下：
本地+云-->云+本地
尽量有权重的双中心运行
（5）上云实施
①平滑切换尽量避免业务中断
②有权重的双中心运行：云+本地
③上云后的测试方案要提前准备，实施后按计划测试
④建立云切换方法和尽量实现多云管理平台
（6）云后运营和评价等
①建立和完善上云之后的运营，包括本地和云上系统的分配以及权重、主备切换、备份、监控等
②评价上云成本，同时对上云预算进行预测
③成本对比，包括上云与本地的成本对比以及长期总成本对比
④制定长期战略
⑤风险评估以及应急演练
附件一、某企业云平台技术选型调研报告（简）
声明：附件内容仅供参考，不做任何商业倾向，仅对某企业的某时刻的某业务场景做出的主观判断，不承担任何后果。有所删减，更详细的数据可联系作者获取，同时欢迎充分的讨论和探讨。
经过技术调研、厂家沟通（近10家）以及同行交流等方式对新机场IT基础资源架构方案产品，大致有如下两种分类方式：
（1）基于产品类型分为开源产品和商业产品
① 开源产品：OpenStack+K8S
② 商业产品：
基于开源的商业产品：EasyStack、华为、华三、Zstack等
完全自研的商业产品：VMware、青云等
（2）基于底层架构分基于VMware的底层架构和基于kvm的底层架构
① 基于VMware的底层架构：VMware
② 基于kvm的底层架构：除VMware外
方案选型对比从技术方面、人员方面、综合成本方面和国际业务等多方面进行详细对比，具体如下：
1 技术对比
技术产品 | 商业/开源 | 优势 | 劣势 |
Openstack+k8s | 开源产品 | 1.接口丰富，自定义、个性化的能力强 2.生态完善，功能模块、开源插件配套齐全 3.代码公开，技术开放，技术贡献者众多 | 1.需要大量的“方案组合及验证”，人力物力的投入会大幅增加。 2.稳定性、安全性、平滑升级等方面不友好，并且缺乏技术支持责任主体。 |
VMware | 完全自研的商业产品 | 1.全球范围内，虚拟化与云计算的领导者，其稳定性、安全性业界最佳，有实力雄厚的全球研发和技术支持能力。 2.接口丰富，方案完整，技术先进，易于维护，在全球范围内拥有大量的成功案例与成熟的解决方案。 3.被AWS/阿里云/腾讯云广泛认可，可实现混合云架构。 4.极其完整的生态系统、数千种官方认证软硬件兼容性。 | 1.软件许可费用较高。 2.商业闭源产品，二次开发、自主开发难度较高。 |
EasyStack | 基于开源的商业产品 | 1.基于kvm+OpenStack+K8S的二次开发与封装，具有原生开源平台的大部分优势特性。 2.可提供企业级技术支持。 | 为了不必要的麻烦，已删除。 |
华为 | 基于开源的商业产品 | 1.基于开源平台（OpenStack）的二次开发与封装，具有原生开源平台的大部分优势特性。 2.可提供企业级技术支持。 | 为了不必要的麻烦，已删除。 |
华三 | 基于开源的商业产品 | 1.基于开源平台（OpenStack）的二次开发与封装，具有原生开源平台的大部分优势特性。 2.可提供企业级技术支持。 | 为了不必要的麻烦，已删除。 |
青云 | 完全自研的商业产品 | 1.自研商业云平台，拥有自主知识产权。 2.较多的银行案例和四川航空等民航案例，相对比较强大。 2.可提供企业级技术支持。 | 为了不必要的麻烦，已删除。 |
深信服 | 基于开源的商业产品 | 1.基于开源平台的二次开发与封装，具有原生开源平台的大部分优势特性。 2.可提供企业级技术支持。 3.与自身的安全设备和安全产品兼容较好，在安全方面有一定优势。 | 为了不必要的麻烦，已删除。 |
Zstack | 基于开源的商业产品 | 1.基于CloudStack架构或是有该架构的身影，比较简单，部署也比较方便。 2.与阿里云紧密合作，基于阿里云的混合云优势明显。 | 为了不必要的麻烦，已删除。 |
AWS | 完全自研的商业产品，公有云 | 1.全球范围内，公有云服务的领导者。 2.服务目录丰富、服务种类多样，客户选择余地大。 3.接口丰富，方案完整，技术先进，易于维护，在全球范围内拥有大量的成功案例与成熟的解决方案。 4.拥有华夏航空的典型案例。 | 1.网络连接风险较大，目前国内节点较少。 2.数据存放在云端，或许有潜在风险，以数据库服务为例，DBA在平台方。 3.云服务费用较高。 |
阿里云 | 完全自研的商业产品，公有云 | 1.亚洲范围内，公有云服务的领导者， 2.可提供符合国情的电子商务SAAS服务。 3.对前端互联网应用的极致负载有较强的管理经验。 | 1.数据存放在云端，或许有潜在风险，以数据库服务为例，DBA在平台方。 2.对于复杂的企业级应用尤其是企业私有云方面，架构较为复杂。 |
Gartner排名：
综上对比，以vmware虚拟化作为底层架构的方案或产品在技术方面相对更加稳定，以kvm虚拟化作为底层架构的方案或产品在二次开发和日常运维方面较为稳定，但技术相对较新，版本更迭较快。
2 人员对比
不同产品选型对系统运维人员的数量和质量皆有不同的要求，从开源产品、基于开源的商业产品和完全自研的商业产品进行比较：
产品类型 | 产品举例 | 人员数量 | 人员质量 |
开源产品 | OpenStack+K8S | 最多（约15人） 系统运维 7人（操作系统、网络、数据库、中间件等） 运维开发 5人 平台运营 2人 系统架构 1人 | 对技术要求最高，要求具备基本系统运维知识技能的基础上还需对开发语言、开发流程等熟悉。 |
基于开源的商业产品 | 华为、华三、深信服、Zstack等 | 较多（5-8人） 系统运维 3人 平台运营 2人 系统架构+运维开发 1-2人 | 同上，因为是基于开源的商业产品，对人员的要求较高，同时版本更新迭代较快，需要增加升级、迁移等能力要求。 |
完全自研的商业产品 | VMware、青云等 | 较少（约3人） 其中VMware与当前运维人员完全匹配适当增加3人共同运维整体运维平台 | 对人员的技术要求相比上述略低，对人员的综合技能和云计算整体架构要求较高，人员扩展相对比较容易。 |
* 人员数量和人员质量为基于信息中心系统运维当前人员情况在需要增加的数量和质量。
3 国际业务对比
考虑到公司国际业务的逐渐增多，未来公司业务和系统国际化运行势在必行，就上述调研产品，在国际化业务和系统运行方面对比如下：
（1）阿里云、AWS为大型公有云服务，其中阿里云的优势主要在国内及亚洲地区，AWS为国际上排名第一的公有云供应商。华为、青云等也有公有云的业务，但是主要集中在国内，且规模较少。
公有云方面，阿里云在国内具有显著优势，AWS在国际具有显著优势。
（2）深信服、Zstack、EasyStack等厂商主要业务范围在国内，故与阿里云结合较密切，尤其是Zstack；VMware为全球云计算厂商，与AWS、阿里云、Azure等都有深度合作。
综上，在国际业务方面VMware+AWS应为最佳实践组合。其中经过与华X航空、南X等同行交流，目前航司在国际化业务方面正逐渐迁移至AWS，实现业务和系统的国际化运行。
4 综合成本对比
成本计算以5年时间计，详细对比内容如下：
*（根据部分地域供应商提供的报价进行估算所得，仅供参考）
序号 | 技术方案 | 软件费用 | 硬件费用 | 人力费用 | 运维费用 | 总计 |
1 | OpenStack+K8S | 0 | 180万 | 1350万 | 1530万 | |
2 | VMware | 为了不必要的麻烦，已删除。 | ||||
3 | 青云 | |||||
4 | 深信服 | |||||
5 | 华三 | |||||
6 | Zstack | |||||
华三报价目前正在沟通中，待华三提供后补充完善；Zstack报价比较粗略，已经沟通完善中，待厂家进一步提供后补充完善；因为根据会议讨论，该部分不影响整体调研结果，故后续补充完善。
* 方案1中OpenStack+K8S为开源技术架构，软件免费，基本不需要商业授权，硬件资源根据实际需求，大致费用在180万；人力费用以15人计，按照人均10000每月（技术要求高）收入计算，5年公司的人力成本大致在：15*10000*1.5*12*5=13500000，其中因为自己运维，故运维费用与人力成本合在一起计算。
* 方案2中因为目前运维人员可以满足VMware的人员需求，故不需要增加额外的人力费用，但是考虑到未来的发展，暂以3人计算，VMware人力成本略低，按照人均8000每月（技术要求一般）计算5年公司的人力成本大致在：3*8000*1.5*12*5=2160000。运维费用在免费服务期结束之后，大致按照每年30万计，约需要60万。
* 方案3中为了不必要的麻烦，已删除。
* 方案4中为了不必要的麻烦，已删除。
* 方案6中Zstack方案，软件较为便宜，为了不必要的麻烦，已删除。
* 由于华为云计算对微软产品的支持减弱的原因，故未详细咨询华为报价；AWS、阿里云为公有云，本期建设以私有云为主，兼顾未来公有云扩展，故未咨询详细报价；EasyStack为了不必要的麻烦，已删除。
综上综合成本对比方面，以5年时间计算，开源成本为最高，主要集中在人力资源成本上较高；其他商业产品价格相对均衡，为了不必要的麻烦，已删除。
另外就人员招聘和人员储备资源方面，VMware人员基数大，招聘相对容易；华为、华三为国内一线大厂，人员基数尚可，招聘难度一般；青云、深信服、Zstack、EasyStack等多为国内新兴公司，人员基数少，招聘专业人员难度较大，更多需要依赖原厂技术，费用相对较高，同时新兴公司内部人员稳定性也不如VMware、华为、华三等大厂稳定。
从更加长远的规划发展来讲，随着公司规模的逐渐增大，特别是在150架飞机规模及以上时，基本任何一家商业产品解决方案的IT投入成本会变得较为庞大，此时依靠自身力量基于开源技术的解决方案在性价比方面会变得更优。这要求我们在接下来的技术发展思路上基本遵循以下原则：前期（5年以内）以商业产品解决方案为主，同时实践和尝试开源解决方案并将开发测试环境和部分生产环境运行在开源方案环境中；中期（5-8年）以商业产品解决方案和开源解决方案并行运行，具备运维和开发能力，并且将部分核心系统运行至开源解决方案环境中；后期（8年以后）随着公司规模，逐渐加大研发和运维能力，基于开源解决方案建立自己的产品代替商业产品，如航信的航信云、海航的海航云等。
以上只是从软件、硬件、人力和运维方面四个方面考虑，其中品牌绑定、品牌兼容性以及品牌附加价值等暂未计算入内。例如华为和华三的虚拟化产品与其自身的服务器和网络交换机绑定较深、深信服与其自身的安全设备绑定较深等。以上各家，目前只有VMware提供品牌兼容性列表，其他厂家（除华为、华三）均宣称兼容所有主流硬件产品，但有待进一步考证，如经过深入调研，某厂家实质性内部是有自己的兼容列表的。
选型建议：
综上技术对比，云计算平台大致可以分为两类：基于OpenStack+K8S的云计算平台（EasyStack、华为、华三等）和完全自研的云计算平台（VMware、青云等）。就底层技术而言，也可以分为两类：基于KVM虚拟化的云计算平台（除VMware外）和基于VMware的虚拟化平台（VMware），其中就稳定性和市场份额来说，VMware虚拟化可能更胜一筹。
