The Many Faces of PaaS

By now, enterprises understand the value of Software as a Service (SaaS) and Infrastructure as a Service (IaaS), but there still is much confusion about Platform as a Service (PaaS). This confusion is one reason why enterprises have been slow to adopt PaaS. Why is there so much confusion? Because PaaS is still in its early days of maturity, but it is growing up really quickly right before our eyes.

In the early days, PaaS solutions were limited to running on a single stack and on the PaaS provider’s infrastructure. For example, Force.com required Apex, Google required Python (they have added other languages over the years), Heroku required Ruby, and Microsoft required .NET. Of the four, only Heroku did not require that customers run on their own infrastructure, but to use Heroku you had to run on AWS. Although many eager developers started building on top of PaaS, very few enterprises took the leap of faith because of the constraints.

The next wave of PaaS emerged where companies like EngineYard started supporting multiple stacks like Rails, Python, PHP, Java, etc.  Heroku added additional stacks as well.  That was great but the enterprises wanted to dictate where the data would reside and even the type of infrastructure to run the applications on.  Enterprises wanted to use a combination of bare metal servers, virtualized servers, and container-based servers.

This gave birth to today’s PaaS solutions, which support multiple stacks and multiple clouds: Public, Private, Hybrid. All of these choices have created confusion for many customers because it is not clear what the pros and cons of the various PaaS deployment options are. Choosing the right PaaS deployment model requires understanding trade-offs between control and agility. The picture below shows the different permutations of PaaS that are available in the market place. The early PaaS vendors offer just the “Public Hosted”, some offer just the “Private Unmanaged” deployment model, but many of the emerging PaaS vendors are offering all or most of the six deployment models.

Public Hosted – This is the classic PaaS deployment model like Force.com, Microsoft Azure, and Google App Engine, where the vendor supplies the data center and manages all of the infrastructure. The cloud service consumer (CSC) focuses on application development and defers the responsibility of infrastructure management including security, scalability, patching, and more to the PaaS vendor. In return for giving up control, the CSC gets agility in the form of speed to market and reduction of IT tasks.

Public Managed – In this model, the PaaS vendor allows the CSC to choose their public cloud provider and for a fee will manage the PaaS and the underlying infrastructure on behalf of the CSC. The trade-offs are similar to those of the Public Hosted model, but the agility is slightly lower because the management of the infrastructure requires coordination with the service provider, whereas in the Public Hosted model, the CSC does not need to coordinate or participate in any infrastructure tasks. An example of Public Managed is a PaaS solution such as WSO2’s Stratos deployed on top of AWS with professional services in place to install and manage the PaaS and application stack.

Public Unmanaged – This model requires the CSC to manage the application stack (operating system, application server, database server, programming language). The public cloud provider manages the underlying infrastructure but the CSC manages the software that runs on the infrastructure, including the PaaS software itself. This is a hybrid between IaaS and PaaS. Systems administrators perform the same duties for a Public Unmanaged PaaS as they would for a Public IaaS solution. Application developers can build applications on top of a development platform but are limited to the infrastructure provided by the IaaS provider. An example of Public Unmanaged is a PaaS solution such as Apprenda deployed on top of AWS but the CSC installs and manages the PaaS and the application stack.

Private Hosted – In this model, the CSC leverages a private cloud vendor with a PaaS offering. Private Hosted means that the cloud service provider (CSP) provides the datacenter and infrastructure, but it is single tenant and dedicated to the CSC. The trade-off here and with all private cloud PaaS offerings is that the CSC has to manage the cloud stack. An example of Private Hosted is an Open Stack IaaS implementation with a PaaS solution like Stackato deployed on a private IaaS provider like Rackspace (note: Rackspace provides both public and private IaaS solutions).

Private Managed – In this model, the PaaS runs on a private cloud but hires a CSP to manage the application stack for them. I rarely, if ever, see this model used in the private cloud. Typically this is mostly done in the public cloud for companies that don’t want to manage infrastructure and application stacks. Most companies choosing a private cloud deployment model do so because they want to control the infrastructure and application stack.

Private Unmanaged – In this model, the CSC wants total control of the data center, infrastructure, and application stack. This greater level of control allows CSCs to dictate what types of servers to use and whether or not to use virtual machines, bare metal machines, or containers. This model gives the CSC the ultimate level of control and flexibility in return for the lowest level of agility and highest level of costs. An example of Private Unmanaged is an OpenStack IaaS implementation with Stackato deployed on the CSC’s own data center.

 

Assessing Tradeoffs

The chart below are my rankings for the six deployment models. The first four columns (Data Center, Physical Infrastructure, Application Stack, and PaaS Software) track whether the CSC manages the resources or not. The last three columns (Control, Agility, Costs) are my rankings of whether the value ranks low or high. Keep in mind that these values are comparing the six deployment models. A low in costs does not mean the solution is inexpensive.  It means out of the six deployment models, it is low in comparison to the others.

Looking at the vendors, their deployment models, and their stacks

Now that we know what the pros and cons are between the six different deployment models, let’s look on some of the vendors that fall into the different categories.

Public Only

• Force.com (Apex) – run on their own infrastructure
• Google (Python, Java, PHP, Go) – run on their own infrastructure
• Microsoft (.Net) – run on their own infrastructure
• dotCloud (php, Node.js, Python, Ruby, Perl) – run on AWS
• Engine Yard (Ruby, Node.js) – run on AWS
• Heroku (Ruby, Java, Clojure, Python, Scala, Node.js) – run on AWS

Public and Private

• Apprenda (.Net)
• WSO2 (Java)
• Stackato (Java, Node.js, Perl, PHP, Python, Ruby)
• AppFog (Java, Ruby, Python, PHP, Javascript, Groovy, Clojure, Scala, Node.js)
• CloudBees (Java, Groovy, Scala, Clojure, Javascript, Node.js, PHP)

Summary

The adoption rates of PaaS in the enterprise were slow prior to 2013. Enterprises are aggressively evaluating PaaS in 2013 as a key differentiator. The challenge is that there are many different deployment models and application stacks supported by numerous vendors. It is important to understand the tradeoffs between agility, control, and costs. Mapping the right PaaS vendor to a company’s requirements is one of many keys to a successful deployment.  Make sure the vendor supports the desired application stack and deployment model.