Moving your data center to the cloud: is it worth it?

Every CIO wants to get out of the data center business. It’s the most common thing I hear when meeting with any IT strategist. “I’d like to use the economies of scale of Amazon, Google, Microsoft, Oracle, etc.” And it’s tempting to just want to “lift and shift” or “move and improve” your data center into the omnipresent cloud. You should save money. But will you? We have all heard of the pitfalls of cloud migrations. “I had no idea how much I/O I had in and out of that thing, and now I get charged GB/[time]. And feel forced to buy dedicated lines.” These things that we don’t think about the impact of the cost of migrating to the cloud. There are many consultants out there who can help navigate these pitfalls, but unfortunately, they don’t know what they (or you) don’t know. And the only way to know is to do. But do it with cost constraints. And work with someone who knows how to implement them.

When you buy a server from any vendor, you know exactly what it is going to cost you over 3-5 years: the initial price + cost of yearly maintenance + data center costs. Simple. Your IT department should calculate data center costs by (power + cooling + network + building + fully burdened headcount + misc.) per “device RU” per year.

So here are the things to keep in mind when you are considering the cloud:

1. Time:

The cloud doesn’t have to be up 24 hours a day (for you).

Does one of your development engineers need 4 VMs to do their work? Each VM requires 4 cores, 16GB memory, 1 IP address, 100GB disk space, minimal I/O.

On-prem: You just give them a server with 16 or more cores, a few file systems or LUNs on some storage or local disk, and let it run 24 hours a day, even though they are in the office from 10-7 and rarely work on anything after. What’s the cost of that server + maintenance + data center over 3-5 years?

Cloud: Bring up 4 VMs + Storage. Teach the engineer to launch the environment when he begins work. The VMs will come up from where they ended. Teach him to shut them down when he leaves, which he probably will not do, so an orchestration environment should be in place to check the load on the VMs after, say, 9 pm and if there aren’t any…shut them down. In the cloud, you get charged for $/hr of uptime, not for a shut-down VM. Orchestration can save you up to 2/3 of your server costs as compared to on-prem in a development environment. I have priced out this exact scenario, and each developer would cost you less than a Starbucks grande latte per 8 hour day. Venti if he works a 10 hour day. $5-7 per workday per developer. What was your on-prem server costing you?

2. Networking:

You can’t get there from here.

On-prem: Your apps, database, etc. are all in the same place. Their I/O is within the same building. It feels virtually free. The I/O from your customers may come over dedicated lines or via the Internet. Fixed costs. And shared among various departments.

Cloud: If you migrate your apps and database into the same cloud data center, the I/O between them will also be essentially free. I/O in-to and out-of-the data center are now charged GB/[time]. Or, you can opt for a fixed cost leased line between your cloud provider and the Internet (public). Or the cloud provider and your corporate data center (private). These decisions are based on your presence in the Cloud provider’s data center. However, what if you start migrating apps to SaaS providers in other data centers? What does your I/O start to look like, and what are the costs? The trade-off between cost and latency begins. I will write another blog post that focuses solely on the networking aspect of cloud migration. I find that in the initial migration to the cloud (first app), the network is an afterthought. The second time (second app), it’s the first topic of conversation.

3. CPU load:

Your data center is architected around peak workload. You can architect the cloud for nominal.

On-prem: Unless you are in manufacturing, I doubt your VMs are running at 80% utilization 24 hours a day. Most architects around their projected peak workload. Best Buy architects a data center around Black Friday and Cyber Monday. H&R Block does it around tax time. What do you think H&R Block’s servers look like in August?

Cloud: If your on-prem servers are running at 15% utilization during off-peak, then aggregate five of them onto a single cloud server. Run it at 70-80% utilization. What happens during peak? Startup another server, and migrate the VMs. That’s what the cloud is for. But this requires orchestration work. The cost savings are more than worth it.

You can apply orchestration to daily peaks as well, on DBaaS, for example. If you choose to rent your licenses, then you can scale from 2-30+ cores in real-time, up and down, and only get charged for the cores you are using for that hour. Again, this requires some good coding, but working with a partner who knows how to implement orchestration will pay for itself in infrastructure savings almost immediately.

Here at Infolob, we are pros at managing the cost constraints that make the cloud so popular. Knowing that migrating your data center to the cloud contains a lot of unknowns, we are here to simplify the migration. We have done it before. We also know that without good orchestration, your cloud costs will soar. Let us help.

This blog post was written by Glen Shok, Sr. Director at Infolob Solutions. He can be reached at Glen.Shok@Infolob.com.