Choosing a Platform Based on Workload Characteristics

Paradoxically, there has never been a better or more confusing time to discuss which platform is most appropriate for a given workload.  As we seek to solve problems around automation, continuous integration / continuous delivery, ease of upgrades, operational complexity, uptime, compliance, and many other complex issues – it quickly becomes clear that there are more than a few viable options.  Making matters worse – there is too much focus on the “how” (to adopt a given platform) and not enough focus onthe “why”. To this end, I’d like to address more of the “why” in an attempt to better influence the “how”.

A Little Background

There were a few catalysts for this article. First and foremost, I’ve recently met with numerous customers and, unsurprisingly, have been asked numerous challenging questions. Most of these questions were asked in consideration of “popular” concepts such as “the cloud”, “automation”, “streamlining”, and “cost”. In addition, on a number of occasions, customers wanted to get right down to talking about a particular / specific product that they had heard of or to get a product recommendation from me or my colleagues.

These lines of questioning and the tendency for some to dive right into “product” are not “bad” per se; but they only scratch the proverbial surface. I typically elect to dig deeper. It’s far more important to get at the heart of why Red Hat (or anyone, really) is sitting across the table from you. And… the reason?  The reason is typically “change”. Customers want change because one or more things are broken – broken enough that something needs to change. So… my vote is to get to the root of the problem(s).

The next thing that needs to be addressed is the actual workflow for how an application (including its underlying virtual machine, container, instance, or server) gets ordered, provisioned, deployed, updated, and retired. Where does the data get stored? There are lots more questions, but hopefully this sets the tone for the types of conversations that need to occur before anyone determines the right platform(s).

The other primary catalyst for this article is my colleague Brad Vaughan, who created a rather large and detailed matrix of workload characteristics. For the purposes of this article, I’ve greatly simplified the matrix, but I have to provide credit where credit is due.

Extremes and Bad Balances

As mentioned above, many customers want to go straight into a product discussion before we have the chance to discuss their particular application, workflow, or business needs. Note that while all of these conversations are taking place between equally intelligent and articulate individuals – there has (indeed) never been a more confusing time to match workload characteristics with a particular platform. Sometimes there is blind focus on a particular technology – other times there is just confusion over use cases.

In addition to plain old confusion – I sometimes encounter situations where customers are attempting to “hold back the tide”; essentially holding onto outdated practices, methods, and/or technologies. Potentially worse – they may be attempting to apply those old methods to the new technologies – a sort of “unhappy balance” between old and new. Or, in some cases, as customers look to standardize – they look for a panacea (i.e. “the mythical single platform”) that will run everything. Spoiler alert: “the mythical single platform” doesn’t exist (yet).

On the one hand, yes, there are competing technologies. Competing in the sense that Red Hat Enterprise Virtualization (RHEV) competes with vSphere in virtualization or AWS and Google compete in public cloud. But public cloud and virtualization don’t necessarily compete and containers and private cloud don’t necessarily compete (…and so on and so forth). I state this for the simple reason that applications may be designed to utilize more than one type of platform in terms of architecture.

It’s all a matter of matching the workload characteristics to the potential target platform.

Workload Characteristics

Here is how I am defining the workload characteristics for the matrix (further below):

Slide2Here is how I am defining the target platforms for the matrix (further below):


Enter the Matrix

The matrix (below) is presented as a “heat map” of sorts. The general idea is not to say one technology is better than another – it’s more to illustrate that some technologies lend themselves better to different workload characteristics than others do. For example, while security has come a long way in terms of containers, if security is a top concern, you may want to first look at a different platform. On the other hand – if the combination of elasticity, lifecycle, and deployment automation are of high importance – this makes containers a tough option to ignore.

Note that if you are looking for “the most green across the board” (i.e. the most flexible platform across the most workload characteristics) traditional virtualization is hard to ignore.

