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 like CloudBees 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, as Heroku and PivotalCF demonstrate.
What's the solution?
Public PaaS is dead - at least for all but the simple prototype or small, non-critical application. So, what are you supposed to do? It seems the answer is to build on top of infrastructure cloud vendors.
The problem with building on top of cloud infrastructure is that it exposes all of the details of server management that you probably prefer not to handle. That is where Cloud 66 can help. Cloud 66 can help you manage your infrastructure resources and deploy your Realscale, container-based applications and microservices.
With infrastructure management solved, the next step is to focus on your software architecture. So, how do you architect your solution using cloud infrastructure so that it will scale as you grow?
Realscale is our philosophy for addressing these concerns. Realscale helps teams create a scalable software architecture that can handle thousands to a million uniques per day - without the infrastructure complexity often found in web-scale vendors that deal with tens to hundreds of millions of uniques.