vSphere 7 and Kubernetes - CTO Advisor Episode 118

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, you're listening to, and maybe I'll publish this as a video too, because we're doing this over Zoom, episode 118 of the CTO Advisor Podcast. I have with me a CTO DOS host, Joop Pisker. Joop, how's it going? It's good, man. How are you? Pretty good. Thanks for joining me late in your afternoon, almost evening there, right? You're in the Netherlands? I am in the Netherlands. m. here, so we're all good. So quote, unquote, almost the end of your day.

You're also an entrepreneur, so the day really doesn't end, technically. So thanks for joining me at the end of your day. So both of us virtually attended VMware's vSphere 7 launch, I don't want to call it the launch event, because they had a launch event, and then they have something else, and we'll talk about that a little bit later on, around April 1st. Let's call it their launch addendum, tech field day 21, hosted by Gestalt IT, which they had virtually. And VMware went over a lot of great stuff with vSphere 7, what they're doing, and technically how they're going to achieve it, and we'll get into that.

But first, before that, I wanted to set up kind of the landscape of the overall market. Where are you seeing the movement of containers versus VMs versus cloud-native type services or cloud services directly? Yeah, so, I mean, we all know VMware from virtual machines, right? People figured out a way to not have to buy those big, ugly, physical boxes for every new application, and we've been doing that for the better part of a decade, maybe even longer. And so VMs are kind of the standard way of deploying applications, at least in your own on-site data center.

But with the rise of containers, you know, the use of virtual machines became some kind of discussion, right? People were starting to discuss, do we need VMs, are we going to go full-on to containers, or maybe even go fully into cloud, into cloud-native development techniques? And so, you know, the discussion right now is kind of, do we still need a virtualization platform? Do we need VMs? And that's, you know, that's a discussion I think that is far from over. It'll take a good few years before we even see the end of the containers versus virtual machines discussion.

That'll be undecided for quite a while. But containers do have their, you know, their use cases, especially if you go into developer environments where it is easier to deploy a container than it is to deploy a virtual machine. I mean, it totally makes sense, and I get that VMware sees that as a threat for their business model. I mean, VMware is still mostly the virtual machine company, while they do have a bunch of other products, most of them cater to that virtual machine world.

So I totally get that VMware is seeing the threat of containers, and they have been for a longer while, but VMware is the big infrastructure company that, you know, everyone knows and everyone likes. So with vSphere 7, I think they are kind of looking for removing part of that discussion by removing some of the differences between a VM and a container from that operational standpoint. You know, it shouldn't matter too much for a VM admin if they are deploying a virtual machine or if they are deploying a container or maybe something else, right?

Who knows what VMware will come up with to run on their platform. So I do see VMware moving into a space where it shouldn't matter too much what you're deploying, you know, be it a VM, be it a container, be it an application packaged by a third party or maybe the ISV itself. I haven't played too much with vSphere 7 at all, maybe you have, Keith. But from what I've seen, it is, you know, it is not easy at this moment to get it up and running.

I think the product will only launch in about a week. So we'll have to see what the first couple of experiences from the field are going to be. So we'll get into kind of what my impressions are from a technology perspective. You hit on a couple of key points, I think. If you're thinking about this from the VI admin's perspective, yeah, compute is compute. Whether it's compute, whether the wrapper is a VM or the wrapper is a container, it's storage, compute, networking, security, and configuration management.

That's kind of the VI admin's world, where CTOs and VP of infrastructures, et cetera, and VPs of application development start to care is when you're talking about the design around application development, how you want to consume it. You mentioned, you know, developers may care about using a container because a container is easier to develop on and it's easier to package and then hand over to operations. It's that simplicity or that ease of use that I think VMware and companies like VMware are starting to look at and feel a little bit threatened, especially when you look at stuff like Qt, Vert, which allows you to put virtualization VMs into containers.

I recently wrote something for TechTarget on the topic. It should be published in the next couple of weeks, but based on my research, the idea has been, yeah, I've made the decision to go all-in containers, and if I'm going to go all-in containers, I have these components, these VMs that I can't get rid of. For example, a ISV appliance, like a VNF, virtual network functions component that can't be containerized, and it has to run in a VM. So Qt, Vert is, you know, it's a nice solution to take care of those problems.

