Back in the day, we used to fight for five-nine availability. This meant that you would have access to the product or service 99.999% of the time. (If you’ve not read Wikipedia’s article on the Myth of the Nines, now’s your chance.) Mathematically, this equates to only having 5.26 minutes of downtime a year. Pretty impressive, when you consider how long it takes the average computer to simply reboot.
We would tie the availability requirement to a penalty (aka “financial incentive”). This is a kissing cousin to service and support response/repair times and similar penalties… and it heavily applies to situations where you need steady and consistent access to a particular product.
For ASP/SaaS products, uptime is extremely important, as it not only defines the amount of time you have access to use the product but also is a measure of the service provider’s value/responsibility (you don’t have access to the product to fix it yourself). Until recently, though, network bandwidth wasn’t really available to sustain the offerings and was the scapegoat for much of the argument to reduce or eliminate uptime requirements, even if it was the vendor’s back-end server performance causing the problem(s).
As a result, compromises were made to allow uptime calculations only based on daytime work hours (so downtime at night wouldn’t be counted) for those businesses which didn’t have 24/7 operations. Compromises were also made to allow vendors the ability to challenge a request for credits based on downtime. Of course, compromises are fine so long as you’re not compromising your business model.
Flash-forward almost a decade. Gigoam commented recently about the fact that the current movement towards more cloud-based computing is going to require more attention towards availability. I agree. And I’m a little disappointed that I haven’t yet seen a likewise return of significant uptime commitments.
The bandwidth is here (to understand the difference between then and now, check out this table and compare 10Base-T versus Gigabit Ethernet, almost a 1000x speed difference) and applications are designed to be a little more efficient, too. The result is a resurgence of ASP/SaaS products. There are several that I love, actually. They’re incredibly good products, with good support and they don’t typically have downtime problems. But I’m not seeing uptime guarantees of any significant amount.
To get decent uptime availability commitments from your providers, you need to be in-the-know regarding your own proposed usage and the product offering: Know what the service’s value is to your organization. Know when it must be available and when it can be down. Know about server-loads and peak-usage periods. Know the difference between hot/warm/cold backups and have an understanding of what failover might require.
99.999% availability might never be offered again… but something should be. Make sure you’re asking for an uptime guaranty from your providers. Never forget that the middle name of ASP and the last name of SaaS is service.