×

驳“公共PaaS已死”

96
conglei_kobe
2016.04.07 14:31* 字数 2258


最近好多圈内好友转这篇文章给我看 公共PaaS已死,盖棺论定!,问我的想法,我先把我的观点亮出来:

- 这篇文章内容是bullshit

- 公共PaaS死不死不知道,反正SAE今年年底能做到正向盈利

- 垂直化和私有化是方向,对于IaaS/PaaS/SaaS皆是

现在咱们再来说说为啥 公共PaaS已死,盖棺论定!是bullshit:

1,“第一个原因:公共PaaS成本高昂,又缺乏灵活性。

虽然使用公共PaaS在项目开始阶段很快速,但是久而久之,成本比较高。我们之前撰文探讨过这点,特别指出:将服务器管理这块扔给提供商带来的缺点是,随着你不断扩大规模,成本就会大幅增加。

与此同时,公共PaaS提供的灵活性比较差。并非所有的软件开发商都支持PaaS平台,这迫使你选择某一种PaaS种市场解决方案,或者负责自定义集成这项繁重任务。另外,PaaS提供商势必指定你在语言和工具方面可以获得的选择。由于公共PaaS提供商提供的选择有限,这会制约应用程序的成熟性。


PaaS从技术上讲虚拟化的程度比IaaS更轻量化,共享程度更高,而共享程度越高,用户的成本越低,这是常识。从实际使用情况来讲,PaaS更适合中小企业/startup企业,因为他们可以省去雇用系统工程师的成本,只雇用web开发工程师来完成业务开发。换句话说IaaS的直接使用者是系统工程师,而PaaS的直接使用者是web开发工程师。对于灵活性,是PaaS的短板,虽然目前PaaS/CaaS也用了很多技术来弥补这个短板,但不可否认,对比IaaS,灵活性还是差一点。

2,“第二个原因:公共PaaS的安全选项比较少。

随着应用程序不断成熟,要求常常随之提高,需要更高的安全性。如果使用PaaS,就无法扩建虚拟私有云(VPC),将后端资源与公共互联网隔离开来。如果企业无法通过VPN连接到私有数据中心、安全地访问其数据,它们同样面临局限性。

公共PaaS上的安全选项也很有限。由于最近Tinder和SnapChat API相继曝出安全漏洞,现在对移动API和物联网方面的端点安全要求更高了。许多公司可能发觉更难在PaaS里面添加更多的基础设施层次、为移动后端确保安全。”

完全没懂PaaS、IaaS和能否扩建VPC有啥关系,无论是PaaS/IaaS,都可以通过VPN隧道将私有数据和公有数据联系起来,比如SAE,就提供“VPN隧道服务”,可以将企业的内部数据和SAE上的RDS联系起来,比如做主从同步,建立好VPN隧道后,用户能看到就是他在SAE上的RDS内网隔离环境。对比内网VPC自组网,PaaS/CaaS都是以域名或者Visual IP的方式来提供,比如k8s就以VIP的方式提供内网服务,这样就隐藏了内网实际IP,好处是可以做到故障平滑迁移。

说到安全,这观点就更可笑了,你的API有XSS漏洞和IaaS/PaaS有啥关系?你需要做的是对接一个类似WAF服务,在这方面很多云计算厂商和第三方厂商都提供。

3,“第三个原因:缺少高可用性选项。

如果你在构建一个具有高可用性的Web应用程序或移动应用程序,部署到单一可用区(AZ)被认为是不可接受的。不过,公共PaaS提供商通常为它们所在的每个区域只提供一个可用区。加上缺少基于IP的过滤机制和拒绝服务(DoS)预防机制,PaaS连最简单的DoS攻击都无力防备。其解决办法就是:添加更多的进程来处理加大的负载,应对额外的DoS攻击途径(即花更多的钱,结果还是解决不了问题)。”

跨几个Zone跟PaaS/IaaS没有半毛钱关系,只跟钱有关系。DDoS防护是云计算的必备服务,不知道文章“PaaS连最简单的DoS攻击都无力防备”的结论是怎么得出的?从技术角度来讲,DDoS防护取决于有无实时流量分析/学习服务、有无清洗中心、有无硬件防护等,DDoS防护不仅跟PaaS/IaaS没关系,甚至跟云都没关系,任何一个做大型网站都需要在网络基础设施上防护DDoS。

多说一句,就DDoS来讲,PaaS反而比IaaS更安全一些,因为PaaS往往以域名的方式提供服务,而对用户隐藏了外网IP,这样就多了一层HA,一旦遇到攻击,PaaS平台可以切换实际IP做规避,而对于IaaS,如果用户承担不了高防的费用就只有被IP黑洞了。同时,因为PaaS专注于HTTP服务,甚至可以在网络入口处屏蔽UDP协议,进一步提高安全系数。当然,对于威胁最大的syn-flood,需要清洗中心,清洗中心的防护能力取决于云服务商的经济能力,但不是取决于IaaS还是PaaS。

4,“第四个原因:微服务架构在发展壮大。

自2014年以来,使用微服务开发应用程序这个趋势一直愈演愈烈。谷歌趋势表明,2014年年底,公众突然加大了对微服务器的关注度。

微服务架构采用的软件设计方法是,构建并部署单一微服务,或者一小批相关的微服务,它们彼此独立。然后将这些微服务整合起来,组成经受得住停运考验的应用程序。

由于使用微服务的应用程序日益增多,它们也需要PaaS提供商方面配置越来越多的独立应用程序。除非微服务小得足以在最小单位的服务方案下也可以运行,否则扩展每个微服务的成本就会迅速增加。

第五个原因:向使用Docker的容器化转移。

容器让物理和虚拟服务器能够隔离进程,这些进程各自拥有正常运行所需要的独立文件系统和资源。容器比虚拟机来得小巧,因为它们并不包括一个完整的操作系统。正如谷歌趋势图表明的那样,容器是微服务架构大行其道的主要原因。

如今,容器与微服务结合起来,部署数十个、数百个、乃至数千个微服务实例。这造就了支持自行构建PaaS这种场景的新一代云计算。"

微服务是个比较大的话题,这里不展开,只能说,对于大型企业,基本采用服务统一化的模式。同时,微服务跟PaaS/IaaS也没啥关系,目前主流的PaaS平台几乎都支持通过docker技术提供微服务。

PaaS的未来

与其“扬长补短”不如做到“扬长避短”,公有云上,PaaS与其在灵活性和IaaS死拼,还不如结合行业特点把上层应用服务/运维做好,尤其结合H5的特点,让用户用起来简单、爽、啥都不用管,从而形成和IaaS的体验差异。

私有PaaS是未来方向,其实PaaS的本质就是隐藏了IaaS的细节,降低了用户使用云的成本,这对于任何企业都是非常重要的。未来PaaS将同时具有管理公有云和私有云的能力,并且帮助用户的业务在IaaS稳定运行,成为用户使用云的入口。

多说无益,报表见吧。

随笔
Web note ad 1