Image via CrunchBase
This is the sixth post in the SaaS Risk Reduction Series. For a change, I am planning to highlight a problem faced by one of the SaaS customers and explain how it could be done differently based on my suggestions in this series. Zoli gave me a link to one of the threads in Joel on Software Forum. In the thread, a frustrated SaaS user described his/her ordeal with Google Apps for Domains Free edition. Let me quote his story here.
I started using the free version Google Apps a little over a year ago for one of our intranets. Luckily it was an intranet and not the main site! I guess it wasn't entirely luck. Management would never have let us use it on the main site. Anway, we used the shared calendar, email for a certain group, Google docs and a few other things.
For the most part things worked well. A few weeks ago it was time to renew the domain, and as the admin I promptly paid it using Google checkout.
Shortly afterwords the domain expired on the day aniversary date and we were totally hosed.
All his attempts to solve the problem frustrated him to the core and he was in a desperate situation
At this point, I'm ready to cry. What have I done to be stuck in this kafkaesque place.
Before I proceed with my post, lemme do a plug here. This is exactly the reason why SaaS users should subscribe to Cloud Avenue and visit regularly to read our posts. In fact, the basic premise behind the SaaS Risk Reduction Series itself is to help users avoid situations like the one above.
Let us now see how this user could have avoided this scenario if he/she had followed one of my first suggestions in this series. Don’t keep all eggs in one basket. In that post, I had argued against using a single vendor for all your SaaS needs. Some users didn’t like the idea because they thought keeping email with one vendor and calendar with another is too much of a hassle. I do agree with them about the hassle but paranoid ones are better served by spreading the apps/data with different vendors. Anyhow, even if one didn’t want to spread different SaaS apps with different vendors, they could use this principle in other things related to their digital properties. In the above example, the user could have registered the domain directly with a domain registrar instead of going through Google or some other resellers. The domain is the identity of any business. It is very important to identify a “friendly” registrar and, then, register the domain through them. I would list the following as the characteristics of a friendly registrar.
These are some of the basic things one should take care before trusting a registrar to hold your or your company’s digital identity.
Secondly, and most importantly, SaaS users, using their own domains, should use a third party DNS provider like DNS Made Easy to manage their domain records. Thirdly, it is important to use a secondary mail server (it could come handy in cases where Google or some other mail provider goes down or locks up the email accounts for some reason) from another vendor.
The user in the above case could have easily avoided all the troubles by keeping all his eggs (in this case domain registration, dns management, saas applications) in different baskets. Yes, it is a hassle compared to getting it done with a few clicks, with a single vendor. Yes, there is a learning curve to it. But, by following my suggestion, one could minimize the risks and have a peace of mind in this increasingly distributed IT environment.
Would you do the equivalent with - say - a car? Buy the body, seats and engine from different vendors? I assume not, because nobody would put up with this sort of extra hassle in most business areas. So why should anyone expect it with something as fundamental as domains?
If you scan the comments for Matt Glotzbach's name, he stopped by to comment on that thread yesterday: "Hi, I work with Matt Cutts and am responsible for Google Enterprise products. We've had a chance to investigate this more deeply. We've identified the bug in our code that caused this issue for a small handful of domain renewals, and are deploying the fix. Please accept my apologies on behalf of Google for the inconvenience this caused you. Also, phone support is definitely still available for all Premier Edition users." So at least in this case, Google investigated the issue, found out the problem, starting fixing it, and dropped by the web page to give an update in the comment in under a day, before the post even got to Techmeme. Of course we aim to never have any issues at all, but I think Google was pretty responsive in this case.
This doesn't look like a problem of too many eggs in one basket. The expectations for that registrar were completely reasonable to expect of a company like Google. While they could've taken all the steps you describe, asking small companies to do that for every Intranet (this was an intranet application) is a lot of overhead. There need to be single vendor solutions that work with a few clicks (and no, I would not expect Spolsky's crowd have a problem understanding how to do it your way) simply because it isn't worth the overhead. That Google fumbled the ball so badly here (and apparently this case is not an isolated exception) is inexcusable. They have to do better.
Bob, coming from a country like India to US in mid nineties, I used to wonder about the fact that I could easily walk to the airport gates in US without undergoing security hassles like what we experienced in India. I used to think why can't India make it easy like US Airports. Then came Sept. 11th and we all understand how important it is to have a beefed up security at airports. It is the same here too. It is human nature to take convenience over security until something bad hits them. I have no doubt that Google goofed up but users should also prepare themselves for worst case scenario.
Post Comment