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):
Here 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:
- 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.
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
執筆者紹介
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit