The fact that SaaS vendors can offer innovative, cool new services that are easy to start using and easy to operate is a given ... nobody would argue with that.
But can an enterprise trust these offerings yet?
As Larry Dignan notes in a post about Coupa's e-procurement offering, which is going to market on top of Amazon's EC2 and S3, enterprise expectations are typically "five 9s" ... that is, uptime of 99.999%.
What are Coupa's chances of achieving five-nines as they stand now?
As I noted yesterday, I am really happy to see that Amazon is breaking the ice by offering an SLA for S3, their cloud storage offering. There are many questions about the quality of the SLA, but at least it's a start.
What Are the Chances?
With that in mind, let's look back at Coupa. For Coupa to work for a customer
- S3 must be up AND
- EC2 must be up AND
- the network access to EC2 and S3 must be up AND
- the user's network and ISP must be up AND
- Coupa's code must be working.
So in case you're keeping score, that's at least FIVE SERVICES THAT MUST BE WORKING for Coupa to work ... any of them fail and *poof*, it's nap-time. The only thing in this chain with an SLA is the storage (S3), and it's SLA is only ok.
Suppose that Coupa depends on other services as well to actually perform the e-procurement function (it definitely does, btw ... that's part of the main point)? Well then, the chances that it's all working go down even more.
What Does This Mean?
I think this has three practical ramifications.
First of all, folks that are looking for easy to implement, easy to operate functionality (the SMB target market for offerings like Coupa) will use the offerings as-is, and simply put up with the outages. And yes, that has worked for salesforce.com so far.
However, over time the drive towards higher SLAs (both marketing-commitment SLAs and actually-delivered SLAs) will be relentless.
So the second consequence will be that the raw-ingredient services, such as cloud computing and cloud storage, will begin to offer SLAs, and over time back up those SLAs with delivered reliability.
The Most Important Consequence
The third, and probably most important consequence, is that the service offerings themselves must engineer their applications to ensure their own reliability, scalability, and operational integrity. The traditional approach to doing this leads to the development complexity that plagues our industry like especially-vigorous kudzu in the deep south of the US - frustrating, hard to combat, and just gets in the way of anything productive.
That is precisely where fabric offerings like our EAF come in. EAF assumes that everything below the application will let you down, and simply protects against that automatically. So whether a service offering is hosted in-house or hosted in a cloud, the service itself will ensure that it is available and works as expected.
Simple.
Technorati Tags: application fabric, availability, commoditization, reliability, SaaS, web 2.0
Post new comment