Web应用该在哪种云服务上运行？

当开发了一个web应用，或者准备搭建一个网站，肯定要面对的一个问题是选择一个服务器。

这里先不讨论上个“时代”的玩法：虚拟主机、VPS。

今天我们考虑的是所谓的“云计算”，主流的方式有：

• IaaS (Infrastructure-as-a-Service) 基础设施即服务。 模式是将虚拟机或者其他资源作为服务提供给用户。代表有Amazon的EC2、DigitalOcean、Linode等。国内提及的云主机，比如阿里云的ECS、腾讯云主机等，主要也是这种模式。
• PaaS (Platform-as-a-Service) 平台即服务。 模式是将一个开发平台作为服务提供给用户。代表有Google App Engine、Heroku、以及国内的新浪SAE、百度BAE等。最近
• SaaS (Software-as-a-Service) 软件即服务。 将应用作为服务提供给客户。代表有 Salesforce Sales Cloud、Google Apps、Zoho等。至于各种在线建站系统算不算呢?我觉得也算。

在这里其实对于成都电脑维修开发者或者是大多数站长来讲，我们关注的其实只是IaaS和PaaS，SaaS主要面向终端用户。当我们拥有自己的应用代码和独立的网站时，能作为我们提供程序运行载体的服务主要也在IaaS和PaaS。所以我们暂且不讨论SaaS。

那么我们说说IaaS和PaaS对于普通开发者和站长来讲有什么切身的利益问题。

一、自由度

IaaS自由度更大。因为选择IaaS服务你相当于获得一个全新的电脑系统，在系统能力范围内，你在这个系统上想怎么玩就怎么玩，当你的应用或网站需要经过特别的配置优化或者有自己独特的运行环境，那么IaaS或许是更好的选择。比如Google的App Engine，作为一种PaaS服务它很长时间里只支持Java和Python，而且还需要通过配置文件去和它自己的运行环境去适配，虽然变相便于选择开发方向和对开发本身作出规范，但同时也是一种掣肘，你触碰不到服务器的“底层”没法随意对它的运作方式作出改动，你只能把焦点集中在代码本身。

二、运维压力

PaaS的运维压力小很多。某种程度上甚至可以说运维压力约等于0。

这就是IaaS高自由度下的代价。因为在IaaS下，邮件服务、数据库服务、文件传输服务等等都可能需要自己搭建，虽然也有一些第三方的服务可以去配置，但是也免不了需要安装好基本的服务和语言环境，从这个意义上来讲，“云”的优势里头“便利”这一点得不到体现，你还是得像“远古”那样，具备 LAMP(Linux+Apache+MySQL+PHP)之类的知识，等花了老半天配置下来累得半死，网站还未必能顺利跑起来。但PaaS通常只需要在服务后台点击一下，就能做项目的增删改操作然后将项目代码Push到服务平台就了事。

事后的运维更是大头，比如数据备份和恢复，万一哪天服务环境出问题了，平时没有备份那只能自认倒霉，而如果你想换一台机器或者更改服务方案，还有可能需要重走一系列的服务配置流程。

关键是，由于IaaS的性质决定，它提供给你的是“基础设施”(机器、系统)，所以你在“基础设施”上搭建的供应用或网站运行的“服务平台”到底出了什么毛病是不归它管的，这意味着为了保证你的东西能顺利健康地运行，你是需要自行投入到运维工作中去的。

而PaaS提供给你的正是“服务平台”，所以运维压力基本上落到了服务上身上了，因为它起码要保证自己不出事。你只要管好你自己的代码就行了。

三、性能

我们平常用IaaS服务，可能一个虚拟机实例里会装上各种语言的运行环境用来运行几个网站，而PaaS则是以“容器”计算，一个容器其实就是一个虚拟机，相当于一个虚拟机就运行一个网站。

那么问题来了：在同样条件下(CPU、内存、带宽等)一个IaaS实例运行3个不同语言环境的网站或者应用，和用3个PaaS容器各自运行应用比较起来，谁的性能更强表现更好?

这个问题我暂时无解。寻找Docker(PaaS技术)和KVM(IaaS技术)性能比较，网上看了不少评论和资料也是众所纷纭。虽然一般提到Docker都说“轻量、高性能、便捷性”是其优点，但是我没有真正的有效地测试过。

不过一位目前专注于Docker开发的前辈有提过，Docker自己给出的结论是同样条件下IaaS的性能还是比PaaS强——那么一丁点。

我们从自由度、运维压力和性能的角度对 IaaS 和 PaaS 两种云服务对web开发者的适用性进行了PK。

下面我们将从便利性及迁移成本这两个角度继续探讨“我的Web应用或网站到底应该在哪种云服务上运行?”这个问题。