So from a philosophy perspective, it really does matter whether or not you go containers or VMs, and I think you make this point that VMware is answering that challenge. In theory, with vSphere 7, it really doesn't matter. If you have your physical underlay or your logical underlay, VMware can organize that underlay and orchestrate it using vSphere 7, and you can use containers or VMs, whatever you want to use from a compute abstraction layer. Yeah, and that's it, yeah, yeah, because, I mean, again, from looking at the use cases, you know, companies still have their on-prem data centers, and they should be able to use containers, they should be able to use virtual machines or even serverless workloads, for that matter, because they do have the infrastructure, right?

Why limit the investments you've made with VMware and your old data center if you're only going to be able to run virtual machines? So let's talk about the technology. First off, let's start with how it's packaged. I'll defer to you. I was a little surprised about the packaging of what VMware delivered versus what I heard. I think I injected what I wanted to hear at VMworld when they announced it versus what they delivered. Am I the only one with that impression?

No, I am completely on board with that same impression. So I came out of VMworld with the impression that VMware had once again created a lean and mean solution, and, you know, just like they did with ESXi Hypervisor, you know, it's small, it's easy to install, it's not complex. So operationally, you know, it is something that you would want to use because you don't have to spend so many cycles on managing and implementing it. And so I came away from VMworld with that same impression.

Project Pacific, you know, Project Pacific and the runtime engine that would run containers was going to be integrated into ESXi. So my impression coming out of that was this is going to be lean, this is going to be mean, this will mean no changes to existing environments, other than, of course, doing the version upgrade itself. But as, you know, time progressed, we heard more and more, especially in the last few weeks, I was kind of shocked to see the packaging and to see it have expanded so much beyond just core vSphere, because you have to run vSAN, or you have to have a storage solution, you have to run NSX, and especially in the first versions, it's going to be really limited.

So it's going to be really hard to implement in existing environments, right? Because those may or may not adhere to those limitations that VMware set. There's so much you need from an architectural standpoint, that it makes the number of deployments feasible to do in a version one, you know, fairly small. And I worry that the packaging is going to be, you know, it's going to limit VMware in the number of implementations they'll see for that first version. So this isn't new in software development.

I mean, if I think about the beginning of VMware, the precursor of the vSphere, ESX. ESX, without the I, fairly complicated. maybe I'm romanticizing the time period, but I felt ESX, less complicated. To be fair, this is a really, really hard problem that VMware is solving. When they first brought Nesera into the fold and they announced NSX-V, I was very disappointed that they went the NSX-V route instead of, you know, just biting the bullet and going NSX-T and releasing NSX-T to general availability, eventually got there.

and VMware doesn't like it when I say this, but go after the very large customer. And after the very large customer, you know, kind of works out the kinks, then bring it down market. VMware has told me that, no, this isn't about just the very large customer. This is about anyone who wants to leverage vSphere 7 to optimize container and virtual machine hybridity. And I guess I can say, to be fair, yeah, sure, if you want to go out and buy VCF, yes, you can, absolutely.

And VCF, VMware Cloud Foundation, is the licensing scheme that you have to purchase to get the Kubernetes experience. VMware's Kubernetes experience, which is called Tanzu Grid. In order to get Tanzu Grid, you have to go out and buy all the licensing from VMware for vSAN, NSX-T, vRealize, and vSphere. And we talked about the requirement of why we need vSAN. VMware wants to ensure stability, I think, was their word. So you don't have to use it for your storage provider and permanent storage in your Kubernetes workloads, but you have to use it for the management domain.

So that limits it to kind of like the really big customers. That tells me that implementation is probably not where VMware wants it from a ESXi type of experience. Have you played around with the beta bits for what was known as project specific yet? Yeah, I have. And it's just like you said, right, you have to install a bunch of extra things like a storage layer, networking layer. And, you know, given that Kubernetes itself is fairly complex, I get that there's a couple of limitations and requirements around networking.

But even, you know, even in those cases, I mean, Kubernetes is supposed to kind of be that central, you know, central industry interface for people to communicate on the application layer. And so it shouldn't necessarily be so difficult to have that underlay, that infrastructure be a lean and mean solution. And, you know, I think that we've come up to a point where, you know, I agree, this is going to be for the big customers, right? Little customers will probably not run the VMware Kubernetes experience on prem.

They will go and, you know, use other solutions out there from a cloud vendor, maybe from a managed service provider that offers this. But, you know, if you want to see this kind of come downstream, eventually there should be, you know, that it should be back to basics. It should be the way that VMware used to be, you know, at least after the vSphere or starting with a vSphere for four days where we have that ESXi hypervisor. Things were fairly simple yet again.

