Inversoft

6
Aug/2012

Our Jump from the Cloud

Brian Pontarelli By Brian Pontarelli
Google+
@bpontarelli

First things first: we don’t think the cloud is a bad thing. Not by a long shot. In fact, it’s an ideal solution for many organizations. But for us, the cloud’s cost and performance wasn’t quite the right fit for what we needed. So now, after months of consideration, we’ve decided to move our applications out of the cloud and onto a dedicated server.

A Past of Virtual Servers

Here’s a little background of how we were using the cloud (aka our virtual servers). Over the last three years, we have used a variety of cloud-hosting providers—some call themselves “cloud providers” while others still use the term “VPS.” Rather than using a single provider such as Amazon, we used a few different providers in an effort to balance cost and performance. We hosted all of our websites and public-accessible applications this way, and as we added new applications, we would spin up a new instance in the cloud to run it.

Here’s the list of the applications we ran in the cloud:

Most of our applications are Java applications or WordPress applications running inside Apache. To run these applications, we had four cloud instances, each with roughly these specifications:

  • 2 virtual cores
  • 3+ GB of RAM
  • 100+ GB of disk

One of the major benefits of running four instances in the cloud was the insulation of each application from the others. If one had issues or crashed, the others weren’t affected. Yet, over the last six months, we have had a string of problems that prompted us to consider alternative, cloudless options. Plus, as we added cloud instances, we also added to our monthly costs—all without seeing any major improvements in performance and stability.

The High Cost of RAM

One of our primary hosting concerns is RAM. We have a number of large applications that use a considerable amount of RAM, which doesn’t come cheap in the cloud. In fact, it appears that RAM is generally charged at a premium and is one of the main factors determining price in the cloud.

Here’s an example of Amazon’s RAM pricing:

  • 1.75 GB: $67/month
  • 3.75 GB: $124/month
  • 7.5 GB: $240/month
  • 15 GB: $570/month

This shows a mostly linear increase with the amount of RAM.

Swap and Paging Pitfalls

To keep costs low, we often used OpenVZ rather than VMWare virtualization when the hosting company offered it. OpenVZ has a few drawbacks though. Mainly, it doesn’t provide swap space and it controls memory pages pretty strictly.

Even though our instances had enough RAM, our applications would sometimes ask for more. Oftentimes we had either hit the limit and there was no swap available or we would need more pages than the virtualization software would allow. In either situation, the application would not get the memory it needed and crash. In a few cases the cloud instance would crash completely.

Piecemeal Performance

All of our cloud instances were slices, meaning we were receiving a piece of a server and sharing the rest of it. This technique makes cloud hosting a highly profitable business when you have many customers who don’t use a lot of processing power or RAM.

However, this can often work against you as it did for us. After noticing that most of our instances were not performing well, we determined that the server was swapping our entire instance off the CPU and then adding another customer’s instance in its place. This probably happened a couple of times each second, which meant that we were constantly battling with the other customer’s for the shared CPU and RAM access.

Even though we always had two or more virtual cores, we couldn’t consistently access them. Even when the machine had enough cores and RAM for everyone, this seemingly endless swapping slowed down our applications and served up page load times exceeding four seconds.

In the end, it became clear that two virtual cores and 3GB of RAM in the cloud just doesn’t deliver the same performance as a two-core, 3GB on-site server.

Serving Up Server Stability

So, what was it that ultimately pushed us to make the change from virtual to dedicated servers? Simple: we needed a solution we could trust.

Toward the end of our time on the cloud, one of our instances was crashing on a far-too-regular basis, and the hosting company was not as responsive as we hoped. We also experienced a number of unfortunate, extended outages. Every time, the hosting company would increase our RAM and increase the page limit for our instances. But every time, we saw the same problems pop back up again.

The Switch to Dedicated Servers

After the third outage in as many months and another lackluster support interaction, we decided to contact a friend who runs a dedicated hosting company in Boulder named CarbonLogic.

Chris at CarbonLogic was able to quickly get us up and running with a good-sized, dedicated server on our preferred operating system (Ubuntu 12.04). We decided to start out modestly with a single server that would replace all of our cloud instances and run all of our applications.

To get the job done , we needed at least 8GB of RAM. Here are the specs we chose for our dedicated server:

  • 2 Xeon Quad core CPUs
  • 16 GB of RAM
  • 2 250GB disks (RAIDed)

Dollars and Sense

We were pleasantly surprised to learn that our new, dedicated server was roughly the same cost as our previous four cloud instances. This was particularly important when we considered that we were already maxing out our space in the cloud and would soon be buying more. Our new server can handle all of our current needs with plenty of room to spare. So as we continue to grow, our investment will save us even more money along the way.

Peak Performance

Since switching to our dedicated server, our past performance issues are gone. Page loads that were consistently taking four­ to five seconds now take less than one. What’s more, the machine is more responsive both through a web browser and a command line.

Stability That Sticks Around

When we first discussed switching to a dedicated server, we were concerned about stability. If it crashes, all of our applications will be down. This is a valid concern, but given the state of our hardware and software, we feel confident that this possibility is extremely low. And since we no longer have to battle with virtualization systems or compete with other customers for the CPU, we expect even greater strength from our new solution. We also now have a clear backup and recovery process that should minimize the outage duration of an unforeseen crash.

Finally, we hold a new level of trust for our new hosting provider, CarbonLogic. We believe they will respond to failures more quickly and with a higher level of expertise than any of our cloud providers did or ever could.

Summary

Our recent move from cloud-based hosing to a dedicated server has made a large improvement in both cost and performance for our business. While we could have purchased more, larger instances in the cloud to equal the space and power of a dedicated server, our past experiences show that this would have been a more expensive and less effective solution for our needs.

Additionally, we feel comfortable to be working with a local company that has a proven track record of excellent service and support.

- The Inversoft Dev Team