当开发了一个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强——那么一丁点。
对这个问题有兴趣的朋友不妨看看这个slideshow：KVM and Docker LXC benchmarking with openstack
我们从自由度、运维压力和性能的角度对 IaaS 和 PaaS 两种云服务对web开发者的适用性进行了PK。
下面我们将从便利性及迁移成本这两个角度继续探讨“我的Web应用或网站到底应该在哪种云服务上运行?”这个问题。
#p#
四、便利性
有一种说法，是Docker部署应用“像点个按钮一样简单。”其实对于一般人来说，真正应验这句话的是PaaS服务(有些PaaS服务是建立在Docker基础上的)。
做得好的PaaS在这点上是可以秒杀IaaS的。譬如GAE，当你修改完代码，用Google提供的软件点一下按钮就可以完成在本地测试和在云端运行，你甚至都不需要去知道你的代码是怎么传上去的。
而IaaS基于上边所说的有前后期的运维压力，你甚至在部署应用之前得选择你的服务器要安装什么操作系统。
事实上现在PaaS服务主流的上传方式还是有一点学习曲线的，比如你可能需要了解怎么用SVN或者GIT去更新和推送你的代码到PaaS服务上，这个过程不比传统FTP上传来得简单，但是本身SVN和GIT作为版本控制工具的诸多优势，是FTP不可比拟的，熟悉基本的使用后，一切就交给一两句命令去完成。 而对于PaaS服务商来讲，如何解决开发环境和生产环境里项目可能产生的差异是一个挑战。比如你一个WordPress项目虽然通过GIT做到本地和云端的代码一致，但是数据库如何解决一致的问题?云端运行的版本在线安装了插件以及上传了图片等静态文件上去，这种情况造成的差异问题如何解决?
五、迁移成本
对于有运维基础的人来说，IaaS比较保险，虽然麻烦一点，但是毕竟要拿回文件和数据是分分钟的事情。
PaaS……主要看服务商怎么做，程序代码由于能做到云端和本地天然一致，自然没问题，问题上面一条提到的静态文件和数据怎么办，而且即便都拿到了，能不能在另一个平台顺利运行也是个问题。比如我当年在GAE上运行的网站在GAE被墙后基本上就宣告死亡了。这个问题上我建议即使选择PaaS，也不要选择服务太奇葩的，GAE的问题在于它的数据库类型，几乎在其他环境下没法用。尽量选择服务环境比较通用的。
总结
总的来讲，IaaS是让服务环境去适应项目程序，你需要花精力去做运维工作配置好适合的运行环境;PaaS是让项目程序去适应服务环境，你需要限制程序开发的自由度按照PaaS服务的一定规范去开发你的项目。
我建议先看看备选的PaaS服务商提供的服务是否能满足你项目正常运行的需要，小型项目和需要快速上线的项目可以用PaaS快速部署看看效果，而使用常用CMS创建的网站，由于对运行环境的定制要求不高，也特别适合用PaaS。 如果有后期优化运行环境需要或者程序不稳定因素大的、有可能大改程序的，那么基于自由度的因素选择IaaS或许更适合。
