何为PaaS
地球人都知道PaaS就是Platform as a Service的缩写,但到底什么是PaaS呢?
假如我们现在需要一个业务,提供一个很简单的"hello world"服务,那么需要的资源有哪些呢,看下图:
从最底层的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的办法:通过一种技术,将菜按口供应,每个顾客只要张嘴就可以吃菜,不张嘴就不吃了,停止计费,来了一个新朋友,也是通过同样的方式,只要张嘴就有菜吃。
从这张图可以看出,PaaS对比IaaS虚拟化的粒度更细,更贴近用户的实际需要,因为用户真正需要的并不是虚拟机,而是满足业务运行需求。下面我们来仔细讨论一下PaaS和IaaS的区别吧:
PaaS的计费粒度更细
从计费粒度上,PaaS比IaaS更细,IaaS普遍以 虚拟机的实例数*运行时间 计费,即使IaaS标榜他们的计费单元可以精确到秒级,但如果用户业务某个时间段没有任何请求,用户仍然需要为这部分虚拟机使用时间付费,因为用户无法预知下一次请求什么时候到来,所以用户无法关闭所有虚拟机。
而PaaS是以请求消耗的资源为单元计费的,如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是真正的云计算平台。
CIO之家 www.ciozj.com 公众号:imciow