何为PaaS

  地球人都知道PaaS就是Platform as a Service的缩写，但到底什么是PaaS呢？

  假如我们现在需要一个业务，提供一个很简单的"hello world"服务，那么需要的资源有哪些呢，看下图：

IaaS&PaaS覆盖图

从最底层的IDC、机房、网络、服务器，到服务器上的操作系统，操作系统上的服务软件（主要包括WebServices、数据库、缓存等），当然最终在WebServices里运行的是我们的业务代码。如果我们生活在互联网的初始阶段，那么这些元素都是需要我们关心的，我们不得不为带宽机架跟运营商打交道，为域名备案跟通管局打交道，为服务器跟服务器供应商打交道，最后还得雇佣管理一个运维团队，帮助维护自己的IT资源。这会使人疯掉！

    现在幸福的事情，IaaS（Infrastructure as a Service），来了，IaaS帮我们节省了红线所涉及的部分，包括IDC、网络、服务器、甚至包括部分操作系统，为什么说部分操作系统呢？因为我们还是要关心操作系统挂掉、机器宕机等因素，如果我们不关心，或者说我们从业务的架构上不考虑这些因素，是很难保证业务稳定的。

    而PaaS呢？PaaS帮我们节省了蓝色涉及的部分，也就是说除了IaaS节省的部分外，还节省了服务软件和代码的部分，换句话说，PaaS提供了一个完整的业务开发、运行环境，我们无需关心怎么安装Apache、怎么配置缓存、怎么配置数据库读写分离，所有这些已经以服务的方式（注意：不是以机器的方式）提供好了，我们需要做的，只是把业务代码放上来就好了。

    总之，IaaS提供的还是虚拟机资源，而PaaS提供的是实际业务的开发、运行环境，正如SAE对自己的定位：“Web应用/业务的分布式开发、运行平台”。

PaaS和IaaS的区别

    刚才说了IaaS主要是虚拟机资源，而PaaS提供的是业务的开发、运行环境，那么PaaS和IaaS的区别就是这些吗？

    云计算追求的就是通过共享从而降低成本，并且利用技术提供更好的服务。我们来看一个生活中的例子：

    我们去饭店吃饭，菜很好吃，但有一个事比较烦心：“到底点多少菜”，点的多了怕浪费，点的少了怕不够吃，快吃完了再点又怕上菜慢，现在我们利用云计算的思路解决这个问题=》

    IaaS的办法：将菜“虚拟化”，将一份菜切分为半份菜、1/3份菜，甚至1/4菜，用户可以点小份。

    这种办法很有效，可以有效降低我们吃饭的成本，但仍不是特别方便，A，我们无法准确预估需要点多少份；B，吃着吃着饭，突然来了一个朋友，又要现点份菜，这需要上菜时间，耽误工夫。

    那么怎么才能做的更好呢？人类吃饭的单位都是一口，没有人能吃“半口饭”，能不能按照口供应呢？我们来看：

    PaaS的办法：通过一种技术，将菜按口供应，每个顾客只要张嘴就可以吃菜，不张嘴就不吃了，停止计费，来了一个新朋友，也是通过同样的方式，只要张嘴就有菜吃。

IaaS&PaaS解决问题对比

    从这张图可以看出，PaaS对比IaaS虚拟化的粒度更细，更贴近用户的实际需要，因为用户真正需要的并不是虚拟机，而是满足业务运行需求。下面我们来仔细讨论一下PaaS和IaaS的区别吧：

PaaS的计费粒度更细

   从计费粒度上，PaaS比IaaS更细，IaaS普遍以 虚拟机的实例数*运行时间 计费，即使IaaS标榜他们的计费单元可以精确到秒级，但如果用户业务某个时间段没有任何请求，用户仍然需要为这部分虚拟机使用时间付费，因为用户无法预知下一次请求什么时候到来，所以用户无法关闭所有虚拟机。

    而PaaS是以请求消耗的资源为单元计费的，如SAE价格：

SAE价格列表

    这样，如果用户的业务暂时没有任何请求，则用户无需支付任何费用，做到了真正的“所付即所用”。

    从SAE上用户的实际使用情况来看，几乎所有用户对比之前的使用IaaS时都会有不同程度的成本节约，以某创业为例，日均15万PV，

