Google Spreadsheets — getting better

I had the opportunity to use Google spreadsheets for some data gathering this week and thought I would write about my experiences. We are using Google Apps and Gmail at my company, Gnip, to facilitate document sharing. However, I am one of those people that mostly uses my desktop Office apps to create documents and then I just upload them to Google Docs.

For a bit of research we are doing we decided to use the new Form editor in Google Spreadsheets. (For people that want to keep up with the Google Apps team I would recommend following their blog) I’m very excited to see a lot of recent updates to the spreadsheets and the reporting and form editors. For our project the results were mixed. The main reason we used the Google Spreadsheets was to try out the “data analysis” feature which auto-generates a report based on using a form for data entry. The results were great for the questions we entered before we started entering data. However, as happens a lot of times we can up with a few new questions after we had entered some data. What we did was add the questions and hand entered the data to the spreadsheet for the existing entries. The result: the hand entered data in the spreadsheet was not included in the auto-generated graphs (bummer) so we are left with a complete data set, but auto-generated graphs that do not match the full data set. This appears to be a known issue to the Google Spreadsheet team so we look forward to new capability being added. As for my data, I just had to generate my own complete graphs.

Amazon S3 services down today — ugh

It seems every few days or weeks we have a reminder that cloud services are experiencing growing pains. I wrote about this topic a few weeks ago, and also about an incident with Amazon. Today, Amazon S3 services are down.

In fact, a nice reminder from the folks at WordPress tells me that this impacts me directly on my blog:

“Notice: Because of an issue with Amazon’s S3 service, some images maybe unavailable for viewing after upload. We are working on resolving this issue and will update the following forum thread with more information as it is available.

The AWS Service Health Dashboard shows a lot of nice information for people keeping up with the outage. I give Amazon a lot of credit for trying to be transparent as possible, but it is troublesome to see a multi-hour outage take a lot of investigation to just figure out “the why” and in the mean time users are left without a reliable backup service and must scramble to fix things locally. Perhaps there is a need for someone to provide a best practice for setting up a local set of information that can be regularly synchronized with the cloud so one can at least control their backup. Otherwise many services and websites that store content and data are simply broken or offline while waiting for S3 in this case to come back to normal.

The S3 details from the AWS Service Health Dashboard

9:05 AM PDT We are currently experiencing elevated error rates with S3. We are investigating.

9:26 AM PDT We’re investigating an issue affecting requests. We’ll continue to post updates here.

9:48 AM PDT Just wanted to provide an update that we are currently pursuing several paths of corrective action.

10:12 AM PDT We are continuing to pursue corrective action.

10:32 AM PDT A quick update that we believe this is an issue with the communication between several Amazon S3 internal components. We do not have an ETA at this time but will continue to keep you updated.

11:01 AM PDT We’re currently in the process of testing a potential solution.

11:22 AM PDT Testing is still in progress. We’re working very hard to restore service to our customers.

11:45 AM PDT We are still in the process of testing a series of configuration changes aimed at bringing the service back online.

12:05 PM PDT We have now restored communication between a small subset of hosts. We are working on restoring internal communication across the rest of the fleet. Once communication is fully restored, then we will work to restore request processing.

12:25 PM PDT We have restored communication between additional hosts and are continuing this work across the rest of the fleet. Thank you for your continued patience.

12:51 PM PDT The restored hosts are stable and we are moving forward in restoring communication between additional hosts.

1:17 PM PDT We continue to make incremental progress and communication between additional hosts has been restored. We are continuing with the plan to restore communication across Amazon S3’s large fleet of hosts.

1:38 PM PDT At this point, we are accelerating progress on restoring internal communication as all signs continue to look good.

2:03 PM PDT We have restored all internal communication between hosts in the EU and we are continuing to make progress in the US. Once all internal communication has been restored, we will start a multi-step process to begin accepting requests across Amazon S3 locations.

2:19 PM PDT A quick update to let you know that we have now also restored all internal communication between hosts in our West Coast facilities in the US.

2:36 PM PDT We have restored all internal communication across Amazon S3 hosts. We have started the multi-step process to begin accepting requests across Amazon S3 locations.

Speaking of cloud reliability now Amazon is down

So, right after I did my last post on the need for cloud data services SLAs to meet enterprise expectations I got a ping that Amazon is down — I went to the main Amazon URL and the EC2 URL and got the dreaded “Http/1.1 Service Unavailable”.

Wow!

How will cloud services mature to meet enteprise service levels

In reading the latest post from Louis Gray (Disqus’ Downtime) I learned that he is suffering from a data outage — namely his blog comment service appears to be down and with it all his access to his blog’s comments. Now it appears comments are back on.

Over breakfast I was talking about this and other cloud issues with a friend so I found this interesting that when I sat down to see what was going on the first thing I ran across was an example of unreliable data access from a cloud service. We were talking about how even though there have been some great advances in SaaS, PaaS, and also understanding of service-oriented architecture the enterprise just brings higher levels of service expectations then a lot of the new providers appear to grasp.

In enterprise IT shops services have to run — the business depends on the information that helps people work, supports the customers or puts the products and services in the hands of the right people. Sure, this case is blog comments, but what if it were data representing communication with the customer service department? contract settlement between partners? order processing? For SaaS solutions to become adopted beyond the early adopters and on wide scale they are going to have to meet enteprise standards or service that approach five 9s for reliability or they simply will not be used for critical information and business processes.

Back up your data while you still have it

I can relate to this post as until recently I also just too lazy to do regular data backup.  It seems there are a host of new companies trying to make it easier and fighting what must just be human nature that leads everyone to believe their data will not be lost.

This post refers to a new startup called Backblaze, and I have friends that use Mozy, but for me the solution was buying the Apple Time Capsule and syncing several computers to it.   In my case I had the unfortunate experience of having a hard drive fail on my laptop I had not backed up in about six months.   Why?  Well because I just was being lazy.   With the Time Capsule and the new host of backup services it can be auto-magic.  I really do sleep better now

With all the digital music, photos, and other things you might want to take with you do yourself a favor and get a data backup service or something that just does it for you.