公共PaaS变得不太适合满足现代Web应用程序和移动应用程序的要求，而这种情况似乎根本没有任何好转。

　　你可能还没有听到这个说法，但公共PaaS已死。这倒不是说，公共PaaS不会苟延残喘一段时日。但是公共PaaS变得不太适合满足现代Web应用程序和移动应用程序的要求，而这种情况似乎根本没有任何好转。不妨让我们分析一下为什么是这样。

　　第一个原因：公共PaaS成本高昂，又缺乏灵活性。

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

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

　　第二个原因：公共PaaS的安全选项比较少。

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

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

　　第三个原因：缺少高可用性选项。

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

　　第四个原因：微服务架构在发展壮大。

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

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

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

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

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

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

　　结果：公共PaaS逐渐变成私有PaaS。

　　由于软件架构向容器和微服务转变，又加上需要具有高可用性、高安全性、高扩展性的应用程序，公共PaaS提供商变得更像是业余爱好者的乐土。这使得PaaS提供商受到挤压――CloudBees等一些公共PaaS提供商已被挤出去，Heroku等另一些提供商则在减慢公共PaaS方面创新的步伐。正如Heroku和PivotalCF表明的那样，许多提供商发现提供私有PaaS解决方案更受欢迎。

　　ZStack 创始人 张鑫对本文的点评与补充：

　　观点倒没错，但在第二个原因里面举例不准确，可能是个纰漏。公共paas其实分两种，一种是老式的平台型paas，例如google GAE，新浪SAE这类。这篇文章讲的公共paas实际上说的是这种。这种大而全的平台型paas已经不流行了，docker的兴起，和它以前的母公司dotcloud关闭就是证明。

　　但第二个原因里面举例Tinder和SnapChat API作为证据是不准确的。因为他们是第二种公共paas的形式，即垂直细分领域paas。这一类是现在非常流行，而且从我角度来看是大有前途的。在国内现在流行的即时通信云就是这种，代表厂家有网易、环信这样的，包括最近的daocloud似乎也进入了这个领域。垂直领域的paas现在的势头非常好，它通过SDK的方式让应用程序开发变得更加简单，而且不可或缺。例如你现在写一个类似的微信的程序，有了这些paas的帮助，就不用自己开发通信的中间件和后台。这个类型的paas我觉得将来会成为趋势。