Cloud Fail: Why We'd Rather Shell Out for Our Own Servers
John Swindells is Lead Developer at BlurtIt.com, Norfolk, England
We either needed to expand our server hardware — which would add about $4,000 to our monthly expenses — or give up the idea of hosting our own data and move over to the cloud, which we hoped would be more cost-effective and more flexible as we grew.
BlurtIt is an online question-and-answer community. With about £2.4 million (more than $3.8 million in US dollars) in annual revenue, BlurtIt is also the largest source of income for our parent company, Mindcom Internet Limited. We have carefully cultivated the loyalty of thousands of contributors since our launch in 2006. Regardless of which option we chose, we couldn't afford to screw up the transition to a new system.
In the end, cost and flexibility won the day: We were better off in the cloud. Or so we thought.
After some research, we decided to go with Amazon's Elastic Cloud Compute (EC2) plan. We could buy it on demand, paying only for the server capacity that we actually used, which seemed very attractive.
Before we made the switch we brought in a third-party consulting firm to give us a hand, just to be safe. They knew their way around Amazon's cloud hosting services, and the setup seemed easy enough to them. It all looked good until we changed our domain name server and moved our traffic over.
Everything went wrong from there.
Within minutes of moving to the EC2, performance took a nosedive. There were all sorts of delays, and pages took minutes to load — if they ever loaded at all.
The problem had nothing to do with lack of resources: In the past, we'd used three dedicated servers to host our data, and we'd purchased five equivalent-size servers on Amazon. It wasn't a human error, either: Our consultants had significant experience using EC2, and they did everything that was supposed to be done.
As far as we could tell, the cloud-hosting server just didn't have the capacity to load our data nearly as fast as we needed it to. Our users and our advertisers rely on our site loading quickly. What's more, we get a lot of search-engine traffic, but the search bots would miss our data if the loading time remained so slow. Leaving the situation as it was would have completely killed our business. It was a disaster.
We switched back to our own dedicated servers that very same day. The company that helped us move to Amazon assisted with the migration back to our servers, and worked with us to make sure everything went smoothly. Since we only paid Amazon for the data we used, the financial cost wasn't very significant. Even so, we lost a half day's worth of traffic and new user sign-ups, and a full day's work for me and the rest of the IT team.
Given the dreadful experience we had with Amazon, we weren't in a hurry to try it again, but I was curious to find out what had gone so wrong. I got in touch with someone at Amazon who said he would help us with our problem. I extracted all of the technical logs that we collected during our brief stint using the EC2, and sent them to him. But I never heard back -- I never received any explanation. That was another major disappointment.
Don't get me wrong — I'm not opposed to cloud computing in general. We actually have a smaller project that lives on the Rackspace cloud. It's many times smaller than BlurtIt, and we do get good performance from it. But an interactive and rapidly evolving site like BlurtIt needs a dedicated platform where we know exactly what computing resources we have at hand.
Amazon's cloud hosting may work for number crunching, but for real-time Web apps, it really falls short. When you use cloud hosting, you can't guarantee that the service will deliver exactly to your specifications. With a dedicated server, we know exactly what to expect. Sometimes it may not run as fast as we'd like, but it's a better option than dealing with the uncertainty of a system that may not deliver our data at all.
In theory, if the EC2 had met our expectations, we would have ended up paying considerably less than we do for our server hardware. If you come across a platform that offers huge cost savings over your current setup, sometimes you need to take the risk and give it a try. But in our case, it failed spectacularly.
Editor's note: Amazon did not respond to requests for comment.
John Swindells has led the IT department at BlurtIt since its founding in 2004. The company has never taken any VC funding.
— As told to Kathryn Hawkins
Read more: