公共PaaS已死，盖棺论定！
公共PaaS变得不太适合满足现代Web应用程序和移动应用程序的要求，而这种情况似乎根本没有任何好转。
你可能还没有听到这个说法，但公共PaaS已死。这倒不是说，公共PaaS不会苟延残喘一段时日。但是公共PaaS变得不太适合满足现代Web应用程序和移动应用程序的要求，而这种情况似乎根本没有任何好转。不妨让我们分析一下为什么是这样。
虽然使用公共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提供商方面配置越来越多的独立应用程序。除非微服务小得足以在最小单位的服务方案下也可以运行，否则扩展每个微服务的成本就会迅速增加。
容器让物理和虚拟服务器能够隔离进程，这些进程各自拥有正常运行所需要的独立文件系统和资源。容器比虚拟机来得小巧，因为它们并不包括一个完整的操作系统。正如谷歌趋势图表明的那样，容器是微服务架构大行其道的主要原因。
如今，容器与微服务结合起来，部署数十个、数百个、乃至数千个微服务实例。这造就了支持自行构建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我觉得将来会成为趋势。
云头条编译｜未经授权谢绝转载
相关阅读：
2016年平台即服务（PaaS）比较矩阵报告（附14、15年魔力象限解读）
PaaS群欢迎加入，群主微信：aclood
英文原文：
It's Official: Public PaaS Is Dead
Public PaaS is becoming less of a fit for the needs of modern web and mobile applications. And it doesn't seem to be getting any better.
The Cloud Zone is brought to you in partnership with Cloud 66. From code to Cloud in under 5 minutes: build, deploy and manage any application with a single, integrated toolkit for Docker and Rails.
You may not have heard about this yet, but public PaaS is dead. That doesn't mean that it won't be around for some time. But public PaaS is becoming less of a fit for the needs of modern web and mobile applications. And it doesn't seem to be getting any better. Let's examine why this is the case and what you can do about it.
Reason #1: Public PaaS Is Expensive And Less Flexible
While using a public PaaS is fast at the start of a project, there is a higher cost over time. We wrote about this previously, noting that the cost of offloading server management greatly increases cost as you scale.
At the same time, a public PaaS offers less flexibility. Not all software vendors support PaaS platforms, forcing you to select one of the PaaS marketplace offerings or do the heavy lifting of a custom integration. Plus, PaaS vendors get to dictate the language and tool choices available, forcing you to fit into their one size fits all approach. This can restrict application maturity due to the limited options available by public PaaS vendors.
Reason #2: Public PaaS Has Fewer Security Options
As applications mature, demand often grows for greater security. With a PaaS, there is no way to build out a virtual private cloud (VPC) to isolate backend resources from the public Internet. There are also limitations for enterprises that are unable to VPN to private data centers to securely access their data.
Security options are also limited on public PaaS. There is now higher demand for endpoint security around mobile APIs and IoT due to recent exploits of the Tinder and SnapChat APIs. Companies may find it more difficult to add more infrastructure layers within their PaaS to secure their mobile backend.
Reason #3: Lack Of High Availability Options
If you are building a highly available web or mobile application, deploying to a single availability zone (AZ) is considered unacceptable. Yet, public PaaS vendors typically offer only one AZ for each region in which they reside. Combined with the lack of IP-based filtering and denial-of-service (DoS) prevention, PaaS is ill-prepared for even the most simple DoS. Their solution: add more processes to handle the increased load to overcome the additional DoS attack vectors (i.e.: spend more money with them to not solve the problem).
Reason #4: Microservice Architecture Is Growing
The trend of architecting applications using microservices have been gaining huge momentum since 2014. Google trends shows the growth in microservice interest near the end of 2014.
Microservice architecture approaches software design by building and deploying a single microservice, or a small number of related microservices, in isolation. Microservices are then integrated to compose applications that can withstand outages.
As apps grow in microservice count, they require more and more independent apps to be provisioned on the PaaS provider. Unless the microservice is small enough to operate under the smallest plan, the cost for scaling each microservice begins to grow quicky.
Reason #5: The Move To Containerization Using Docker
Containers enable physical and virtual servers to isolate processes with their own filesystem and the resources they require to operate. They are smaller than a virtual machine, as they do not include a full operating system. Containers are the primary reason that the microservice architecture has been on the rise, as this Google trends graph shows.
Containers are being combined with microservices to deploy tens, hundreds, or even thousands of microservice instances. This is creating a new generation of cloud computing that allows for a build-your-own-PaaS scenario.
The result: Public PaaS Is Becoming Private PaaS
With the shift in software architecture moving to containers and microservices, and the need for highly-available and secure applications that scale, public PaaS vendors are becoming more of a hobbyist playground. This is causing PaaS vendors to be squeezed - some likeCloudBees are being squeezed out, while others such as Heroku are slowing innovation on their public PaaS. Many are finding better traction in solving private PaaS solutions, asHeroku and PivotalCF demonstrate.