Quite some time back, I explored the idea of different delivery models for PaaS solutions. To sum it up concisely, I believe that PaaS providers have to make a decision when they deliver their solution. They have to decide the degree to which their solution supplies inherent knowledge of a set of platforms versus the flexibility that solution delivers. With that in mind, I proposed that we can generally characterize PaaS solutions in the following way:

1) Platform and service depth with little breadth

2) Platform and service breadth with little depth

3) Platform and service depth with breadth

When examining option one or option two, many consumers will feel that they are making a compromise, and not without reason. Option one delivers a PaaS solution that provides significant inherent knowledge about a particular platform or group of platforms at the expense of being well-rounded. This means that users can setup some cloud platforms very easily and with little effort, but they cannot address all of the platforms necessary in their organization. Option two is just the opposite. It does not supply much platform specific knowledge at all, but rather it is flexible enough to address a large swathe of runtimes. Of course, this means users end up being the supplier of the platform specific knowledge, so adoption and implementation typically take significantly longer.

Given all of this, in my original post I was of the opinion that option three is the most appealing. I still believe that today. PaaS solutions are plenty disruptive on the cultural front, so minimizing technical hurdles can go a long way towards spurring on adoption. If users can get a PaaS solution that lets them address a significant subset of their organization's platforms with minimal technical work, coupled with the ability to address other platforms with some customization work, I think they will naturally gravitate that way.

Unfortunately, the reality is that delivering such a solution is not an easy thing to do. From a provider standpoint, it is easy to fall into a trap whereby you unwittingly build a solution rooted in the context of just a select few platforms. This could surface itself in management interfaces, deployment models, and user interface terminology just to name a few places. Many times this happens when you build the PaaS solution to address a specific subset of platforms, and then work backwards to make it an open system. This just does not work. As a provider, you have to build the open platform, and then provide the content necessary that customizes the system for the subset of platforms you choose.

This is where I really think IBM Workload Deployer gets it right. From day one, the subsystem that deals with virtual application patterns has been based on an open architecture. Every virtual application pattern is a collection of one or more plugins that provide the knowledge of how to install, deploy, and manage application environments in a cloud. IBM provides virtual application patterns (built on provided plugins) right out of the box for a selected set of runtime environments. Users can create virtual application patterns for other platforms they want to deploy and manage using IBM Workload Deployer by contributing the foundational elements -- plugins.

The ability to create and load custom plugins into IBM Workload Deployer has been a feature of the solution since its announcement earlier in the year. So, why am I just bringing this up? Well, last week IBM published the IBM Workload Plugin Development Kit that provides tooling and documentation that guide users through the plugin creation process. The tools and guidance included in this kit provide the framework within which users will be able to create any kind of plugin to support any type of virtual application pattern they want to create. This kind of tooling makes it feasible to have a PaaS solution that provides both depth (via the patterns and plugins provided by IBM) and depth (via the patterns and plugins provided by users).

My advice to you is that regardless of the solution(s) you are looking at, challenge your cloud providers in terms of the value they deliver and the flexibility they enable. Look for those that give you out-of-the-box value without handcuffing you to a particular set of platforms. Time to value does not have to come at the complete expense of flexibility!

• App-DNA Optimises Citrix Application Delivery Models
• Reportlinker Adds The Future of Software Delivery: The opportunities and challenges of emerging software delivery models Report
• IBM Calls on Healthcare Providers to Forge New Delivery Models That Redefine Value and Engage Consumers
• PaaS Deployment Models