为什么是云计算，为什么是现在

• 商用云：商用云的设计初衷是将基础设施商品化，并以较低的成本对外提供，是用户能够获得高扩展性和自服务能力。
• 企业云：企业级云的目的，则是达到或超过它所要替代的本地基础设施的安全和服务等级协议（SLA）

企业云的价格和复杂性要高得多，但商用云通常不能满足企业所要求的安全标准和SLA需求。

云服务模式

云计算的5个特征是网络接入、弹性、资源池化、可计量的服务以及按需自服务

IaaS

NIST定义 消费者能够获得处理能力、存储、网络和其他基础计算资源、从而可以在其上部署和运行包括操作系统和应用在内的任意软件。消费者不对云基础设施进行管理或控制，但可以控制操作系统、存储、所部署的应用，或者对网络组件（如防火墙）的选择有部分控制权。

CSA定义 以服务的方式交付连同原始存储和网络在内的计算机基础设施（通常是一个平台虚拟化环境）。客户并非购买服务器、软件、数据中心空间或者网络设备，而是将这些资源作为外包服务整体采购。

PaaS

NIST定义 消费者能够使用提供商所支持的编程语言、库、服务和工具，将自己创建或获取的应用部署到云基础设施上。消费者不会对底层云基础设施进行管理或控制，这包括网络、服务器、操作系统或存储等，但是可控制所部署的应用，并有可能控制配置应用的托管环境。

CSA定义 以服务的方式交付计算平台和解决方案包。PaaS服务消除了购买、管理底层硬件和软件以及部署这些主机所带来的成本与复杂度，使应用的部署变得更容易。

一般情况下，大企业会选择混合云服务，把数据保存在私有云里，然后把不重要的组件迁移至公有云中。

在三种云模式下，PaaS是最不成熟的模式

SaaS

消费者能够使用提供商运行在云基础设施上的应用，并可通过类似Web浏览器（如基于web的电子邮件）等瘦客户端界面，在各种客户端设备商访问这些应用。除了一些有限的特定于用户的应用配置的设置之外，消费者不会直接对底层云基础设施进行管理或控制，这包括网络、服务器、操作系统、存储，甚至单个应用的功能。

部署模式

公有云

NIST定义 云基础设施提供给大众公开使用。拥有、管理或运营这些设施的可能是商业、学术或政府机构，抑或其组合。另外，这些基础设施都存放在云提供商处。

所谓公有云指的是这样的一种多租户环境，即最终用户与其他消费者一起，在一个共享的商业资源网络上为自己所使用的资源付费。最终用户可以选择数据中心所在的位置，但不知道自己的软件具体运行在哪台物理机上。物理硬件之上是一个抽象层，以API的形式展现给最终用户，由用户用来创建运行在多人共享的大型资源池里的虚拟计算资源。

公有云的优点

• 公用事业价格
• 弹性
• 核心竞争力

公有云的缺点

• 控制
• 监管问题
• 有限的配置

私有云

云基础设施提供给由多个消费者（如业务单元）构成的组织专用。拥有、管理或运营这些设施的可能是该组织、第三方，抑或其组合。这些基础设施的存放点可以在本地，也可以不在本地

私有云的优点

解决了公有云的一些缺点（控制、监管问题和配置能力）。私有云可以部署在本地或者托管在云服务提供商的数据中心里。无论那种情况，私有云的最终用户都只是在一个单一租户环境下进行部署，不会与其他用户混用。

私有云的缺点

牺牲了“快速伸缩性、资源池化以及按需使用的定价模式”

混合云

单独存在但却通过标准的或专利性的技术绑定在一起，以使数据和应用具有可移植性的两种或多种不同的云基础设施（私有云、社区云或公有云）的组合

混合云的最佳实践方式是在利用快速伸缩性和资源池这些云计算的优势方面尽可能多的使用公有云，而在数据所有权和隐私这些公有云中风险较高的领域使用私有云。

云计算的错误实践

将应用迁至云

首先确定架构师真正理解了无状态和有状态设计模式之间的差异；其次，弄清楚应用程序是否适合迁移至云端，抑或托管、重新编写等才是更好的选择。

不切实际的期望

设定合理的预期。将云计算方案分解成多个更小一些的可交付项，这样可以尽快交付商业价值，使团队在前进的途中不断成长；不要让团队脱离市场埋头几个月或一整年只为了一下交付一大堆新型的云服务，不要尝试这种“爆炸式”的成长方式。了解各种云服务模式的缺点。对云服务的消费进行优化，监控和审计，实施管制流程来坚持正确的消费模式。认真查看每个月云服务提供商寄来的账单，确保成本控制在期望范围之内。

云安全的错误认知

一开始就要确认架构师、产品团队和安全专家对于云安全、法规控制和审计要求有足够多的认识，如果有必要，可邀请独立的第三方来进行评估，并对部署之前和部署之后进行审计对比。最好未雨绸缪，尽量避免亡羊补牢。

只选最喜欢的，不选最合适的

理解SaaS、PaaS、IaaS三种云服务模式之间的差异。清楚每种服务模式最适合什么业务场景。不要只是因为开发者使用了某种软件包或者公司多年来向固定的提供商购买了硬件而选择云提供商，应该综合考虑。

服务中断及停业场景

选择云服务模式和云服务提供商时，先理清楚可能有的故障点和带来的风险，并对此进行应对设计。了解云提供商的SLA和数据所有权政策，仔细检查所有具有法律约束力的文档和协议。每种云服务都会带来某种程度上的供应商锁定。研究锁定的成因和影响，确定服务等级。云计算不是一个非此即彼的命题，不必非得全部迁入，也不必完全摒弃。细心选择，更细心的进行架构设计。

低估组织变革带来的影响

如果可能，在实施云计算项目时，先从较小的、低风险的方案做起。如果项目风险和类型都比较大，千万不要低估组织变革带来的影响。营造出紧迫感，组建并赋权一个团队来掌控项目，创建未来状况的愿景，并通过使用各种可能的沟通机制（全体大会、博客、简报、会议、海报等）一遍一遍的在整个组织内进行观点的传播。

技术不足

基于项目需求对现有的员工能力进行评估，确认技术缺口。然后，通过全职招聘或劳务外包的方式获得有经验的人才来填补这个缺口。确保在这个过程中，现有的员工能从这些经验人士处学习提高。切记，如果仅有外部的经验人士参与到这些方案中，那么公司的内部的人难免会有抱怨情绪，此外，留意参加实践者做讲解的聚会和大型会议（但是要提防供应商的推销行为），多与那些有成功经验的本地组织进行接触。鼓励团队成员参加培训、阅读博客，以及通过网络进行协作，分享学习其他人的经验。

对客户需求的错误认识

在选择云服务模式和云类型之前，理解业务需求和客户对于云计算的期望。是需求驱动决策，而非决策驱动需求。明确产品定义和需求，对业务需求的安全和监管问题进行评估，把不足添加到整个产品的待办事项中。记下经常会被问到的问题，随时查阅，能够解答典型客户对于基于云的方案经常会有的疑惑或顾虑。

出乎意料的成本

了解每种云服务模式的成本，建立适当的公司治理和软件控制层级，对成本进行优化和监控。对于有着遗留方案的公司来说，不要低估与遗留架构集成可能要花费的工作，以及培训现有员工或聘请有经验的工程师所需的成本投入。