1.2.3 云的形态并非一成不变
前面我们介绍了不同形态的云的特点，并列出了一些规则来帮助人们决策到底要选择哪种云以适应各自的业务需求。在拥抱云的过程中，从人的思维方式到团队的合作方式，再到与客户的接洽方式，甚至是整个社会的运作方式都在逐步发生巨大的变化。这一小节我们就来谈一谈变化中的云。
1. 云计算带来的三大变革
我们先回顾一下，传统的数据中心中运行的是大量的、专用的、垂直的一些堆栈式应用，完成各种响应性操作。在其向云转变的过程中，云计算带来了三大变化，如图1-13所示。
图1-13 云计算带来的三大变化
（1）基础设施
第一个变化是基础设施。当年电信运营商受到新兴IT企业冲击的背后，是其大量使用的专用点对点、回路交换等技术被包交换、IP等技术颠覆了。这些技术逐渐渗入基础设施中的各类设备上，提供了更高的性能、效率、安全和可用性。同样地，在今天云化的过程中，构建云基础设施也有类似的特点：采用了大量的虚拟化技术，选择了通用硬件平台，采取了开源技术的应用，等等。
（2）运营模式
第二个变化是运营模式。在云的时代，任何事物都可以以一种服务的方式来交付，其中包括IT。ITaaS（IT as a Service）于是应运而生。ITaaS是个抽象的概念，直观说法就是它具体体现在整个服务流程的自动化，以及对不同优先级任务的区分对待等，最终的目标是实现资源的最优调度和配比。
（3）应用
第三个变化就是应用。在第三平台中我们前所未有地注重用户体验，“一切为了应用”已经变成了一句箴言，从基础设施到运营模式都是为了更好地创造应用、优化应用，并围绕应用提供一套完整的数据采集、处理、分析、汇总、反馈的系统（十几年前我们叫商务智能，今天我们叫大数据），然后通过集成到客户端的应用展现给终端用户。
我们换一个维度来看上面提到的三大变化，即云的三大变革，如图1-14所示。
图1-14 云的三大变革
用一句话来总结基础设施变革与应用变革，那就是：变革中不会也不可能摒弃传统的架构与应用，在引进新的云架构、新应用的时候也需要兼顾传统的需求。
2. 运营模式变革中的“5+1+1”
运营模式的变革是为了更好地服务基础设施与应用，其主要的变化可以用 “5+1+1”来表达，其中，“5”表示计量引擎、编排引擎、策略引擎、服务目录、用户门户，两个“1”分别表示敏捷流程和新IT角色。
（1）引擎+目录+门户
我们来分别了解一下“5”代表什么。用户需要一个门户作为入口，访问云计算所提供的服务。在门户当中最重要的就是提供以下服务。
① 服务目录。这个很容易理解，就好像逛超级市场或上网购物一样，你会需要一个目录来帮助你快速检索。
② 各种引擎帮助实现具体服务与任务的管理与执行，具体而言就是策略、编排与计量三大引擎。策略可以是多种多样的，如访问策略、安全策略、网络策略；编排是一个很大的概念，我们把自动化部署，以及资源管理、监控、储备等都划入编排的范畴；计量对于按需收费的云计算而言，是保证实施及完成监控的基础组件。
（2）敏捷流程
软件工程中有很多方法学与流派，其中两类的实践者最多，一类叫作顺序开发，另一类叫作迭代开发。顺序开发最典型的例子是瀑布流开发模式（见图1-15），其最大特点就是每两个环节之间紧密相连，设计之初就要有清晰的需求，实现之前就要有完整的设计，以此类推。对于传统的软件开发而言，这样的流程设计非常清晰，易于执行。而在一个需求高速变化，甚至设计也在高速变化，实现、验证与维护只有极短的时间与极少的资源来完成的时代，瀑布流开发模式就显得不合时宜，取而代之的是被称为敏捷开发的流程，如图1-16所示。敏捷开发有如下几个特点。
图1-15 瀑布流开发模式
图1-16 敏捷开发流程
① 轻监管（比瀑布流开发模式需要更少的项目监管）。
② 重互信（重视高度信任的管理与协作）。
③ 喜变更（即便在开发的晚期阶段也可能需要变更）。
④ 强交流（强调商务人员与开发人员交流的频繁程度）。
⑤ 快迭代（高频迭代，迭代周期从年缩短到月，缩短到周，缩短到天……）。
⑥ 评估项目进展的标准是可运转的软件。
从以上特点不难看出，敏捷开发流程属于典型的轻流程、重结果，具有以高速迭代为导向，保障失败后可以迅速重来的应变能力。它与瀑布流开发模式最大的区别是各环节形成了一个循环迭代的环。
值得一提的是，在从瀑布流开发模式向敏捷开发流程转变的过程中，大多数企业采用了一种折中的开发流程：瀑布式敏捷开发（Waterscrumfall），如图1-17所示。采用这种折中开发流程的核心原因是敏捷开发中依赖的迭代式增量开发模式不能被单一功能团队所完成，于是只能在部分环节依然保持瀑布流的方式。由于篇幅所限，本书无法对此展开讨论，有兴趣深究的读者可以查阅相关的专业图书。
图1-17 瀑布式敏捷开发
（3）新IT角色
我们再来看一下变革对人的影响——IT角色的变化。传统意义上的系统管理员、存储管理员、网络管理员、安全管理员等IT角色将逐渐退出历史舞台，取而代之的是云管理员、云架构师、自动化工程师、开发+运维合二为一的角色DevOps（Developer-Operations）等新IT角色，如图1-18所示。
图1-18 新IT角色
我们在前面讲解了云带来的一系列变革，那么现在来关注当选定了一种云形态之后是否就一成不变了呢？
3. 云迁移
越来越多的初创型公司在早期阶段可能会因初始化投入成本较低而选择公有云服务，常见的是从云主机入手，逐渐扩展到云存储、云数据库、云加速器等服务。但是，随着业务的发展，到达某一个阶段的时候，就会出现以其他云形态来补充或者是从一个云服务提供商迁移到另一个云服务提供商的需求。不同形态云之间的转换如图1-19所示。
图1-19 不同形态云之间的转换
云迁移的诱发因素多种多样，可归纳为如下几种。
（1）性价比：客户永远在追寻更高的性价比，仅此而已。
（2）功能导向：对于A云不能实现的功能，若B云可以实现，则该功能会被迁移到B云。
（3）策略导向：例如合规要求的变化在原有云无法实现。
在任何两种云之间，云迁移的方向可以是双向的或单向的。从应用到数据到基础架构，都可能被迁移。有的迁移像搬家一样是一次性的，有的迁移是具有随机性和重复性的。较为典型的例子有云爆发[2]及混合云。
图1-20中描绘的是一个典型的混合云架构，我们用表1-3来说明公有云和私有云在一个混合云架构上各自的侧重点。
图1-20 混合云架构
表1-3 混合云架构上公有云和私有云的侧重点
注：*DAS，Direct Attached Storage。
接下来我们给大家介绍一些逐渐形成潮流的云间数据交换和跨云的基础架构迁移的场景。
场景1：云间数据交换。互联网公司在业务发展初期大量使用公有云服务早已成为一种定式，但是随着业务的发展，特别是需要处理的数据量呈爆发式增长时，有一些如大数据分析的业务由于公有云服务商品化硬件的限制（如单机的CPU和内存限制），不得不考虑自建数据中心（私有云）来完成，那么就涉及公有云与私有云之间数据的传输成本与效率问题，通常最高效的方式是在两种云之间拉设光纤专线。当然，两种云所处的数据中心在物理网络上距离越近，数据交换的效果越好。比如一家位于硅谷Mountain View的公司，它在AWS的EC2主机位于马路对面的数据中心，而自建的Cassandra集群就在其隔壁的互联网服务提供商数据中心里面，若建立一条连接彼此的10 Gbit/s的专线，则专线传输相当于在高速局域网里进行数据传输。当然，前面的这个例子是比较理想的场景，我们只需要关心数据如何在两个数据中心之间进行交换。这个问题可以进一步分解为4步。
（1）源数据传输准备：提取、去重、压缩、加密等。
（2）数据分发与传输。
（3）接收源数据：解密、解压、重建。
（4）数据重构。
图1-21展示的是一个典型的从源数据中心向目标数据中心通过分布式数据分发、P2P公共网络传输数据的架构。该架构意图达到高效、可靠、分布式数据传输的效果，同样适用于基础架构迁移的场景。
图1-21 从源数据中心向目标数据中心传输数据的架构
场景2：跨云的基础架构迁移。基础架构的迁移是指要把IaaS及之上所有的平台、服务、应用及数据完全迁移，这其中最大的挑战是对业务可持续性的要求。如果对在线业务的下线时间是零容忍，那么这就是一个经典的第三平台无缝衔接大数据迁移场景。参考图1-21，我们来简单描述一下如何实现无缝、无损数据迁移（为简化设计起见，假设源与目标数据中心具有相同或类似的硬件配置），具体如下。
（1）对源数据中心进行元数据提取。
（2）在目标数据中心重构基础架构。
（3）非实时数据的大规模迁移。
（4）在目标数据中心启动服务、应用进入备用状态。
（5）以迭代、递增的方式在源和目标数据中心进行实时数据同步。
（6）目标数据中心调整为主服务集群。
（7）持续数据同步、状态监控。
（8）源数据中心下线或作为备用基础架构。
至此，我们应该对云的各种形态都有所了解，它们不是一成不变的，套用一句古希腊哲学家赫拉克利特的名言：唯一不变的就是变化本身。
[1]ERP：Enterprise Resource Planning，企业资源计划。
[2]云爆发是指私有云中运行的应用在访问量呈爆炸式增长后，会临时使用公有云服务来保证服务不间断。