This article can also be found in the Premium Editorial Download "Modern Infrastructure: Understanding infrastructure and platform as a service."
Download it now to read this article plus other related content.
Cloud computing is catching on in a big way, and as it matures, adoption keeps growing and new uses emerge. Those in the IT world are getting ever more comfortable with Software as a Service and Infrastructure as a Service. But Platform as a Service remains a murky endeavor, often due to problems with cloud washing and the market's infancy.
Make way for PaaS
Part 1: PaaS adoption hindered by cloud washing, market immaturity
For a certain class of applications, Software as a Service (SaaS), is a slam dunk, providing access to complex applications in a way that does not require a steep outlay of cash and requires low management overhead. Likewise, Infrastructure as a Service (IaaS) is increasingly attractive to many organizations, offering access to vast amounts of compute, storage and bandwidth resources that can be manipulated much like on-premises infrastructure, with no up-front costs.
Platform as a Service (PaaS) is a whole other ballgame. Favored by forward-looking developers, PaaS' main value proposition is increased productivity and faster deployment times. PaaS also provides built-in provisions for automatic scaling and failover, freeing developers from having to learn these complex coding techniques if they want those capabilities in their applications.
"When you combine a prebuilt OS and development platform, application deployment is dramatically simpler," said Roger Jennings, principal consultant of OakLeaf Systems and a .Net developer. While most IT professionals naturally gravitate to IaaS for their cloud needs, it takes just one-tenth the time to stand up a website on Microsoft's Windows Azure PaaS, for example, he claimed.
Today, the market for PaaS is a small fraction of the overall public cloud. But if PaaS takes off -- and many experts believe that it will -- that could have wide-ranging implications for IT professionals, ushering in yet more changes in their roles and responsibilities. But the market is still in its infancy, making it difficult for enterprise IT to predict how many and what types of PaaS platforms and PaaS-resident applications they may be asked to support down the road.
Anatomy of a PaaS
The first thing most IT shops need to get straight is the difference between true PaaS platforms and pseudo PaaS.
"Remember all the cloud washing that we used to see from infrastructure providers?" said James Staten, an analyst with Forrester Research. "It's much worse with PaaS."
PaaS platform roots
Many PaaS platforms have their roots in a specific programming language. Over time, most PaaS vendors have moved beyond a single language and claim to be "polyglot," supporting multiple languages. Nevertheless, their heritage is worth bearing in mind, as it may help inform your choice of which one best fits your environment. Here is an incomplete list of PaaS players and the original development environment for which they were designed.
AppFog — PHP
CloudBees – Java
CloudFoundry – Ruby on Rails
Engine Yard – Ruby on Rails, PHP
Google App Engine – Python
Heroku — Ruby
Microsoft Windows Azure — .Net
Staten said he routinely sees vendors trying to pass off garden-variety IaaS with a few added services as PaaS, confusing developers and operations professionals alike.
At its core, a true PaaS platform must include an abstracted runtime environment, an application server, caching layers, integration with development tools, plus features for autoscaling and failover. That middleware, to use an old-school term, can run atop public IaaS, or be delivered to run on on-premises hardware.
Examples of true PaaS include, but are not limited to, Microsoft Azure, Engine Yard, Heroku, CloudBees and Google App Engine, Staten said. Amazon Web Service's (AWS) Elastic BeanStalk, while often touted as PaaS, doesn't quite fit the bill.
"What Beanstalk does is take a script for how to deploy a complex application on IaaS, plus adds scripting for failover and scalability," Staten said. In contrast, true PaaS does not supply scripts, but exposes components that can be called by the application, he explained.
The differences between true and pseudo PaaS are not simply academic; there are real implications for the developer team. For developers who believe they're working on PaaS, "the expectation is that. I write my code, I deploy it, it automatically scales and it automatically fails over," Staten said. On a pseudo PaaS, "there's an expectation miscue; the application doesn't scale and it falls over."
This was first published in June 2013