Why PaaS Failed
“PaaS, as a name, as a concept and as a solution is dead.”
So says Abby Kearns, the chief executive of the Cloud Foundry – itself one of the best known PaaS offerings.
A few years ago, most analysts predicted an equal three-way market split between IaaS, SaaS, and PaaS. But the last actually holds a much smaller piece of the pie, and that’s not expected to change.
Heroku, one of the biggest public PaaS providers, only has 6 of the top 10,000 websites running on it.
So, we have to ask, what caused the downfall of PaaS, and how has this impacted its relationship with IaaS?
Containers have been around for some time now and are a crucial component of PaaS. But in recent years, container technology has started to be used in its own right for the deployment of applications. In a big way.
One of the main selling points of PaaS is that it can essentially handle the deployment of an application into a live environment for you. However, container technology automates the deployment of applications inside software containers. By breaking down an application into packages before the production stage, containers have eroded the need for PaaS.
In fact, companies such as Red Hat and Pivotal have started to reposition their PaaS solutions more as container automation/orchestration tools than traditional PaaS offerings.
One of the main containerisation success stories has been Docker, with 40% of enterprises now using it and 30% more planning to employ it. Advocates relish its leaner, more efficient way of handling microservices – its extra layer of abstraction allows it to portion cloud-based operating systems.
As fewer resources are needed, the Docker engine only has to be linked to a single instance of Linux – not an entire guest operating system for each virtual machine, as with PaaS.
Lack of Control
The advent of virtual machines meant developers no longer had to sit twiddling their thumbs while a physical machine was set up for them – they could create a new development environment themselves.
The movement over recent years has been in the direction of providing more control to devs but PaaS has actually restricted this in many ways. Configuration of things like an application’s monitoring, scaling, performance, and logging is considerably hindered. Freedom to choose your own language, database and stack is also drastically limited.
One of the advantages of PaaS is that, when it runs smoothly, it frees up time for developers to do their jobs, as they don’t have to get involved with the underlying management and deployment of applications. They can work on developing features.
But what happens when access to a bespoke/niche tool or service is needed to make that feature a reality? When they need to pick the right tool for the job? Good luck.
Admittedly, not all businesses will need to tinker quite this much when developing software, but many do, and the restrictive nature of PaaS certainly hasn’t helped its sluggish growth.
Finally, what happens when PaaS is not running smoothly – when the PaaS provider is having issues? Well, often, not much – not being in the driving seat can tend to mean the company has to just “hurry up and wait”.
This lack of control can frequently make PaaS expensive as well as frustrating. By being tied into the vendor’s system, the customer is often unable to access free or cheaper open-source versions of tools they need. So they’re forced to spend more on PaaS add-ons instead.
Expense has long been a problem with IaaS too – in fact the public cloud is roughly 4-5 times more costly than a traditional network infrastructure set-up.
By helping development and operations teams work together better, it can increase the speed and quality of continuous delivery. Of the two teams, obviously, it’s Ops that has the expertise in handling the infrastructure, and, in reality, this expertise is often delivered as a service to the devs.
But with PaaS, this relationship is disrupted.
The devs increase their knowledge of and involvement with Ops issues, which they often don’t really embrace, as they’d rather be coding. And the expertise and interest in network infrastructure of the Ops team can be pretty much wasted. Proving PaaS to be somewhat incompatible with the DevOps culture.
PaaS has failed, much like IaaS has.
It’s failed because:
- Containers are frequently an easier and lighter-weight solution.
- PaaS is inflexible and puts developers into a sandbox. Often, this is not just frustrating but ineffective too.
- DevOps is prevalent and PaaS struggles to be compatible.
- The closed nature of PaaS makes it expensive, as free/cheaper open source tools are locked out.
The future of PaaS is changing rapidly, as container management platform companies such as Apcera lead the way. And as stated by Apcera CEO, Derek Collison:
“The biggest threat to established PaaS vendors will be infrastructure-as-a-service systems creeping up the stack as they provide new tools to handle tasks like provisioning, managing and monitoring applications.”
The truth is, in the coming years, PaaS will likely be subsumed into larger IaaS offerings even more than it currently is.
However, at Happi we’ll stay focussed on delivering true IaaS, and, for the first time, give customers full control over the provisioning, deployment and management of their hosting environment via our intuitive network infrastructure design software.