Revisiting PaaS delivery models


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!

Advertisements

One Response to “Revisiting PaaS delivery models”

  1. What is an application? « Dustin's Blog Says:

    […] Dustin's Blog News and opinions on emerging technologies « Revisiting PaaS delivery models […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: