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.
Here is how I am defining the workload characteristics 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:
- 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.
- 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.
- 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.
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