The Cranky Admin

Finding the Right Fit for Your Workloads

Virtualization doesn't always make the choice easier.

• By Trevor Pott
• 02/22/2017

x86 virtualization brings features to the table which make working with many workloads easier. Despite this, not every workload is worth virtualizing. Determining what to run on bare metal, what to virtualize and what to run from within a container isn't easy, and is more about business processes than technology.

Nerds don't like discussions about business processes. We want to iterate through a checklist or a series of if-then statements and ultimately arrive at a conclusion about what to run where, how, and for how long. If ambiguity is the enemy, conformity is the goal: the more everyone runs things the same, the higher the likelihood that when we run into an error someone else has already experienced it.

This desire for hard-and-fast rules leads many technologists to say things like "Exchange shouldn't be virtualized," or "Web servers work best in containers." Broad, sweeping generalizations rooted in enterprise needs end up as industry-wide accepted "facts" that are applied to the wrong situations. We like thinking about things on a per-workload basis, and we like thinking that what works for one size organization works for all. It's never that easy.

Managing Nightmares
Different organizations see different benefits from virtualization. For enterprises, virtualization is absolutely about workload consolidation. They have thousands upon thousands of workloads and reducing the number of servers by half can save many millions of dollars.

For smaller organizations, however, the real benefits seen from virtualization are in the encapsulation of workloads inside a virtual hard drive and the associated ecosystem of management, backup, migration and high availability tools.

If an enterprise had to run all their workloads on bare metal, relying on application-specific features to provide high availability and integrating an array of backup options into a reliable whole, they could do so. An enterprise can afford the cost of the management tools and nerd time for scripting; they're probably running multiple instances of any software they have deployed anyway.

This isn't true for smaller organizations. They might, for example, virtualize an exchange server because they get high availability out of the deal without having to buy, manage and maintain a second copy of Exchange. Rinse and repeat for any number of workloads. A decent hypervisor, hyper-convergence and software to back up VMs off to the cloud can provide a remarkably robust and highly available infrastructure, for significantly less than bare-metal whitepaper high availability.

What's important here is the use of the virtual infrastructure to effectively bypass the need for several layers of management. This works at a small-ish scale. You have a few dozen or a few hundred workloads that you treat as pets, and you lean on the hypervisor management tools and backup software to see you through challenges.

A quick snapshot before patching gives you the chance to roll back if things go splork, without needing a formal patching regime. The ability to convert a carefully-babied VMs into templates and spawn infinite clones allows a desktop jockey familiar with “next-next-next-next-done” install wizards to suddenly manage a fleet of servers. Only the barest automation is used, and very little scripting is required.

This doesn't work at scale.

Desired State
At scale, you don't want to spawn workloads from a template. You want to bring up new instances of operating systems from clean installers, patch them and inject applications and configurations. Data lives on separate storage from both the configurations and the operating systems. Execution environments are entirely disposable; if something goes wrong, you throw the operating system away and rebuild from scratch.

Here we start seeing tools like Puppet, Chef, Ansible and Saltstack matter far more than arguments over hypervisor vs. bare metal. Once the ability to deploy workloads in an automated fashion has been achieved, the context under which a workload runs are a choice rather than a necessity.

Carefully babied copies of entire workloads don't have to moved from system to system, and backups don't have to contain operating systems and applications. Configurations are managed in a versioned repository. Only the data matters.

Desired state workload management has a lot of advantages, and is the only sane way to handle workloads at scale. What proponents rarely discuss with the uninitiated, however, is that it's a lot of very hard work to get to a desired state workload management system. It's also a lot of work to keep applications working in that sort of environment.

Automating your datacenter so that you can rebuild every workload from base installers and a backup of the data at the push of a button requires an extraordinary understanding of the operating systems and applications involved. That's fine if you have several hundred nerds managing hundreds of thousands or millions of instances of a few hundred different types of workloads. It's completely unrealistic to expect one or two overworked sysadmins wrangling three dozen workloads in an SMB to achieve that level of techno-zen.

Finding the Fit
Most organizations are going to find themselves somewhere in between the two extremes. Easy to automate or mission-critical workloads will often be brought up to the standard of desired state management. Everything else will rely on virtual infrastructure to do the heavy lifting. There's absolutely nothing wrong with that.

All of the above is in part a convoluted way of banging the drum about doing proper needs assessment, rather than being sucked in by marketing or peer pressure. More importantly, it's a reminder that in the real world, needs aren't driven by whitepapers or some objective concept of technical excellence. Needs are messy, individual and human: human limits, human ability to understand management tools, and human priorities on how to spend limited budgets.

This year is going to see a flood of tools aiming to make private clouds, containers and public cloud migrations easier to use. This is a good thing, but it's important not to get carried away by  the waves of novelty.