PaaS比IaaS更可靠

     IaaS用户容易高估自己的服务可靠性，这里面有两个原因：
     - IaaS服务厂商往往夸大自己的服务可靠性，实际从目前看任何一个IaaS厂商都时不时有重大故障报出来
     - IaaS用户迷信厂商提供的SLA，自己不进行高可靠架构部署
     我见过在IaaS只用2台虚拟机，然后标榜自己的服务可靠性有多高的用户，殊不知当物理机宕机时，虚拟机一定会收到影响，目前IaaS服务商能提供热迁移的只是少数，即使能提供也是需要提前准备的，无法做到故障时实时切换

      PaaS隐藏了服务器、虚拟机的概念，把一切功能服务化，而这些服务都是基于高可靠架构的，以SAE提供的Cron定时服务为例，这套Cron服务是基于分布式环境，任何一台机器宕机都不会影响定时任务的准确触发。

PaaS是真正的“高可扩展”

      要明白这个问题，我们先来看什么叫“可扩展”，可扩展有两个层面：
      1，用户可以自行扩展资源，通过手工的方式（包括页面点击、API调用等）
      2，随着用户的业务扩张，自动扩展

      几乎所有的IaaS厂商都可以实现层面1，但层面1的问题是，用户不知道什么时候扩展。用户真正需要的是层面2的扩展，即随着业务增长，资源自动扩展，整个过程用户可以完全不感知，目前这种层面的“高可扩展”没有任何一家IaaS厂商提供。

     而SAE恰恰提供这种层面2的高可扩展，SAE会自动判断用户的业务是否存在等待队列，一旦请求出现等待，将自动将请求分配新的计算节点，通过这种机制，用户从PV 100/天涨到PV 1亿/天，可以做到瞬间实现而无需用户做任何操作。

PaaS是免运维的云计算

    “免运维”是PaaS的最大魅力，因为用户把代码放上来，就可以完全不管了，无论业务凋零还是业务暴涨，都无需人工干预，当然SAE提供完整的图表展现用户的各种请求曲线，了解业务情况还是必须的。在SAE上的很多用户团队里都是0运维，也就是一个运维人员都没有，这在传统业务团队中是不可想象的。

PaaS的缺点

    虽然PaaS有免运维、高可靠、自动扩展、更加节约成本等优点，但是PaaS也有缺点，PaaS的最大缺点就是因为用户无法看见服务器，感受不到虚拟机，这样限制了用户的自主性和灵活性，比如用户想部署一个自己的C程序，或者用户想直接开一个FTP管理文件，这些需求都无法在PaaS中满足，因为PaaS提供的是一个业务的开发、运行环境，而不是用户能够登陆的云主机。

    那么既然PaaS有优点也有缺点，那么什么情况适合使用PaaS呢？

PaaS的适用场景

    其实，PaaS和IaaS各有各的适用场景，主要由以下一些规律：

    非HTTP业务（如游戏服务端、数据分析服务）适合用IaaS，HTTP业务（网站、RESTfulAPI服务端）适合用PaaS；

    大型团队（拥有丰富的系统、网络、运维能力和经验）适合用IaaS，创业团队/小型团队（团队规模小，全部聚焦在业务）适合用PaaS；

   技术团队（喜欢定制化、喜欢掌控一切）适合用IaaS，产品团队（聚焦在产品开发）适合用PaaS；

   资金充裕（能够雇佣昂贵的系统工程师、能够支付没有流量的虚机费用）的团队适合用IaaS，资金紧张（对成本比较care的用户）的适合用PaaS；

PaaS是真正的云计算平台

   总之，在桌面时代，我们需要的不是IBM ThinkPad、甚至不是Windows，而是上面成千上万的应用、游戏；到了云时代，我们需要的既不是几core的虚拟机、也不是什么EBS存储，而是一个能让我们的业务稳定可靠省心运行的环境，如果有这样的环境，除了技术Geek，我想没有人想管服务器。。。

   PaaS尽管有种种问题，但它确实是从诞生就想提供给用户一个省心、稳定的业务运行环境，用户一旦部署，不需要关心扩容，不需要关心架构，不需要关心宕机，不需要关心配置，不需要关心优化，就可以随着业务的发展时时满足各种需要，所以PaaS是真正的云计算平台。