In an attempt to eat his own dog food, IT pro Rick Vanover shares a less than successful experience in using cloud technologies for a specific situation.
Over the last year or so, I have written a number of pieces on cloud computing. I recently had an opportunity to do a task using 100% cloud technologies, and the experiment failed. To be fair, I’ve had a number of demonstrations and evaluations work. I recently came across an opportunity to use cloud services where other solutions may have seemed more practical.
How many of us provide some form of technical support to friends or family? Well, I don’t know about you, but I have never been able to fully shake this burden. What I do now is simply explain my limits. I’m not an expert in gaming or high-end multimedia on computers, so my answers there usually filter people away as I simply tell people not to use those technologies. They usually go away with those questions, but what can still come up are various levels of recovery when things go wrong.
My specific situation was a good friend who destroyed his laptop’s internal power distribution system by plugging the wrong type of AC adapter into the unit. I suspected that the data on disk was still good, so I had the friend ship me the laptop. My plan was fairly simple:
- Remove hard drive from failed laptop
- Place it in a known working laptop with the same type of interface
- Boot using a Windows PE recovery environment and copy the entire disk via command line to a network resource
- Make the relevant data available via download via my cloud storage account with Amazon Web Services (AWS)
I had considered converting the entire hard drive to a virtual machine via a cold-clone mechanism, but decided on the command line copy. When the laptop arrived, all steps went as planned to recover the data. Once I had all of the data of interest -- the My Documents area of the laptop -- I created a 7-zip archive of the data of interest. The total was around 4 GB. At that point, I was ready to upload the file to the AWS Simple Storage Service (S3) cloud.
Once the file was uploaded, I did myself a think-ahead favor and downloaded the file from a different Internet connection to make sure the file’s integrity was maintained. I used the CloudBerry Explorer to upload the file and the download was performed via HTTP. To check the integrity of the file, I used the Hashtab tool to perform a before and after MD5 checksum on the file on different computers.
The file checked out for me, and I instructed my friend to download the file via AWS over HTTP. No matter what, the file could not be downloaded correctly. I even walked the friend through installing Hashtab to see if maybe the default program to open the ZIP file was not handling the format correctly. The Hashtab result was inconsistent with the source each time.
I did have to buckle and burn the My Documents data to a DVD and mail it to my friend. The good news is that the costs were not insignificant for each solution; I spent around $5.00 to purchase a DVD disc and mail it to my friend. I incurred $2.82 on AWS for the transfers and S3 storage costs for the failed endeavor.
Sure, the problem was on the receiving end of the file. I verified that I was able to download it, and even went through the hassle of doing it on another Internet connection. But the issue with cloud services is, we don’t always know what the other end looks like. Of course, this isn’t enough of an experience for me to stop advocating cloud services. But, it is a lesson learned on what you can’t control with building a solution of any type on a cloud service.