Personal Blog (scroll down)
You’re SaaS Dependent and the Internet Goes Down
You’re SaaS Dependent and the Internet Goes Down

You’re SaaS Dependent and the Internet Goes Down

A common starting point

The internet’s ubiquitous nature has made possible so much. If it were not for the internet (like the utilitarian ‘phone,’ it’s time to stop capitalizing ‘internet’) the notion of Software as a Service (SaaS) wouldn’t even exist. Yet while incredibly empowering, the internet can be incredibly devastating when it fails.

Saying, ‘…the internet is down…’ is often akin to using the ever popular, ‘they.’ From a user perspective, the internet being down often simply means a transaction between Point A and Point B is failing. It does little to identify whether the failure is at A or B, or somewhere in-between.

As the consumer of SaaS, you need to consciously plan for service disruptions. Can you protect yourself if the failure occurs locally, or at the service provider’s end? What about outages of various durations?

Wikipedia and other sources will describe SaaS as effectively being ‘rented software,’ either thick or thin client (e.g. web-based or locally installed). Others, such as The Connect Web’s Phil Wainewright more correctly (in my experience) view SaaS as primarily web-hosted, commenting, “SaaS vendors, of course, spare their customers the burden of installing the software at all…” In its most popular delivery model, Software as a Service assumes a near-zero size client-side foot print relying on nothing more than a web browser for access to the service.

The preceding comment is important. In my experience, most SaaS consumers are using browser-based client access to their service. This means there’s also a near-zero ability to work in an ‘off line’ mode should connectivity to the SaaS provider be lost. The options are often pretty simple: Sit on your hands and wait, or, send staff home for the day. In most cases the latter extreme is very rare, but it does happen.

Protecting yourself

How you protect yourself against SaaS service disruption largely depends on two things: your operating budget, and, service provider selection. Your budget not only dictates how you design your environment, but also nature of the Service Level Agreement (SLA) agreed to by your service provider (see my article on choosing a vendor).

The SLA can describe everything from penalties due to service failures they are responsible for. It can also specifically identify the level/type of redundancy they have, how often backups are done, and responses to catastrophic failures.

An example may include requiring the vendor to: at all times maintain 2 internet connections, neither exceeding 50% capacity; maintain a remote data center they will seamlessly switch over to in the event of a failure, switching over after ‘X’ period of time; and minor details like average browser page render times (e.g. 1-10 seconds). The more you demand, the higher the cost, hence the tie to your budget.

Focusing on your end

Successful SaaS delivery is subject to the notion of the weakest link. Your service provider may have excellent redundancies but if your sole link is a dial-up connection (yep, even these days), you have a good idea where the weakest link may lie.

The level of sophistication you employ is going to be budget and priority driven. If the service is non-core and delays can be tolerated, little or no redundancy might be necessary. Odds are, you’re relying on the service you’re paying for, so, here are some details worth considering:

  • Multiple internet connections
    Have alternate connections through different providers (e.g. AT&T/Sprint/Comcast/etc). Helpful if a major national backbone goes down. Helpful too in event of billing snafus and one wants to (sometimes mistakenly) shut you off.
  • Multiple points of entry to your building(s)
    Have one connection enter the back of your building(s), another from the front. Even the Fortune 100 forget this occasionally and have entire facilities shutdown because of ‘Bob, and his backhoe,’ or the tractor-trailer that was higher than the cable across the parking lot.
  • Manage network bandwidth
    Never let your available bandwidth become saturated. Buy more bandwidth if you start to exceed “pick your %” utilization. Check your actual consumption regularly (hint: annually, at contract renewal, isn’t sufficient).
  • Negotiate with your carriers to accommodate bandwidth spikes, peak hour surges, and similar
  • Create contingencies
    • What will you do if your connection(s) fail?
      When does it become an issue? In certain high-demand applications a 2 minute disruption can be killer at the right time (e.g. end of month/quarter reporting for 20,000 dealers).
    • What happens if there’s a failure for 2 hours, 2 weeks, 2 months (think truck hitting telephone pole; mudslides; regional power outages; Katrina).
    • When is it time to send staff home for that shift, for that day?
  • Practice the Five Whys. Though you might substitute ‘what’ for ‘why’ in this case. For instance, start with why might my SaaS service fail? Why would my internet connection fail? What are my options? What don’t I have answers for? What keeps me (IT/Ops Mgr) awake at night?

You can have tremendous luck making use of SaaS offerings. But how well your luck holds ;) depends on the ground work you’ve already done.

%d bloggers like this: