There’s still a considerable disconnect in data centers of all sizes between capacity planning (where systems are designed to support workloads) and workload optimization (where workloads are designed to support systems). You’d think the two would at least be willing to meet halfway.
For the marriage of Red Hat and IBM to progress smoothly, the hardware maker will need to take even further steps to adopt the software maker’s definition of “platform.” Red Hat’s containerization platform is OpenShift — essentially branded Kubernetes, plus Red Hat’s workload implementation and deployment systems, and Red Hat Support. Last March, as our Christine Hall reported, parent IBM opened a few more pathways for OpenShift to be deployable on IBM’s Power processor-based servers, which some analysts say still represents about 6 percent of the worldwide server market.
Red Hat, for now, seems to be the party taking the boldest steps. On Tuesday, the company lifted the lid on its Red Hat Migration Toolkit for Virtualization (MTV). It’s a bridge to the company’s platform for hosting all varieties of virtualized workloads, including the hypervisor-driven, first-generation kind, while enterprises take what it still characterizes as necessary steps towards implementing more efficient, more powerful containerization.
It’s a transition platform, remarked Red Hat’s senior director of product management James Labocki, speaking with Data Center Knowledge, for organizations that have pretty much had it with transitions.
“We definitely see people getting tired of hearing about ‘digital transformation,’” admitted Labocki. “The sysadmins and developers who actually have to do the work, kind of shrug their shoulders and say, ‘Okay, I don’t know what that means. Tell me what it practically means.’”
This is not Red Hat’s first migration toolkit, but this particular one is geared for the enterprise that knows the transition to efficiency will not happen automatically. Rather than a “wizard”-based system that pops all your VMs into bite-size, Docker- or Kubernetes-style containers, Tuesday’s entry is directed towards businesses whose IT operations may need to undergo cultural shifts, if they are to take full advantage of the container management lifecycle.
Why does IT need another cultural shift? Didn’t we just get through with the last three or four? Then there was the pandemic. Can’t IT get a break already?
Organizations may be trying to give IT precisely that, explained Labocki. They’re planning their IT initiatives, he said, more and more on a very simple X/Y chart, where X represents effort, Y represents payoff, and the objective is to get as close to the upper right quadrant as possible. “Rehosting might be the lowest amount of effort, to simply take my VM and move it into OpenShift Virtualization,” he said.
“But it’s going to provide, most likely, less benefit that re-platforming and refactoring,” he continued. “That’s okay, because there might be certain business or technology drivers that are still pushing them to move to OpenShift or Kubernetes, in general, faster — whether that’s, other container orchestration platforms starting to fall down, and not really have the same amount of innovation as Kubernetes. Or business drivers, or developer philosophy, where they want to get a hold of this virtual machine, and put it into their GitOps model.”
Before we start sounding less like Data Center Knowledge and more like The New Stack, let’s break down what Labocki is saying: Six years ago already, Docker demonstrated for the first time that workloads could be deployed to the cloud virtually, without the need for a heavy, hypervisor-driven platform. Immediately, the migration to containerization was declared both inevitable and under way. But there was no obvious way to make this happen. Docker worked on a deployment and management platform called Swarm. Meanwhile, Google began preparing its Kubernetes platform, and released it to an open source incubator: the Cloud Native Computing Foundation (CNCF).
Perhaps the latter had the superior container orchestration system (some still say no). Nevertheless, within a few years, the container ecosystem belonged to Kubernetes. Yet there remained no clear migration path. CNCF’s Executive Director Dan Kohn (who sadly passed away last November) was advising organizations to just try wrapping their VMs in a container and see what happens. It’s a method even its proponents call “lift-and-shift,” and it may not yield the full benefits of refactoring and re-architecture, but it could yield some.
At least, that was the theory. Today, it appears, those organizations that were willing to try lift-and-shift, may have already done so. So was Kohn wrong after all?
“I think it really comes down to, how much time someone’s willing to invest,” responded Red Hat’s Labocki. “Moving that VM into a container, one of the challenges has been, when you have a security vulnerability come out and you need to patch that, or you need to update the application for functionality reasons. A lot of times, when you move that into a container, your whole process needs to change as well.”
To this day, however, some software vendors are unwilling, or unable (especially if they don’t exist anymore) to help their customers re-factor their own applications for containerization. “I’m not trying to play the fence here and say, ‘It depends,’ but I think it really does depend. There’s not one trend that we see across every organization for taking a single path through this.”
Especially in situations where data centers orchestrate applications using the 1990s-style client/server model — which typically involves middleware — many “monolithic” applications cannot, and should not, be lifted-and-shifted to containerization. However, they can conceivably be relocated onto a single virtual infrastructure platform that supports both varieties of virtualization, in order that they may… co-exist peacefully, at the very least. That’s the model Red Hat is aiming for with this latest incarnation of MTV.
General availability of Migration Toolkit for Virtualization began Tuesday. Because we value our readers, we’ll refrain from making any references to you or anyone else “wanting their MTV.”