Over-reaction and Valuable Lessons from the Gmail Fail
There was a lot written in the past few days about the service interruptions with Gmail, so let me add my two cents. In my mind there was a significant over-reaction to the Gmail Fail, mostly by people who for some reason or another are anti-SaaS or anti-Cloud. I wish someone would do some sort of psychological analysis of that crowd (are they contrarians, do they fear the impact to their own jobs, uniformed), but that’s not going to be the topic of this post. While many people made like Chicken Little, I think that most drew the wrong conclusions. I look at it like this:
- Gmail isn’t just personal mail: It highlighted how many people are using Gmail for what they consider business-level communication, not just personal email. With some what I’ve seen regarding Google Wave, this could be a very interesting development and something I’m sure the folks in Redmond are concerned about.
- There is Value in ‘Commercial-Grade’ Release Processes: There is a flawed theory used in much of the online application world which believes that being in perpetual beta is OK. It’s not. I understand the desire to get new products and features out to market right away, but letting your users be your testing team — unless it’s a structured beta — is not the right thing to do. Software companies need to test their products appropriately before releasing it to clients. There is value to a ‘commercial-grade’ release process. And it’s not like a structured release process means slow time to market. Agile development methods support rapid releases and are pretty mainstream these days. Speed does not excuse sloppiness.
- SaaS and the Cloud Require a Systems Engineering Perspective. Architecture and application design – not just testing – for performance, scalability, reliability and availability is critical. And note that people always talk about PSR testing, not the “A” for availability, which in and of itself is a big miss in thinking about designing and developing systems that are meant to be used by large user communities in unpredictable ways. But it runs deeper than that. SaaS requires a systems engineering perspective. It’s not just the software that gets developed it’s how we think about how that software interacts with the underlying infrastructure and how together they deal with internal and external threats — security vulnerabilities, natural disasters, disaster recovery, etc.
Lastly, some of the people I discussed this with have argued that SaaS or Cloud is a good backup to traditional software systems. It’s not. SaaS is a choice…and an alternative to other on-premise software. But you don’t choose an Email or CRM or ERP system as a backup to a separate primary system. Of all the issues around SaaS, integration is perhaps the biggest. So who’s going to take on all those headaches for a something they plan to never use? Nobody.

No comments yet.