So, yeah, I'm not sure how it's going to be. And I guess that goes back to the announcement when Pat announced this whole Kubernetes experiment. In my mind, I picture because they painted a really great picture. You have you're going to have containers that are equal citizens to virtual machines. When I heard when containers are equal citizens to VMs, I heard base capability of vSphere will be the ability to support containers. So that that CRX daemon that they're using to run the pods would just be available that if I wanted to deploy ESXi host, I put in a key and I have access to the Tanzu grid, which is the platform for running, which is the Kubernetes distribution.

What it turned out to be is, to your point, you know, this whole SDDC, this whole software defined data center design is a very opinionated version of the SDDC. I can have an SDDC that has NetApp storage, virtual switches without NSXT in this environment that VMware will bless. Yes, that's the software defined data center as we defined it versus this VCF version of it specifically for Kubernetes. VMware has said that they'll ease the requirements like dropping the requirement for vSAN. I think if you're looking to deploy Kubernetes in a VMware environment, NSXT just makes sense.

Kubernetes networking has never been that great out of the box. So you do need an additional experience. So if you're a VMware customer, it makes sense to embrace NSXT as the model for networking. But just in general, I just feel like I fail for the marketing. Like, yeah, what was going to come is not exactly what we get. Yeah, I agree. And, you know, there's another point to the, you know, this is not suitable for smaller scale deployments, right?

The fact that you have to have... Yeah, but I don't think it makes sense in the long run. I mean, they better make sure the kinks are removed from this first version and make it available on a more logical scale. Because, you know, to be fair, I think if they want to be successful with Kubernetes, the experience should be so integrated, so great that, you know, there's no reason to go to a different provider. Because Kubernetes, you know, for lack of a better word, has become a commodity.

There are so many players out there that, you know, if I were, you know, if I were to work at a customer, I would definitely look at the experience, the ease of management, the cost of it, the technical complexity, the requirements on a technical level to, you know, to make sure I don't have to spend as many cycles in managing this. And, you know, that's where I fear the complexity of Tanzu and Project Pacific is going to be a problem for VMware. So I think we're both on the same page when it comes to that.

I think the promise and the potential is for enterprise customers, specifically large enterprise customers, to never ever have to say, oh, should I consider some other distribution to manage compute for me? No, VMware kind of has taken care of that for me in my base licensing. I'm already buying a bunch of VMware stuff, and I just happened to get Kubernetes, which is no big deal. And VMware, to the credit of VMware, some of the things I really love about vSphere 7 outside of Kubernetes is the introduction of namespaces.

So as I'm thinking about CICD, application development, managing network compute and storage in a cloud native framework, the addition of namespaces was a requirement that one is going to take VI admins a little bit of time to get up to speed to. But once they're up to speed, the ability to do these Kubernetes-like functions may surpass even the need for most environments to even have Kubernetes to begin with. 0 software. Let's leave the audience. If you're a VMware customer and you need Kubernetes today, where would you put VMware in that discussion with what you've seen so far?

I mean, Kubernetes solves a different set of problems, right? It doesn't solve necessarily any infrastructure problems. It solves development problems where you need to have a platform to deploy applications, but with the speed of the developer taking care of their requirements and their wishes. So if you have a Kubernetes problem right now, you probably don't really have a Kubernetes problem. You just have a people problem because they all want Kubernetes. But really what they're saying is I want to deploy in my own containers and I want to do so without security and without operations and all those people breathing down my neck.

So A, you probably don't have a real Kubernetes problem. You may have a people problem. You may have a scalability problem, but you probably also have a self-service problem. That's what cloud solves for so many people is the ability for a developer or an engineer somewhere in the environment, somewhere in the organization to go and solve their own problems. So my best bet is to start looking at your existing environment, whether that's VMware or something else, and make sure that the people using the platform are actually able to use it for themselves without opening a ticket, without waiting for two weeks in a queue.

Make sure that everything is self-service on demand. And if you need Kubernetes to go to do that, you know, totally fine. Go that route. But there are so many other options, even within the portfolio of VMware, to solve those problems. So, Joep, where can people find you on the web and your company? nl. That's my blog. And on Twitter, my handle is at JPScar or JPScar. Just Google me and you'll get there. My spelling is hard.

That's it for this episode of the CTO Advisor. com. You can find the podcast in your favorite podcast application. Hit me up on Twitter with any questions at CTO Advisor. Talk to you next, CTO Advisor podcast.