近期云计算技术的发展与热点技术

从IaaS到PaaS

我这里不是说PaaS要取代IaaS，而是说，IaaS和PaaS两点之间已经连成一条渐变的线了，两者不再是泾渭分明的了，中间遍布了很多介于两者之间的服务，这之间的很多创新点都在过去一段时间里逐步成熟了。

IaaS与PaaS的差距在哪里，其中一个视角是他们所面向用户的不同——

• PaaS 所面向的用户是开发人员，他们设计架构、写代码、有时候做集成测试和 Code Review，然后就发布代码，让用户使用了，也就是说，PaaS把代码变成产品（网站、服务或是什么其他的东西）
• IaaS 所面向的用户则是运维人员，他们根据架构师或开发人员的要求构建基础设施，部署和配置软件系统和各种基础服务，部署和升级开发人员完成的代码，监控并处理故障，根据负载调整系统规模等

当然，各位可能已经看到，这里IaaS上运维人员的很多职责实际已经有服务在帮助完成了，比如预先部署好的数据库服务、消息队列服务、负载均衡服务、MapReduce服务等，监控系统运行的各种监控服务以及一些自动扩展和自动故障恢复服务等。

现在已经没有单纯占据资源层的“纯IaaS”服务了，构建在IaaS服务基础上的各种附加服务正在解放云上的运维人员，云服务的用户可以根据自己的能力、财力和具体需求，挑选一些服务，结合自己的工作量身打造适于自己的系统。

这样，云服务的层次就变得更丰富一些了

----------------------------
           PaaS
----------------------------
预部署服务 | 监控管理  |
-------------------  >IaaS+
       资源服务      |
----------------------------

并且，资源服务也不再只是传统的主机+对象存储+块存储+IP地址了，再过去一段时间，云服务的引领者亚马逊AWS一直在积极推进VPC（虚拟私有云），帮助用户可以通过子网结构化地组织系统，通过网关、路由、虚拟设备和各种其他规则，更安全、更有效地使用云上资源。这些日益丰富的资源让人们可以更方便地使用云服务，降低了云上运维的很多困难，不过也让很多选择和配置变得更加复杂了。

Orchestration

前面我提到，PaaS 帮助用户“把Code变成产品”，又说，IaaS用户相比之下还要做部署、升级、监控、事件处理这些事情，于是，一个自然地想法是，如果“部署...事件处理”这些事情可以变成Code，那么，用户所使用的到底是PaaS 还是 IaaS 呢？

Infrastructure as Code 是 DevOps 粉丝们特别喜欢的一个概念，代码化的描述，让整个系统的部署更加严谨可控，并且可以通过版本管理来追踪发现问题、调整部署。

在云上，由于亚马逊等主流云服务商丰富的API支持，甚至是监控、系统级的事件处理（比如硬件故障导致宕机）这些传统的运维工作也可以通过代码进行自动化的处理，这就演化出了近两年走红的 Orchestration 的概念.

----------------------------
           PaaS
----------------------------
      Orchestration
----------------------------
预部署服务 | 监控管理 |
-------------------  
          资源服务      
----------------------------

这实际是通过一些代码，把 IaaS 用得像 PaaS 服务一样。当然，这些代码不是非常容易写的，于是就有了很多帮助用户在 IaaS 的灵活和 PaaS 的易用之间进行折衷，我所在的 MadeiraCloud 也是在这一领域进行工作，通过图形化的交互界面，把复杂的集群部署和管理工作变得直观而高效。

当然，Orchestration 是帮用户简化不必要的劳动，通过各种附加资源和引导方法协助用户快速地进行系统设计和部署，避免因为繁琐而造成的出错，用户仍然需要相应的知识，理解他所做的选择，才能藉此灵活高效地使用云服务资源，Orchestration 并非要直接取代 PaaS。

Container & Docker

从去年云计算大会之后，Docker 所代表的 Container 技术快速走红，以至于不论是否明白 Docker 意味着什么的人，都在茶余饭后大谈 Docker 和 CoreOS 云云。

Container 技术实际历史非常悠久，而且不同的 Container 之间也有不少差别，作为 PaaS 服务商 dotCloud 开源的技术，Docker 所带来的影响，实际上更提现在运维方面，而不仅仅是在计算虚拟化的层面。

传统的云上部署，运维人员面临两个抉择：部署快、可重用、很少出错的自定义 Image；灵活、可以经常升级、调整的 DevOps 工具。两者各自的优点就是对方的缺点，如今，docker 的 OS Image 分层装配机制会让系统的部署工作产生这样的变化

|     /\         DevOps Tools   |        /\      <-- DevOps Tool
|    /  \    <-- e.g. chef,     |       /--\
|   /    \       puppet, salt   |==>   /    \    <-- Docker Layers
|  /------\                     |     /------\
| /        \ <-- OS Image       |    /        \  <-- Base OS Image
|/__________\                   |   /__________\

这是因为 docker 具有如下优点：

• 分层装配，比 OS Image 更灵活
• 每层更完备，recipe 会比传统 DevOps 工具短得多，更简单，更少犯错
• 可以和集成测试结合起来
• 增量分发，且装配速度比 DevOps 工具逐条执行快
• 甚至可以撤回出错的变更，这一点 DevOps 工具的传统工作方式很难做到

此外，分层的文件系统让不同的 container 之间可以共享更多的文件，这样，从硬盘空间到内存缓存都可以极大的降低每个 container 的开销，使得“一个应用一个Container”的目标更容易实现。

小结

以上是我作为一个在云计算领域淫浸了几年，对运维领域有偏爱的开发者，对于云计算的近期发展趋势的观察，仅供参考，不周或不对的地方还请谅解，不对判断和预测承担任何责任。