CloudBees is the only cloud company focused on servicing the complete develop-to-deploy lifecycle of Java web applications in the cloud – where customers do not have to worry about servers, virtual machines or IT staff. The CloudBees platform today includes DEV@cloud, a service that lets developers take their build and test environments to the cloud, and RUN@cloud, which lets teams seamlessly deploy these applications to production on the cloud.
There is a growing interest in PaaS offerings, with Gartner going as far as predicting that 2011 will be the year of the PaaS. Yet, when talking to people, I realize that there is not a good understanding of what a PaaS is, what it does and how it differentiates from traditional middleware layers. This is a frequent problem with fast-growing technologies: the usage of acronyms describing those technologies tends to get ahead of the real understanding of what they do.
So, what’s a PaaS? The most frequent answer you will get is that a PaaS is a IaaS (pronounced “yass”) with “some” traditional middleware software pre-installed on top of its servers. As developers, we have been used to think about our environment in terms of “Servers”. This has become our unit of work, our unit of provisioning, and has defined up to what level we can scale vertically, and as of when we have to start scaling horizontally, what it meant in terms of application configuration, deployment, etc. Consequently, it should come as no surprise that most of us would come to think of a PaaS as a IaaS with some traditional middleware layer pre-installed on top of it.
The problem with this “naïve” approach is that doesn’t really solve anything new. Au contraire, it tends to make it more complex since you typically have less control over a cloud infrastructure than on your own servers.
What problem are we trying to solve?
Traditionally, one of the main difficulties companies face when developing a new service is the high level of friction between IT operations and development teams. Both teams have different aims, different timelines and different worries. Put simply, a different DNA. Yet, bringing an application to life is a long sequence of high-friction steps involving both IT and development teams. Some of those steps are one-time activities, some are recurring activities, but none are trivial steps. Want to add more nodes to your cluster? Want to push a new version to production? Want to take a snapshot of your running environment for some testing? Those are all high friction activities leading to high costs and bad time-to-market.
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.
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.