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.

PaaS: The Many Faces

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.

PaaS: The Many Faces 2

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.

Share this Article:

Share Button
Mike Kavis (42 Posts)

Mike is a VP/Principal Architect for Cloud Technology Partners. Mike has served in numerous technical roles such as CTO, Chief Architect, and VP positions with over 25 years of experience in software development and architecture. A pioneer in cloud computing, Mike led a team that built the world's first high speed transaction network in Amazon's public cloud and won the 2010 AWS Global Startup Challenge. An expert in cloud security, Mike is currently writing a book for Wiley Publishing called "Architecting the Cloud: Design Decisions for Cloud Computing Service Models (IaaS, PaaS, SaaS)" which is expected to be released in late 2013.

Connect with Mike Kavis:


Related Posts:

5 comments for “The Many Faces of PaaS

  1. July 5, 2013 at 12:23 PM

    Useful article Mike. I spent a lot of time evaluating Oracle’s “On Demand” option for their e-business suite; I could never quite figure out which category it fitted into. Through the high level Oracle marketing literature all appeared like it was a big elastic resource that could easily expand with the needs of your business, but after visiting them that utopia seemed a bit further from the truth.

    As a large customer, to host eBusiness itself, you’d be effectively renting dedicated servers for which you’d need to release all your current platform (database and application licenses) and “some more”.

    Disk space charging can become an issue for organisations with high volumes of data and if you’ve got numerous test instances, it will cost considerably to migrate the lot to their PAAS offering. You could consider doing without, but then you’ll need to rethink all current testing and release strategies with the end users.

    Furthermore, if you’ve got lots of 3rd party ancillary applications (we had invoice scanning and a few reporting tools) it will also cost you to have them hosted, Oracle aren’t keen on them but often it’s a necessity if they want to run PAAS for you as many of these application exist very closely with eBusiness suite. So getting support access for 3rd party software suppliers can be a big problem.

    There really is a lot to figure out and many questions to ask which is why I think that it needs to be both a business and technical decision before you take the plunge from on-site to PAAS.

Leave a Reply

Your email address will not be published. Required fields are marked *


6 × two =