Skip to main content

ISVs will always take the blame for SaaS platform downtime

ISVs must isolate their applications from today’s SaaS platforms to benefit from the improved SaaS platforms expected in the future.

Like disk drives, SaaS platforms are subject to unexpected failures

Data storage is very reliable, but still has unexpected and catastrophic failures. That is why you backup your data. You must plan for when things go wrong. It will almost certainly not go wrong in the way you expected, but it will go wrong—sooner or later.

I have seen my fair share of data disasters over the years so I use a variety of media and archive cycles for local backups. For offsite backups I use Jungle Disk. Jungle Disk is a remote storage solution built on the Amazon Simple Storage Service (S3) for data storage and the Amazon Elastic Compute Cloud (EC2) for block-level file updates and other services.

As a “production” user of Amazon Web Services, I follow with interest the increasing acceptance in using Amazon’s S3/EC2 as a SaaS platform. It now seems to be the default assumption that Web 2.0 startups will use Amazon’s platform from day 1 to save a lot of money. Of course, they are also happy to leverage Amazon’s reputation: “If it’s good enough for amazon.com then it is good enough for our users...”

This is all well and good—until the SaaS platform fails—and it will—and then it’s your fault!

If you cannot provide your application services to your customers then it is always your fault! It will not matter what unusual and totally unexpected event has struck your SaaS platform provider.

If your customers cannot get at their data then it is your fault. The trust relationship you have invested a lot to build with your customer will be damaged. It is you that is going to suffer the consequences, not your SaaS platform provider.

Choosing the right SaaS platform

It goes without saying that it makes absolutely no sense for you to try to build and run your own SaaS-capable data center. You must depend on one or more external suppliers for your SaaS platform.

To gain the trust of your customers, the level of service you commit to your customers will be higher than that offered to you by your SaaS platform provider.

This “SaaS Trust Gap” between what you must offer your customers—and what your SaaS platform provider offers you—is one of the major risks you must manage to survive and profit from the shift to SaaS.

The right choice of SaaS platform provider is therefore critical to your success.

SaaS platforms will always be unreliable

As the market for SaaS platforms develops they will become increasingly reliable. However, they can never be 100% reliable. For the short term probably. In the medium term probably. But in the long term, no. There are just too many things that can (and will) go wrong.

Assume for the moment that your SaaS platform is unreliable. How can you still provide a higher level of service to your customers than that provided to you by your SaaS platform provider?

The basic concept is the same as you are using today with storage arrays. Simply assume your SaaS platform is unreliable and architect your SaaS infrastructure around this fact of life.

My provider guarantees 100% uptime...

At this point you might object that your provider commits to 100% uptime. They have redundant power supplies, redundant Internet connections, fail over this and that.

While 100% uptime might be their stated goal, even the leading tier 1 data centers have major outages. Even Amazon’s widely-used S3 has not been immune to occasional downtime and claims of lost data.

Even if your deployment platform provider really was 100% available, that does not always help your customers. There are a lot of “moving parts” between your SaaS platform and your customers desktops. You will never be able to guarantee100% end-to-end uptime.

So, what do you do?

Standardized SaaS platforms?

In the ideal word there would be a standard for SaaS platforms and a range of suppliers competing on price and availability. You could then develop and manage your applications independent of the underlying deployment platform provider.

This ideal world would make it easier to move from one SaaS platform provider to another in order to improve service to your customers, and to reduce your risks as SaaS platform providers gradually catch up with the commitments you are already making to your customers.

The current market for SaaS platforms is too immature, however, for such a standard to have emerged. And, based on past experience, it is pretty unlikely that anything will happen anytime soon.

We are still at the stage of proprietary platforms, each with their own proprietary interfaces and architectures. We have the well-known players such as Amazon, IBM, Microsoft, Oracle, Salesforce.com etc, plus OpSource, SaaSGrid, FlexiScale and a range of smaller players.

I think the solution to this problem of depending on proprietary SaaS platforms is essentially the same one you have successfully applied to a whole range of technical problems in the past: abstraction.

Abstracting the SaaS platform

In the same way that you developed a “database abstraction layer” or a “platform abstraction layer”, you should consider adding a “SaaS deployment platform abstraction layer” to your application architecture.

There are already some SaaS platform technologies coming to market which are clearly moving in this direction.

