When a large company loses email and other services the help desk is abuzz with calls. But who do you call when an outsourced vendor goes down? I’ve read a number of reports about the Google outage from a few days ago. Having millions of users without service, or with deprecated service, is a lot of potential calls. Just like tens of thousands in an enterprise is lot when those users cannot access email. In the reports I’ve read people were taking a very strong stance on the outage, not necessarily with Google directly, but identifying cloud support options across the board as having “no one to call.” Really? There’s no way to identify a known outage or call someone?
If you have an outage or a problem with Google Apps then you can get support following the steps outlined on this page. Additionally, if you want to check the Google availability for services (both in historical and current contexts) then you can check the google.com/appstatus site. Google also went insofar as to publish a disruption/incident report on the severity and the issues that caused the outage. I love transparency.
IT environments have outages. Google outages, and outages for any cloud-style environment are typically more rare than most organizations I see in production. There is a support line to call and there is also a status page to check, fairly in-line with what you would have for application support for most enterprise organizations. But what gets me is that many of the people writing columns voicing outrage about the outages with Google are the very ones who also write columns about the death of corporate IT and the emergence of the consumerized IT paradigm.
The cloud is not for everyone, but having the option of cloud-based services is a great thing. It’s not right for everyone. However, if you choose to go the route of initiating a large migration towards a cloud-based delivery model for applications then one aspect of keeping that cost at a minimum should be to educate the end users on who to call when it goes down (because at the end of the day, everything goes down every now and then). If it’s a Mac OS X environment maybe you build everyone a widget that displays the availability page or a mash-up of multiple availability pages from vendors on a per-application basis. This would save a lot of wasted time for the service desk (although some users will still call there first).
Overall, there is no substituting an internal solution with one that is cloud-based; this includes both the good and the bad aspects. Internal servers take more resources to manage, there’s always the potential for infighting with the administrator of the application stack that resides on a server and of course, you need to buy the gear that the solution lives on. However, when you outsource that server, which is at the end of the day what you are doing when you employ a SaaS solution, then you end up with diluted ownership, powerlessness when the solution is unavailable, increased bandwidth utilization, feature lock and other negative impacts. There are a lot of arguments to both ends that can be made with regards to moving into any outsourced solution. But complaining about not being able to call a service desk without bothering to check availability nor what the contact information would be for said service desk is ludicrous. If you don’t know how to contact the SaaS vendor then it is more than likely the fault of our organization for not doing the due diligence to document the support scheme ahead of time (or said another way, did you really think Google would never go down, ’cause saying something like that makes ya’ look like a n00b).