Friday, March 22, 2013

Rethinking Cloud-based Computing (SaaS)

Some time ago I moved both myself and my business to the cloud. I have generally been quite pleased with the result. This week two events happened that made me reassess the merits. This post is not against SaaS, but rather looking at problems that are larger or different than I expected going in.


The first event was Google announcing they were shutting down Google Reader, giving only a little over 3 months for everyone to move to alternatives. Google Reader is important to me, and the alternatives simply are not ready. It will be a strain for alternatives to improve within the allotted 3 months. The point here was that Google shutdown an otherwise healthy service that they had been running since 2005. It was listed as one of their main services. The reason for the shutdown seems to be strictly related to their vision of their business. The needs of millions of users actively using the service seems not to have been considered. There is no excuse for Goggle giving only 3 months notice.

When one of my desktop software vendors abandons an application I use (or goes out of business), this is annoying as I'll need to eventually replace the application. On stable systems it may be years before I have to do this. There are exceptions to this... for example, accounting applications need new payroll information every year. When a Cloud-based app goes away, it GOES AWAY. One is completely without that functionality immediately. In the case of Reader, Google gave 3 months, which is better than no notice, but it made me realize that they could have give even less notice. I depend on Google for many things. Some things are replaceable. For example, email could be replaced in a matter of hours as there are numerous alternatives available. The problem with Reader is that alternatives really are not available. As Google made this service available for "free" [not really free, they collect information for ad purposes from you], most high efficiency RSS readers have disappeared. The mobile market still has a viable set available, but nearly every one syncs with Google Reader. There are fledgling web-based services available, but they were not prepared to handle the millions leaving Google. Also, in order to survive, they had to differentiate themselves from Google, usually by prettying-up the interface with pictures. Such services have their place, but are simply not a replacement for someone that sifts through news at high-speed every day.

To sum up, Google killed off a healthy infrastructure of Desktop readers by offering a really good web-based solution that allowed mobile apps to freely sync with it. Then on a whim 8 years later, decided to kill off the service with only 3 months notice. Google is a large, well established company whose livelihood is cloud-based. How could I expect they would kill off a critical service with such little notice? When I went into using SaaS, I assumed companies would behave rationally. That if I picked stable providers, the services I depended on would go away rarely and with plenty of notice. Yet, Google, clearly one of the most stable available, has violated that expectation.


The second event was I had an extended (2 business day) Internet service outage. As I eventually was able to put my business back online using cell phone tethering, it was not as bad as it could be, but it did make one think about how dependent one had become.

This event was less of a problem than I thought it would be. Because of cell phones we were able to access all of our online stuff (more slowly, but it works fine in a pinch). However, it made me stop and think about what would happen if it were a Google outage rather than a telecommunications outage. We would not be completely dead as we daily make a backup of all documents in a form that can be used by LibreOffice.
Contacts and calendars are synced on cell phones so that would not be an issue other than sharing would at least temporarily cease. The need for using LibreOffice would mean it would be a bad idea for us to have no other systems but Chromebooks and Chromeboxes.

From the start, I had planned to use a cell-phone as an emergency way of using the Internet. It turns out that using cell phone tethering was harder than I would have thought. Our ordering system is distributed on our network and only one of the three critical computers had wifi and all three have to be available on the same network at the same time. In the end, I grabbed an old Mac-mini, set it to the address of our default router and turned on Internet sharing, vectoring the ethernet to the wifi, using the wifi to talk to the cell phone. This worked surprisingly well. Once LTE is available here, it might not even be noticeable. Obviously, things like our cloud-based backup had to be turned off.


Lessons learned

  • Even the best of vendors are not really trustworthy. If you are dependent on a cloud-based service, you need a contract specifying shutdown terms. It is essential that your vendor either be quickly replaceable or in really good financial shape.
  • Local backups of cloud-based information are essential.
  • Cloud backups are great for your off-site backups, but local backups need to be a part of the picture as well.
  • Despite our careful backup planning, there is one area we failed in. Google Gmail does not have a reasonable way to make backups. (You are supposed to use IMAP, but Google throttles this to such an extent that backups are unreliable.) In the event of a Google failure, we would have zero access to our email archives. We are currently not sure how to get around this problem. We might have to leave Gmail. (If you know of a reliable way to backup Gmail, I'd love to hear about it in the comments below.)


Any SaaS stories like this you want to share? Comment below!

No comments:

Post a Comment

Now allowing anonymous comments (but they are moderated).