Posted by on July 31, 2013 in DevOps

In the IT industry today, Virtualization is one of the hottest buzzwords around. It seems like everyone uses, supports, provides tools for, and/or sells something that has “virtual” in its name. Virtualization is a fun concept that has a lot of interesting ideas floating around it, but at its core, Virtualization is nothing more than software pretending to be hardware. That software, usually referred to as the hypervisor, can improve server density, lower overall power consumption, increase ease of manageability, and decrease total cost of ownership. A bad hypervisor does the opposite and can make you curse, scream, and sometimes even cry as you watch your data center crumble around you.

Here are a few tips to think about when building a virtualized infrastructure:

Start with a clear vision

What are you trying to accomplish? Before anything else, you need to at least attempt to spell out what you’re going for. Several possible aims, a few of which I mentioned above, should be clear before you get started. Anyone with more than an internship’s worth of experience knows that IT projects are typically moving targets. Many of us give up on attempting initial specs at one point or another, but the fact remains that if you don’t know where you want to get to, you’ll never get there.

Consider the payloads you plan on virtualizing

IIS and Apache payloads require very different hypervisor and hardware specs than a database payload. If you’re looking to increase server density, then you need to pick a hypervisor that can handle high densities. Over-subscription can be applied to better use the hardware resources available, but over-subscription planning is as much an art as a science. Or, if you’re looking for a fully automated infrastructure run completely through APIs (in my mind, an absolute necessity for DevOps infrastructure) then you need to make sure your hypervisor can handle that from inception.

Test, test, test

One of the toughest lessons to learn the hard way is to always, always test for what you will actually be using the virtualized servers for, and whatever you do, never take the salesperson’s word for it. If you were to review the marketing material for the top five hypervisors out there, you would be hard pressed to tell me the differences on paper. To make matters more difficult, even if a feature is supported on paper, some marketing teams have a habit of adding this little asterisk next to key features indicating that it costs extra, or is available in the next patch (or the next release). The only way to find out is to test the hypervisor exhaustively.

Mixed vendor solutions

It is also worthwhile to try out multiple hypervisors for your environment, especially if your environment has multiple payload types. In some circumstances, a mixed vendor infrastructure can have huge benefits for the user base, but you’ll never know unless you try.

At the end of the day, a well-designed infrastructure can make or break an organization. It doesn’t matter how good your product is, or how beautifully your marketing campaign is working, if your infrastructure can’t handle what you ask of it.  If you design the platform on top of your infrastructure correctly, your user base will only ever see a smoothly operating platform, and never think about the underlying infrastructure.

About Daniel Sands

Daniel Sands has been a DevOps Engineer at Ancestry.com since December of 2011. Prior to joining Ancestry.com, he served as the Vice President of Information Technologies at the Enlightened Wealth Institute based in Provo Utah from January 2008 to December of 2011. Mr. Sands holds an M.B.A. with an Information Technology specialization from Western Governers University. His favorite quote is “It’s kind of fun to do the impossible.” - Walt Disney


We really do appreciate your feedback, and ask that you please be respectful to other commenters and authors. Any abusive comments may be moderated.

Commenting is open until Wednesday, 14 August 2013