What is the fundamental VMware software stack, and how do you go about modernizing from legacy architecture to VMware on IBM Cloud?

Sai Vennam and Jordan Shamir break down the components of IBM Cloud’s VMware software stack and show how a customer would go about modernizing from a legacy architecture infrastructure to something like VMware on IBM Cloud.

Learn more

• IBM Cloud for VMware Solutions
• VMware: An Essential Guide
• What is Application Migration?
• Application Modernization: An Essential Guide

Video Transcript

Sai: We’ve got a few things already sketched out on the board, but let’s actually start with the stack that we need to get started with, you know, modernizing with VMware.

The fundamental VMware software stack

Jordan: Yeah, in IBM Cloud, kind of our basic or fundamental VMware software stack is quite simple, right? You have your bare metal infrastructure, where your environment runs on—so bare mental infra.

And then on top, we have your vSphere—and so we actually do automated deployments of 6.5, 6.7, and any future releases from a VMware perspective.

We have NSX, which is the VMware networking tool. And sitting on top of that—kind of the brain of the whole operations is vCenter.

And when we look at this, this is just the very basic, fundamental stack—there’s tons more components that you can add. For example, you can add vSAN, which is the storage option, as well as any kind of Day-2 operations on top of the stack.

Sai: Gotcha. So, for an end user who’s coming in and they want to get started, they could just go directly with vCenter, and IBM will kind of automate and take care of the rest of these components, get them all installed?

Jordan: Absolutely, everything we do is from an automation perspective too, and we understand people have different requirements, right? I talked about vSAN earlier—you know, customers prefer other types of storage compared to vSAN or they want to use other networking tools, so they don’t actually even need to use NSX, it’s just an option and kind of what we do from a stack perspective.

Modernizing from legacy architecture to VMware on IBM Cloud

Sai: I see. Okay, so we’ve got a number of things already sketched out here, like I mentioned, and we want to show and really break down how we modernize from, let’s say, legacy architecture infrastructure to something like VMware on IBM Cloud. So, we’ve got some things sketched out—can you kind of talk through what we have already?

Jordan: Yeah, absolutely. So, I think one of the things we were talking about earlier today was modernizing means a lot. And one specific use case I want to look at is modernizing from legacy hardware and legacy software and calling out VMware HCX.

So, HCX is a migration, hybridity, modernization tool, whatever acronym you want to put with that. And so, it allows customers to actually migrate from vSphere 5.1—which can be running on any hardware you want, and this is an old software stack.

And so, the nice thing that it allows you to do is actually create a connection where you can actually go from old hardware in 5.1 into the newest hardware in 6.7 and whatever VMware is going to be releasing in the future.

And how it does this, it actually makes a kind of a loosely coupled network, which allows you to, essentially, just stretch your network. And that’s the really cool thing—through kind of stretching your L2 network, it allows you to create these connections where you can bring your own IP, you can bring your MAC addresses, and the nice thing since you’re bringing those backwards and forth, it really provides us true hybridity or multicloud approach. 

Sai: So, essentially, all the connections that the applications may have had previously—so IP address dependencies and those kinds of things—you don’t really have to worry about refactoring or breaking all those down since you’re bringing your own IP, since you’re kind of having that that model, those applications continue to work with each other even though now, you know, parts of them are on the cloud.

Customer use case

Jordan: Absolutely, and one kind of story from one of our customers that I love to talk about is, you know, we had a customer running on vSphere 5.0, on old hardware. They were in a data center in California and they were looking to try VMware on IBM Cloud, and they actually moved that application from California all the way to Washington D.C. 

So you’re talking across the country, and so, obviously, with that, they increased latency compared to the other VMs in their application, but that application actually ran better in IBM Cloud, even though it was in Washington D.C., because it’s running on a latest software and hardware version compared to what the customer was running on-prem.

Sai: So, the advantages in the compute basically outweighed that the disadvantage of having latency across the country.

Jordan: Exactly. And so, that’s just kind of one of the use cases we really like to look at because what HCX allows you to do, it cuts this notion of—hey, I’m in a monolithic or in you know legacy app, you know hardware applications, I can’t move. HCX eliminates that by really providing that backwards compatibility where you can take everything you have existing today and move it into your future state.

Sai: Right. So, in this kind of example we can probably say this layer right here, or at least HCX is enabling that, excuse me, that translation. 

Moving assets with HCX

So, kind of moving forward, let’s say we have that that hybrid model on-prem and on the cloud—what if we wanted to start moving some of these assets? So we want to move those database pieces and put them over here—is that is that something that HCX would help me do?

Jordan: Yeah, absolutely. So the beautiful thing about HCX is it allows you to move when you choose, right. I can group individual VMs; I can do a live migration; I can do you know planned migration; and it ultimately depends on what the customer is looking for. 

But, really, the thing that we see with HCX—and you know any migration tool—a lot of it is analysis paralysis, and with what HCX allows you to do is, it allows people to feel comfortable because you can start moving one VM, two VM, and start building up the comfort of moving, you know, back and forth. 

Sai: Right, definitely. So, you know, with HCX I can run this for, let’s say however long to make sure it’s stable, we’re not having any downtime that, you know, critical business workloads are continuing to run, and then once we’ve kind of already we can start duplicating some of these assets, right? So maybe run some of those DB pieces over here in the cloud, and I would guess, eventually, even think about phasing this portion out. 

Jordan: Absolutely, yeah, and it’s all a matter of what the customer is looking for, but if you think about from a data consolidation or a data evacuation use case, that’s exactly what we see with HCX—you take what you have existing from an IP parameter and the nice thing you can move to the cloud, if it doesn’t work you can move it back, but if it moves it runs better—you can actually shut down your own data center and save, you know, a significant amount of cost, but also get you to where you want to be, right? Cloud or multicloud environment.