In Redundancy We Trust

Nov. 9, 2011
Be Careful With Any Cloud Implementation. Make Sure You Know What You Are Getting and Get Proof of the Redundancy
By Jeremy Pollard, CET

Tom Burkitt founded Burkitt Computer ( in Barrie, Ontario. He's a smart dude, not real tall, but he has a tall vision for his company and his software.

My July column on the cloud had a thought from Scott Clayton of IzonData that stressed the importance of a redundant Internet option if a company's connection goes down.

Burkitt had a suggestion. I should take my data and document server and put it with a "real" cloud vendor that has all the bells and whistles for full redundant paths, hardware and 24/7 coverage.

He had issues with his Ontario provider with minor outages for various reasons, not the least of which is that there typically is one fiber from Barrie to Toronto.

Our telecommunications backbone might not be as diverse as the U.S. since we only have a few vendors of bandwidth to choose from, and it remains an Achilles heal for mission-critical software like Burkitt's claim-management software.

His customers are worldwide. They have the option to keep their data on their own servers, or to have BCCorp host them in a dedicated space at its hosting site. Think of it as an Internet-enabled server that can serve a variety of stuff to clients.

The cloud has become a buzzword, and Tom and I had an opportunity to discuss that. "Data should never be part of the public cloud, but services can be," he says.

As we know, a private cloud is really nothing more than an Internet-enabled server typically housed in the company's network center. A public cloud could be hosted by or IBM. Burkitt says his customers house their data and documents on dedicated database servers and dedicated file servers hosted by BCCorp, and they access this data and documents via web-based front end from anywhere. He tells me that the key to his software is that each individual data or document request is authenticated individually, which allows for some pretty cool security features of which he is very proud. This allows for web access in the public domain.

He felt it was time to move to the cloud for his web services. It is a common perception that cloud-based services are more robust, since they take all issues and need for redundancy into account.

He set up a scalable server system for his customers' data and documents. Some of the documents are there for his web services as well.

[pullquote]The customer logs into the service cloud server, and a secure (single-factor authentication) connection is created to the server based on a single request. Once the request is serviced, the port and connection are dropped.

So it was set to go, and the transfer of customers, data, documents and web services went live. Whew. All worked like a charm.

Tom is a detail-oriented guy. The vendor for his servers was on the U.S. West Coast. They were totally checked out, and he was very comfortable with the answers he got about redundancy.

Big Lesson: Trust with verification. Not two weeks later, a customer called Tom on his hotline asking why he couldn't retrieve any reports. Imagine his surprise when he couldn't get an answer from his new, secure, redundant provider.

It was all hands on deck at BCCorp to bring over all kinds of data (not publicly available) from real-time backups to a local server so that customers could get at it.

A hurricane was about to hit Manhattan. It had already had hit North Carolina and adjusters couldn't get to their data and documents. A router had blown up. Asked where the redundant path was, the vendor responded, "We were getting to that in a few weeks." You can imagine the response.

BCCorp now has mirrored sites in the U.S. and in Canada, with full redundancies that were thoroughly verified. That West Coast vendor moved its upgrade plans forward and now has actual full redundancy.

Be very careful with any cloud implementation, private or public. Make sure you know what you are getting and get proof of the redundancy.