04 | 变化的云？

如同天上的白云一样,云计算也是变化的!

引用一句古希腊哲学家赫拉克利特的名言：

唯一不变的就是变化本身。 不过,就像吃大餐前先点份前菜，才更有利于大快朵颐!

1 | 云计算带来的三大变革

首先我们回顾一下:传统的数据中心中运行的是大量的、专用的、垂直的一些堆栈式应用，完成各式响应性操作。当其向云转变的过程中，主要会有哪些大类的变化呢？

（1）基础设施
（2）运营模式
（3）应用
图:云带来的三大变革

第一变化:基础设施

如果大家对当年的电信运营商是如何被新兴的IT企业所冲击的还记忆犹新的话，那么一定记得电信运营商大量使用的专用点对点、回路交换等技术是被包交换、IP等技术所颠覆。这些技术逐渐渗入到了基础设施中的各类设备上，提供更高的性能、效率、安全和可用性。同样，在今天的云化的过程中，构建云基础设施也有类似的特点：大量的虚拟化技术的采用，通用硬件平台、开源技术的采用等。

第二变化:运营模式

在云的时代，任何东西都会以一种服务的方式来交付，IT也不例外。ITaaS于是应运而生。ITaaS是个抽象的概念，直观一些的说法是它具体体现在整个服务流程的自动化，以及对不同优先级的任务的区分对待等，最终的目的是实现最优资源调度、配比……

第三变化:应用

在第三平台中我们前所未有地注重用户体验，一切为了应用已经变成了一句箴言，从基础设施到运营模式都是为了更好地创造应用、优化应用，并围绕应用而提供一套完整的数据采集、处理、分析、汇总、反馈的系统（十年前我们叫BI—商务智能，今天我们叫大数据），然后通过集成到客户端的应用展现给终端用户。

我们再换一个维度来看上文的“三大变革”，看下图:

换一个维度来看云带来的三大变革
用一句话来总结基础设施与应用的变革，那就是：

变革中不会也不可能摒弃传统的架构与应用，在引进新的云架构、新应用的时候也需要兼顾传统的需求。

2 | 运营模式变革中的5+1+1

运营模式的变革是为了更好地服务基础设施与应用的变革，其主要的变化可以用如下的5+1+1来表达。

（1）引擎+目录+门户

我们来分别了解一下。首先是5代表什么。用户需要一个门户作为入口来访问云计算所提供的服务，在门户当中最重要的就是提供：

① 自服务目录，这个很容易理解，就好像逛超级市场或上网购物一样，你会需要一个目录来帮助你快速检索； ②
各种引擎来帮助实现具体的服务与任务的管理与执行，具体而言就是策略、编排与计量三大引擎。策略可以是访问策略、安全策略、网络策略，多种多样；编排（M&O）是一个很大的概念，我们把自动化部署，资源管理、监控、储备等都划入编排的范畴；计量对于按需收费的云计算而言是保证实施以及完成监控的基础组件。

（2）敏捷流程
前一段话介绍了5，这里再介绍一下敏捷流程，在软件工程中有很多方法学与流派，其中两类的实践者最多，一类叫作顺序开发（Sequential Development），另一类叫作迭代开发（Iterative Development）。顺序开发最典型的例子是瀑布流开发（Waterfall）。

它的最大特点就是每两个环节之间紧密相连，设计之初就要有清晰的需求，实现之前就要有完整的设计，以此类推。

对于传统的软件开发而言，这样的流程设计非常清晰，易于执行。而在一个需求高速变化，甚至设计也在高速变化，实现、验证与维护只有极短的时间与资源来完成的时代，瀑布流就显得不合时宜，取而代之的是称之为敏捷开发的流程。

敏捷开发有如下几个特点:

轻监管（比起瀑布流开发需要更少项目监管）
重互信（听起来像是社会主义高级阶段）
喜变更（即便在开发的晚期阶段）
强交流（强化商务与开发交流频率）
快迭代（高频迭代，从年→月→周→天……）
评估项目进展的金标准是可运转的软件

从以上几点不难看出，敏捷开发流程属于典型的轻流程、重结果，以高速迭代为导向—快速失败重新开始，它与瀑布流最大的区别是各环节形成了一个循环迭代的环。

值得一提的是，在从瀑布流向敏捷开发转变的过程中，大多数企业采用了一种折中的开发流程：瀑布式敏捷开发（Waterscrumfall），造成这一折中的核心原因是敏捷开发中依赖的迭代式增量开发（Scrum）模式不能被单一功能团队所完成，于是只能在部分环节依然保持瀑布流的方式。出于篇幅所限，有兴趣深究的读者可以查阅相关的专业书籍。

