Like Gartner’s Eric Knipp said this week, “Large enterprises are very interested in the PaaS value proposition,” and he goes on to highlight a number of reasons for resistance of public PaaS implementation. Public or private, we all agree that many clouds, hybrid or otherwise, will exist; the roots of these clouds should sit on a next gen platform built to be enterprise grade.

If it isn’t immediately obvious, gross confusion exists in the PaaS space, especially for the enterprise buyer. As a means to provide clarity, and clearly categorize the vendor landscape, we’ve developed the “State of PaaS Analysis” for your education benefit.

As you can see from the diagram below, this is not based on identifying a “leader” in the space. It points to the critical elements that enterprises consider when evaluating PaaS – both public and private – and what platforms can handle certain workloads and runtimes.

Like any major shift in a next gen platform, PaaS will come in all forms. The result is the following categorization of the PaaS landscape today, and below is the descriptions of what this chart means and why it’s valuable to review enterprise PaaS in this manner.

Confusion in the PaaS market is due to vendors not clearly articulating what they do, who they service and enterprise buyers not having a clear set of guidelines to properly evaluate PaaS. Add to this that, every so often, some new vendor claims to have a “PaaS” and that they focus on the “enterprise,” when neither is true. This is to be expected, given the popularity of the space and the increasing interest from enterprise buyers. In order for a space to mature, however, some of the ambiguity needs to be resolved.

Ultimately, any false “enterprise PaaS” categorization only harms the customer, and results in a diluted exit for the startup. On the contrary, large PaaS vendors that emerge without clarity, but will try to keep a steady footing in existing enterprise accounts, will only be able to skim the surface in innovation and functions that enterprises need NOW.

Here is how we defined a set of attributes that can be used to size-up different types of PaaS. A quick survey of the field shows three types of PaaS:

1. Web/Hobbyist – This is the most common (and most traditional form) of PaaS. These PaaS’ do little sophisticated work beyond automating the deployment of applications and stacks, coupled with updates to infrastructure updates such as load balancers. They tend to focus on websites and basic hobbyist apps; think 2-tier and sometimes 3-tier applications with little dependency or call path complexity. PaaS’ like AppFog and the original Heroku fit well in this bucket.
2. Ecosystem – This category is representative of “PaaS” that generally extend SaaS offerings and may or may not have a custom languages and runtimes. They exist to help SaaS offerings introduce extensions and customizations through an ecosystem model in the hopes of driving additional value beyond the core offering. An example of this is Force.com. In my opinion, this is a much looser definition of PaaS and is more representative of a cloud plug-in system.
3. Enterprise – A newer version of PaaS is one focused on enterprise. Enterprise PaaS’ tend to afford more flexibility by allowing for more sophisticated application architectures that can be a blend of modern and legacy components (e.g. a REST based service leveraging a NoSQL store while working with a batch processing daemon that talks to some old COBOL-based system). An enterprise PaaS also tends to integrate with various technologies that are enterprise IT mainstays, such as federating traditional identity systems for authentication, etc. An example of this is Apprenda (insert shameless self-promotion).

Each of these PaaS categories are defined by 6 key qualities:

1. Form Factor (FF) – Is the PaaS in a fixed location (as a public cloud service such as Engine Yard), or is it a “portable” software package that can be layered on top of any –infrastructure (e.g. Apprenda, CloudFoundry)
2. Accessibility (Access) – Is the PaaS public cloud only, private cloud only, or support both (not hybrid, but instead accessible as both a public PaaS and a private PaaS).
3. Deployment Format (DF) – Determines whether PaaS is deployed as public only, can it be deployed as private, or can it straddle resources from both private and public to create a hybrid PaaS. This is different than “Accessibility.” For example, if an enterprise deploys a PaaS software layer on Amazon’s EC2, but uses it as a dedicated instance for themselves, than they have private Accessibility running with a Public Deployment Format.
4. Infrastructure Platform (IP) – Defines what sort of infrastructure the PaaS runs on/can run on. This can be either 2.0 Infrastructure (think cloud AWS), existing IT infrastructure (think commodity x86 metal potentially running a traditional hypervisor like Hyper-V or VMware), or it supports both.
5. Workload Type (WT) – Defines whether the PaaS is built for Business Critical workloads (e.g. transactional systems that may be responsible for generating revenue) or Functional workloads (e.g. an application that might do less sensitive work that doesn’t affect the bottom line, such as an engine for managing brand loyalty through a rewards program)
6. Runtime – Determines what runtimes the given PaaS category is expected to excel at for maximizing value.

Plotting these six qualities against our three PaaS Categories gives us a framework to define requirements based on the constraints of each category:

Need an enterprise PaaS?

It’s likely the case that whatever technology you choose needs to satisfy these basic requirements to be considered a viable option. Anything less won’t satisfy the requirements, and anything more will be using a Howitzer to go pheasant hunting (imagine, for example, deploying an enterprise grade PaaS for building a salesforce.com widget).

What we’ve found in practice is that two criteria have a tremendous impact on the applicability of a PaaS in the enterprise: a PaaS’ deployment format and the workload types it supports (zooming in on complexity of application architectures). If we plot vendors against these two dimensions, we arrive at a landscape that looks like the first diagram in this post.

Clearly, non-enterprise use cases are better served by appropriate models. Like Gartner said, private PaaS, like anything else, should be governed by the “right tool for the job” mentality. If you’re an enterprise considering private PaaS, understanding these high level criteria and landscapes will help in your assessment of the space.