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! For the original post on the Red Hat Enterprise Linux blog, please see here.
Hope this helps,
Jon Benedict / Captain KVM
Connect with Red Hat Consulting, Training, Certification
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Training on Twitter
Like Red Hat Training on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.