（3）新IT角色

最后我们再来看一下变革中对人的影响—新的IT角色的出现，传统意义上的系统管理员、存储管理员、网络管理员、安全管理员等将逐渐退出历史舞台，取而代之的是云管理员、云架构师、自动化工程师、DevOps（Dev+Ops，Developer+Operations，即开发+运维合二为一的角色）等新的职位角色。

图：新IT角色出现

前面，我们讲解了云所带来的一系列变革，那么现在，我们来关注：

当选定了一种云形态之后，是否就一成不变了呢???

3 | 云迁移

越来越多的初创型公司在早期阶段可能会因为初始化投入成本较低而选择公有云服务，最常见的是从云主机入手，逐渐延伸到云存储、云数据库、云加速器等服务，但是随着业务的发展，到达某一个阶段的时候，就会出现以其他云形态来补充或者是从一个云服务提供商迁移到另外一家提供商的需求。

图：不同形态云之间的转换

云迁移的诱发因素多种多样，可归纳为如下几种:

性价比：客户永远在追寻更高的性价比
功能导向：A云不能完成的功能如B云可以就会迁移到B
策略导向：如compliance（合规）要求变化在原有云无法达到

云迁移的方向可以是在任何两朵云之间双向或单向的迁移。迁移从应用到数据、到基础架构，都可能被涵盖。

有的迁移像搬家一样是一次性的（One-off），有的迁移是具有随机性和重复性的。

最典型的例子有云爆发（Cloud-Bursting，指当在私有云中运行的应用在访问爆炸式增长后会临时使用公有云服务来保证服务不间断）以及混合云等。
图：混合云架构中负载的分配与迁移

混合云架构中负载的分配与迁移,描绘的是一幅典型的混合云架构场景，我们用一张表来说明公有云和私有云在一个混合云框架下各自的侧重点如何。

图：混合云架构中公有云vs.私有云

此外，在这里再给大家介绍一些逐渐形成潮流的云迁移和云间数据交换的场景：

场景一：云间数据交换
互联网公司在业务发展初期大量使用公有云服务早已形成了一种定式，但是，随着业务的发展，特别是需要处理的数据量的爆发式增长，有一些例如大数据分析的业务由于公有云服务商品化硬件的限制（如单机的CPU和内存限制），不得不考虑自建数据中心（私有云）来完成，那么就涉及在公有云与私有云间的数据传输成本与效率问题，通常最高效的方式是在两朵云之间拉设光纤专线（中美之间的网络成本存在很大的差异，美国的网络宽带成本远低于中国，所以还要评估拉专线方式是否适合具体的业务需求），当然如果两朵云所处的数据中心在物理网络上距离越近效果越好。

比如一家地处硅谷Mountain View的公司，它在AWS的EC2主机位于马路对面的数据中心，而其自建的Cassandra集群就在其隔壁的ISP数据中心里面，那么建立一条连接彼此的10Gbit/s的专线，则专线传输几乎是在高速局域网里进行数据传输的节奏。当然，前面的这个例子是比较理想的场景，只需要关心数据如何在两个数据中心之间进行交换，这个问题可以进一步降解为四步：

（1）源数据传输准备（Staging）：提取、去重、压缩、加密等
（2）数据分发与传输（Transform）
（3）接收源数据（Receive）：解密、解压、重建
（4）数据重构（Apply）

云迁移场景一、二 (该图示的是一个典型的从源数据中心向目标数据中心通过分布式、P2P公共网络来传输数据的架构，该架构意图达到高效、可靠、分布式数据传输的效果，它同样适用于基础架构迁移的场景。)

场景二：跨云的基础架构迁移
基础架构的迁移是指要把IaaS以及之上所有的平台、服务、应用及数据完全迁移。这其中最大的挑战是对业务可持续性的要求。如果对在线业务的下线时间（Downtime）是零容忍，那么这就是一个经典的第三平台无缝衔接大数据迁移场景。

我们来简单描述一下如何实现无缝、无损数据迁移（为简化设计起见，假设源与目标数据中心具有相同、类似的硬件配置）。

对源数据中心进行元数据提取（Metadata） 在目标数据中心重构基础架构（IaaS Replication）
非实时数据的大规模迁移（Non-real-time Data Transferring）
在目标数据中心启动服务、应用进入备用状态（Standby） 以迭代、递增的方式在源、目标数据中心进行实时数据同步。
目标数据中心调整为主服务集群（Cut-Off/Switch-Over） 持续数据同步、状态监控（Continuous Monitoring）
源数据中心下线或作为备用基础架构（Offline/Online）

至此，我们应该已经对云的各种形态都有所了解了——它们不是一成不变的!

·END·