What is a PaaS, After All?

There is a growing interest in PaaS offerings, with
How could a PaaS help us drop that friction?
The key concept here is to change the level of abstraction that developers will have to deal with. Application developers should not have to worry about servers, virtual machines, application servers, deployment scenarios, clustering, etc. The only things developers should have to worry about are … applications. Developers should be able to interact with a platform that provides a self-service environment for all of their typical activities… without any dependency on or interaction with IT. Setting up a new application, testing it, deploying it to production, deploying a new version, auto-scaling it, etc. should all be managed by the platform, not by a mix of IT and developers. It is then up to the PaaS to map this high-level abstraction, applications, to lower-level Lego blocks, servers.

In summary, a proper PaaS should put back the developers in charge of their applications.
As importantly, a PaaS is not just a huge productivity and time-to-market boost for developers, it is also a great time and energy saver for IT teams. By leveraging a PaaS, IT ends up not managing myriad applications of various sizes, each with their own requirements, their own timeline. Instead, IT ends-up managing a single entity, a single “container”, the PaaS. This structure provides a clean demarcation line between IT and development.

Cloud vs. Cloud

What should be apparent by now is that the cloud attributes (pay as you go, self-service, elasticity, etc.) are not linked in any way, shape or form to “IT resources” such as servers. Those attributes are generic and can be applied to any abstraction that makes sense to the problem we are trying to solve. And so the job of a PaaS is to “cloudify” applications, not servers.

The reality

That’s for the theory at least. When you look at the PaaS solutions on the market, you’ll find lots of different approaches.
A number of PaaS implementations out there are still very much examples of the naïve approach of “IaaS+middleware” that we’ve seen above. PaaS’s such as Azure or Beanstalk follow this approach pretty closely. Those are what I’d call “first generation” PaaS: they map legacy middleware on top of cloud infrastructure. In doing so, you get the advantages (and some of the inconvenience) of a IaaS, but none of the advantages a PaaS can bring.
Some other PaaS’s on the other hand — I’d call them “2nd generation PaaS” — do offer that kind of abstraction. Those include CloudBees obviously but also Salesforce.com and Google App Engine. The problem with some of those implementations is that in order to achieve proper “server abstraction” and offer an application-centric view of the world, they clutter their containers with plenty of constraints that developers have to follow (such as the inability to create threads or the maximum duration of HTTP invocations). The problem with that approach this is that middleware developers tend to be smart and those kind of constraints do not fly long.
If you want to get a better feel of what a PaaS has to offer, give CloudBees a try, this is a best way to understand what it brings. Take an existing application, and deploy it fast on RUN@cloud — we are waiting for your feedback.

Sacha Labourey, CEO

Blog Categories: 


I agree that IaaS+Middleware != PaaS, but IaaS+Middleware is a necessary condition to achieve PaaS (at least the interesting flavours of PaaS).

Indeed - necessary but not sufficient.

Add new comment