For decades on-premise ISVs have successfully hid behind abstraction. It was, and continues to be, an excellent way to manage technology doubt and implementation differences. SaaS ISVs have nowhere to hide. Building reliable SaaS applications from non-reliable services demands a fault-tolerant approach. Abstraction just doesn’t cut it any more.

Whether using frameworks, cross-platform toolkits or even application generators, abstraction has worked well for the different combinations of OS, database, networking and user interfaces that confront on-premise developers.

As an SaaS ISV you only have one platform–what technology doubts could you possibly have to worry about?

For SaaS it’s services, all the way down…

SaaS applications are large portfolios of services that extend over the complete hardware and software stacks, including:

• Utility computing services for hardware, data storage and networking
• Common system features, such as billing, subscription management, analytics and service management
• Common application features, including charting, mapping, search and many others

Your customers do not count your technology as a benefit to them. They will not accept premium pricing. As a result, you will only ever have time and money to invest in building services that are core features for your vertical niche.

It makes financial sense to buy-in most of your services; keeping your running costs strictly under control. Your service portfolio can, and should, change in the future as you look for opportunities to swap to something cheaper.

As an SaaS ISV you now have total independence to choose the services you need for your application–where are the technical doubt and implementation differences you need to hide with abstraction?

My service was there a minute ago!

Technical doubt for on-premise products could usually by fully resolved at build-time. Once the customer had installed the product the IT setup changed slowly, if at all.

When a 3rd party supplier disappeared, or dropped support for their product, there was no short or medium term impact on any of the installed applications. These continued to run as before–often for many years. There was enough time to consider replacements (and you abstracted the interfaces anyway).

The services world of SaaS is different–the services you carefully selected can (and will) disappear at run-time! This could simply be from a temporary network outage. More seriously, a provider might close and stop offering their (probably in perpetual-beta) service with little or no warning.

Service outages can impact all of your SaaS customers–and quickly. The buffer that exists in the on-premise world between off-line development and build, and on-line deployment has disappeared.

If a service is unavailable you need to have a plan B in place. You cannot wait and develop a replacement solution in days, weeks or perhaps even months. Your customers have already noticed and they are waiting…

Without your having had any choice in the matter, SaaS throws you head first into the real-time world. You have to build a reliable SaaS application based on a large portfolio of (assumed to be) unreliable services. This is not easy.

Fault tolerance–here comes SaaS, ready or not

You SaaS application must degrade gracefully as services come and go. No matter what happens, you must always deliver the best possible customer experience. How it degrades depends on the missing service or services. An unavailable charting or mapping service clearly has a different impact than a missing database or networking service.

Your SaaS application must handle missing and unavailable services well, and tell your customers what is going on. It cannot just fail because a service is unavailable–even if it is something critical such as your login or security service.

All SaaS outages have an all-too real potential to blow up into a PR disaster. Bad press is not healthy for your reputation or keeping customer trust–both of which are essential for success in the SaaS market.

This time your main technical doubt is not the easy API differences between implementations–the main issue is the concern that any of your chosen services will actually be available from one transaction to the next.

Hiding behind abstraction will not work. You need a more flexible approach that handles unreliable services and guarantees an excellent user experience–no matter what service fails or disappears.

Coming up…

Are you forced to develop this supporting service infrastructure yourself, or are there standard solutions you can use? That is what I will look at in my next post on paasTalk: Could the Amazon EC2 cloud computing platform squeeze the profits from SaaS applications?.