Take the Amazon EC2 platform as an example. The Amazon EC2 architecture makes it possible to manage and run instances in a flexible, reliable and cost effective manner. However, the way in which you need to interact with the Amazon EC2 “management system” is fairly complex and proprietary.

To address this problem SaaS platform vendors such as RightScale and CloudScale are developing technology that abstracts away the details of the Amazon EC2 platform.

While the current focus is on making it easier to use EC2, the same approach can be extended to make your SaaS applications independent of the underlying SaaS deployment platform.

Leveraging the future

The market is driving towards “Cloud Computing” and “Utility Computing”, but those clouds and utilities will never be 100% reliable. An often-used analogy compares cloud computing to the electrical grid. We need to bear in mind, however, that more than 100 years later we still have blackouts from time to time!

A competitive market for SaaS platforms will emerge, but to benefit you will need to:

  • Treat your SaaS platform as just another piece of technology to be abstracted away.
  • Always bear in mind that your current SaaS platform will almost certainly not be your future platform.
  • Protect yourself against being locked in to your current SaaS platform provider.

Thank you for reading ISV Survival. You can get the next post hot off the press by RSS or by email.

No trackbacks yet

TrackBack URL for this article: http://isvsurvival.com/trackback/38/

2 comments

Join the conversation on article “ISVs will always take the blame for SaaS platform downtime”.

Hi Andrew, Good article. I agree with your thoughts. That is…

#1

Suman Chaudhuri

January 31st 2008
23:04 GMT

Hi Andrew,

Good article. I agree with your thoughts. That is why ISVs that are planning to adopt SaaS due to customer pressures need to think of SaaS as a multi-dimentional approach that tackles:

- technology
- business
- marketing
- operational
- cultural

All these aspects are equally important to a successful SaaS strategy. You can read my thoughts on this at:

http://sumanchaudhuri.wordpress.com/2008/01/30/multi-facets-of-the-multi-tenant-architecture/

Hi Suman, Thanks for your comment. I agree with the points that…

#2

Andrew Biss

February 4th 2008
14:23 GMT

Hi Suman,

Thanks for your comment.

I agree with the points that you make in your post.

What makes the switch to SaaS so disruptive for ISVs is the impact on everything the ISV has done in the past.

One of the main reasons users like SaaS is that they do not have the hassle of building and maintaining their own IT setup. With SaaS the burden clearly shifts to the ISV, who now also has to write the software and keep it up and running.

Multi-tenancy is a method ISVs can use to reduce their costs. The users, however, do not care! As long as they can get the software service at a fair price, it works and can be used when they need it, then they are happy…

The technical features and benefits we are used to talking about when selling business application software go away. In the past we often found someone in the user’s own IT group who cared about the bits and bytes. With SaaS this (rightly) drops away.

Users do not care about technical details of how the software is implemented. That is a concern for the ISV, not for them. This is good. It is a positive sign of the IT business maturing.

SaaS will drive this maturity even faster, as the emphasis rightly moves away from “software” and towards “service”, where it belongs.

Your comments

To join the conversation please enter your comments below. To help you check that the formatting of your comment is OK a live preview is shown right below the comment form. The preview is updated as you enter or change your comment. In the interest of all our readers we reserve the right to delete any comments that include spam, profanity, personal attacks or any other inappropriate material.


Please Add Your Comments:

You can use these HTML tags in your comments: <b>, <i>, <u>, <em>, <strike>, <strong>, <pre>, <code>, <blockquote>. Other HTML tags will be converted into HTML character entities and will not be processed. Text blocks with double line breaks will be turned into paragraphs. Line breaks will be replaced by <br /> tags. Special characters will be formatted as HTML character entities. Links, email address and images will be displayed as text and not processed or automatically linked.

Your name (not the name of your company).

(Optional)

The URL of your website or blog. If you enter a URL this will be linked from your name when your comment is displayed.

Your email address. We promise that your email address will never be displayed, distributed or used for any purpose other than related to checking for comment spam.

This will write a cookie to remember your name, email address and URL so that you do not have to enter this information again when you add your comments in the future. You can delete the cookie at any time.

This will send you an email with details of each follow-up comment added for this article. Each email contains an excerpt of the comment and a link to the complete comment. At the bottom of each email is a link which you can click to stop receiving notifications of new comments for this article.

Global sidebar

Latest articles