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
Sobre o autor
Navegue por canal
Automação
Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes
Inteligência artificial
Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente
Nuvem híbrida aberta
Veja como construímos um futuro mais flexível com a nuvem híbrida
Segurança
Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias
Edge computing
Saiba quais são as atualizações nas plataformas que simplificam as operações na borda
Infraestrutura
Saiba o que há de mais recente na plataforma Linux empresarial líder mundial
Aplicações
Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações
Programas originais
Veja as histórias divertidas de criadores e líderes em tecnologia empresarial
Produtos
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Red Hat Cloud Services
- Veja todos os produtos
Ferramentas
- Treinamento e certificação
- Minha conta
- Suporte ao cliente
- Recursos para desenvolvedores
- Encontre um parceiro
- Red Hat Ecosystem Catalog
- Calculadora de valor Red Hat
- Documentação
Experimente, compre, venda
Comunicação
- Contate o setor de vendas
- Fale com o Atendimento ao Cliente
- Contate o setor de treinamento
- Redes sociais
Sobre a Red Hat
A Red Hat é a líder mundial em soluções empresariais open source como Linux, nuvem, containers e Kubernetes. Fornecemos soluções robustas que facilitam o trabalho em diversas plataformas e ambientes, do datacenter principal até a borda da rede.
Selecione um idioma
Red Hat legal and privacy links
- Sobre a Red Hat
- Oportunidades de emprego
- Eventos
- Escritórios
- Fale com a Red Hat
- Blog da Red Hat
- Diversidade, equidade e inclusão
- Cool Stuff Store
- Red Hat Summit