A bewildering choice confronts ISVs pondering which platform to use as they start to roll out SaaS offerings to respond to growing market demand for cloud offerings. Here are some pointers to help make that choice.
Cloud applications are increasingly becoming a mainstream choice for businesses, and that means a lot of ISVs are pondering which platform to use as they begin to roll out SaaS offerings to respond to that market demand. Unfortunately, the choice that confronts them is bewildering, with any number of established and start-up vendors and providers touting everything from conventional software platforms to managed hosting to platform-as-a-service. It should come as no surprise therefore to find that the opening morning of next week's SIIA OnDemand Europe 2010 conference in London has not one but two sessions on this topic — and I'm moderating both of them (see disclosure).
This is a topic I've given a lot of thought to over the past couple of years, arriving at a framework for evaluating cloud platforms that consists of four components, as set out most recently in my post Defining the true meaning of cloud. You can hear my advice on how developers can use this framework in the video below, which I recorded earlier this year while attending the SIIA All About Cloud conference in San Francisco.
There's also a diagram I use to illustrate the framework, reproduced here, which first appeared in a posting back in January, when I wrote: "Where cloud platforms differ crucially from conventional software platforms is that their native capabilities have to extend into three additional, distinct elements beyond the core functional scope. This is mapped out in the diagram alongside."
On the horizontal axis, the breadth of infrastructure extends beyond the traditional development functionality of conventional platforms to embrace the entirely new element of service delivery capabilities, which are a crucial element of any SaaS or cloud offering. Of course some ISVs may feel they'd prefer to build or select these capabilities themselves rather than being tied into a platform provider's predetermined offerings. But whatever they do, they shouldn't underestimate the complexity of the requirement.
Then, on the vertical axis, there's the concept of platform bandwidth, which embraces the notions of multi-tenancy and all the attributes of a collectively shared operational platform, along with the notion of cloud reach or cloud scale. These platform bandwidth components I've discussed in my recent posting on the true meaning of cloud, so I won't reiterate that here apart from repeating my conclusion:
"A computing architecture can have all the other attributes of cloud, but without this cloud scale dimension, it will not be able to keep pace with the operational demands, the overwhelming connectivity and the continuous rapid evolution of the cloud environment."
The problem for ISVS is determining where exactly on that four-way matrix do they want their offering to sit. It may be premature to deliver a fully cloud-scale offering on day 1 (it may take too long to build it, for example). On the other hand, if they simply host their existing software on an Amazon EC2 or a Microsoft Azure instance, they'll have something in the market rapidly, but as a single-tenant implementation it'll have very limited platform bandwidth and poor as-a-service infrastructure (remember that, while the underlying infrastructure is multi-tenant and delivered as-a-service, your application doesn't have any of those features if you don't build them in). The ramifications of decisions like these will be much in our minds as we discuss the topic of cloud platform choice next week.
What questions would you like to put to the platform providers speaking at next week's conference? Post them to Talkback.