The other thing to keep in mind (here) is that this is technology… and technology changes. What do I mean?  I mean three things:

  1. This “rubric” is NOT absolute. The comparisons here are relative to each other. For example, for a seasoned OpenStack veteran who knows the technology, it may make perfect sense. For someone used to traditional virtualization, it is very complex.  Given my comment on container security (above) – I’m not saying containers are inherently insecure – I am saying that given the maturity of containers as a technology – other technologies are currently more secure in relative comparison.
  2. Technology is constantly being updated. Anything on this list / in this matrix is subject to change, updates, and significant improvement.  If we were to re-spin the matrix twelve months from now – it would / will inevitably look different.
  3. YMMV (i.e. your mileage may vary). You may have something in your environment that makes one or more of these colors either irrelevant or not applicable. That’s OK. There is no way that I or anyone else could make a heat map like this 100% accurate in terms of everyone’s particular environment / situation / needs.

Heat Map

So with all of that, here is my attempt at mapping workload characteristics to the “right” platform:



As always, comments and questions are welcome!  Please reach out using the comments section (below).

Hope this helps,

Jon Benedict / Captain KVM

  1. Hi John,

    Thanks for an intriguing analysis!

    Can you clarify the “Resource Scalability” criteria? The way you describe it above “horizontally (low/red) or vertically (high/green)” seems to contradict the way its displayed in the heat map. AFAIK its easier to add more containers or cloud VMs (horizontal scaling), while traditional virtualization typically includes the ability to hot-add RAM and CPU-shares (vertical scaling).

    Do current container technologies include the ability to limit or tweak the individual container’s CPU and memory resource utilization?

    I’m also wondering how to apply this model to possible technology combinations. Suppose I decide that I have some applications that are better fit to run in containers while others that would be better served by virtualization. How do I decide then, if to deploy a virtualization platform and a container platform side-by-side on different servers or to deploy the virtualization platform first and then to run the container platform on top of it?

    (For the sake of the discussion, lets assume I do not already have one of the technologies deployed or familiar to my IT staff. Otherwise, it seems to make the answer trivial)

    1. Hi Barak,

      Thanks for taking the time to comment. The truth is, I’ve been having issues with my source file (updated). The way you describe horizontal and vertical scaling for containters/cloud and traditional virtualization, respectively, is how I look at it and describe those technologies. To that end, applications scale better when designed for containers or cloud (horizontal scaling) as compared to traditional virtualization (vertical). Vertical scaling means we still have physical limitations “somewhere”. The VM can’t grow any larger than the physical host in terms of RAM or CPU…

      Applying this model to combinations is as easy as looking at the different components of the application design. Keep in mind, this article isn’t the “end all” answer either.. it’s really meant to get folks thinking about different platforms.


    2. Hi Barak,

      Your understanding of horizontal vs vertical scaling is solid. The article doesn’t attempt to cover combining the technologies; that’s really better suited for a full blown paper. Containers on virtualization or containers on OpenStack, for example would be a fantastic solution for many workloads.

      Captain KVM

  2. Interested to know why you have assessed containers as having a low for Security and Compliance, this is a technology that we were potentially likely to be looking at in the future and I was wondering what the downside was?

    1. Hi Alec,

      EXCELLENT question. As I stated in the article, I am not saying that containers are inherently insecure, only less secure in comparison to the other technologies in the article. In short, it’s one of the easiest things to misconfigure or “underconfigure” from a security standpoint. Keeping SELinux enabled is a big thing, using signed packages and registries is a big thing, and don’t run as root. There are a number of other points as well, but those are pretty big.

      If containers fit your workload, then you should pursue containers. Hopefully you’ll look at OpenShift – it offers SELinux, registry, and other things to help secure the containers.


    2. Hi Alec,

      First off, apologies for the late reply. Second, as I attempted to make clear in the in the article, I’m not trying to say that containers are insecure. I’m simply stating that in comparison to the other technologies they are less secure. HOWEVER, there are definitely steps that can be taken to mitigate risks. Restricting roles, restricting where folks can pull code from etc..

      Captain KVM

  3. Among the workload characteristics, both resilience and certification have the same description. Is that right?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s