Where do you start your cloud-native journey - CTO Dose 78

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

All right. Welcome to episode 78 of the CTO Advisor. See, Mark, I got us back on track. I thought you were going to stop doing that, man. No, you know what? I took a sheet of paper. I wrote it down. And it's working out well for me. You know, it's like a word of the day calendar. It's what you need. Like a word. Rip the number off. Or a ticket taker at a deli, that's what you need.

So last week, we had on a very high profile guy from the entry, Greg Nierman. Great conversation. Go back and listen to that conversation on private cloud and kind of the definition of private cloud. We're going to continue the private cloud conversation a bit. But we got, it's funny that we're saying this now, but the 800-pound gorilla, when it comes to private cloud conversation, it's crazy. Right before the podcast, Mark, we were just talking with Dom Delfino, how quickly VMware has grown.

And they're now the big kids on the block. Dom, can you go ahead and introduce yourself? Hey, Keith. Thanks for having me here today. So Dom Delfino, I'm the Senior Vice President of Software Defined Data Center for VMware Globally. So Dom, we had our good friend from Hitachi on the line last week, Greg Nierman. And Greg is famous in the industry for promoting private cloud. I have a love-hate relationship with the marketing term private cloud. I most definitely believe in private cloud, but not necessarily the way that it's been marketed.

VMware has had this software defined data center strategy for years. Can you help share some light on the definition or the use of the relationship of software defined versus private cloud? Can you clarify that for the audience a little bit for us? Sure, sure. So Keith, like you, I tend to hate marketing terms myself here. So I think really the two sort of go together. I think it really depends on what you decide is the appropriate architectural approach to build your private cloud, or infrastructure as a service, or really your private data center architecture off of.

And what we mean by software defined data center is that you have this sort of abstraction layer that sits above the hardware infrastructure that really gives you sort of a common plane to program the resources behind it based on what you need in an on-demand fashion, right? So VMware has obviously been doing this since its inception at the compute layer. Now it's about bringing compute, network storage, security, operating together as an entity of one, as a set of pooled resources, and control via this virtualized abstraction layer that we call the software defined data center.

And ultimately, we think the thing customers are struggling with right now today is that you have to have a private cloud that's as good, as fast, as easy to use, and easy to consume, and reliable as the public cloud offerings out there, right? Because ultimately, hybrid is the real strategy. Not many businesses are going to go 100% all into the public cloud providers. And there's going to be a lot of reasons for that, intellectual property protection, regulatory requirements, data sovereignty, et cetera.

So really, I call it now the world of cloud reality that customers are facing right now. And they're starting to get this. And then it becomes, what's the right architectural approach for that customer? And we certainly believe that the software defined data center gives them the ability to do what the public cloud providers have been doing for years. But they hired thousands of developers to build it themselves. Obviously, most traditional enterprise and public sector customers can't do that, right? They're hiring developers to build line of business applications for their business.

So what VMware does is take all those great things that Google, and Azure, and AWS built for themselves, and we bring it to market. And we make it available and consumable by the mass market. So Mark, jump in here. I mean, you deal with this all day, every day, all day. This is like right up your wheelhouse. Is VMware on the right course? Not just VMware, but the larger industry. VMware isn't the only company playing in this space.

We have HPE driving heavily as they start to redefine what they are and their mission. And brokering cloud services is one ideal of it. And they're composable infrastructure with Synergy. Cisco has forever tried to crack this nut. Are enterprise vendors on the right track at solving the problem that you want them to solve? I think they're getting there. I think if we look at things like where vendors are presenting me a stack, and that stack is integrated with multiple cloud providers and bridges that gap between what I already have today, what I am going to likely consume in the future, and gives you that single viewpoint into all of it as a stack.

I think that's, in the end, what I want. I don't want to have to build my own stack. I want to buy a stack. So let's talk about that buying the stack perspective. So these are some very, I think, complementary visions, but at the same time, different. Let's take, you know, we had Jeff from, I'm sorry, Jeff Snover, right? Yep, Jeff Snover, the chief architect for Zur Stack on a few months ago. And he talked about how Azure is public cloud in your private data center.

And it is a very different solution than, let's say, Greengrass running. And Greengrass is an AWS technology running inside of VMware vSphere on your data center versus even VMware Cloud on AWS is yet a different thing. And I guess the question is to you, Mark. From a priority perspective, where do you see the priority and the need? Like, if you were to talk to a vendor and you say, OK, if you want me to open my checkbook and say, just take my money, what's the vision that you would want to buy from them?

Well, in the short term and long term, right now, I need a better handle on resources that we provision in a public cloud, right? When my developer goes, swipes his credit card, I need a better handle on that and a way to govern and predict that. And theoretically, some levers to control that would be even better. That's a very immediate need. My actual strategy, though, is just an overarching thing that's all of it, right? In a perfect world, I log into one thing.

It's probably externally facing. And it can orchestrate my on-prem and my various cloud workloads. You're not going to get to that day one, right? This is a journey, and you've got to start somewhere. So I think people are on the right path, but I think it's a long journey. So Dom, how does that mill with what you're seeing as you talk to a broader swath of customers? Does that mill in kind of what their priorities are as well? I think Mark said it excellently.

As a matter of fact, I was at one of the country's largest air carriers office the other day when we were speaking exactly to that, right? Where they want a single pane of glass that they go into, and they consume resources. And that system on the back end determines where the right placement of that resource is based on availability, cost, capacity, et cetera, so on and so forth. And it's transparent to them. And that's what I'm really referring to as cloud reality.

It's a hybrid strategy. You're going to have some resources in your private cloud. You're going to have public cloud offerings available to you. And you sort of want that control plane really to dictate where those resources are provisioned based on a variety of criteria if you're a customer, but you want it to be transparent to the end user, application developer, or application owner itself. You don't want them to have to worry about infrastructure. And I think that's been the biggest driver of this at the end of the day is, you know, Keith, the pecking order in this world, whether we like it or not, is the business requirements define the application requirements, and the application requirements define the infrastructure requirements.

So at the end of the day, as infrastructure people, which I am and have been all my career, is my job is to serve at the pleasure to the application developer and application owner. And they want it to be, they want infrastructure to be a consumable. They don't worry about storage, compute, network, security. They look at infrastructure as an entity of one, and that's sort of how we have to be able to serve it up to them. Yeah, and I think this, one of the, I just got to talking to a Fortune 500 who wanted to engage the CTO advisor to help on the whole DevOps journey.

And one of the things that they ran into culturally, they're just stuck. They look at the thing, they have all of the major vendors in from VMware to Dell to Cisco, everyone in, and the technologies they understand. And Mark, you've dealt with this, and we've talked about this a lot. Where do you start? Like, we understand that we want to build the, we want to build infrastructure that supports the application. I completely agree with Dom on that. What I get frustrated with when I talk to application teams, when I talk to the business, is that every time I build something, we can go back four or five years and we started this journey with Eucalyptus, OpenStack.

You know, we're getting into Docker Swarm, containers, trying to convert our VMware stacks into cloud native consumable stacks. And it seems like we just can't keep up and provide the development teams what they're asking for in the short term. Where should people start, I guess, is the question. Well, I think that is where refactoring your app has to play a role. As long as you're just trying to take your existing workload and shove it to a different location, you're always going to be fighting those requirements.

You really have to get to a point at some point when your application doesn't care where it runs. Until you get to that, you're constantly going to be saying, okay, you know, containers were great, now I need, you know, serverless. Serverless was great, but now, you know, what I need is big orchestra, I don't know, whatever. So eventually, to take advantages of the agility that the cloud provides in a perfect way, you're going to have to rewrite your app or find a way to refactor it.

So again, some pushback on that. When you say rewrite the app, you know, I just wrote a post on Netflix's container journey. Netflix, poster child for DevOps. They moved from a DevOps environment built on VMs to a DevOps environment built on containers. And they had this problem that they built these monolithic applications designed to run in VMs. Now, even Netflix has the problem. How do I take that and move it to containers? We have to either refactor the apps or we have to build it.

I'll put it in the show notes. I highly recommend reading up on Netflix's Titus journey. I think what I'm starting to personally come to a realization is that we have to start to choke out or starve out the legacy infrastructure. Yeah, I can take that a step further. You know, what Dom said was business requirements dictate application requirements, dictate infrastructure requirements. I think we're starting to realize in infrastructure that we need to focus more on business value. But I think some developers are still in that mindset of, I want to play on a container because containers are the new hotness.

I want to play on X, which is something that's been pervasive on infrastructure. I think it's finally starting to change. But that cultural change, which technology doesn't fix, still has to be dealt with. Yeah, and I think what Mark has got, you hit the nail on the head with that statement right there. Keith, the most complicated part of this is the behavioral change from your organization, right? And I think you've sort of got the two spectrums of where people are going.

What Mark said is everybody wants to play with the shiny new toy. And then you have the other end of that spectrum is the legacy huggers, right? I can't do this because I still have a mainframe or an AS400 or an RS6000 or an HP9000. And they're architecting their entire infrastructure around that legacy instead of putting it in the box, pushing it in the corner saying, hey, that's important, it's a mainframe, it runs mission critical applications. But I've still got to evolve the rest of my infrastructure in a modernized fashion.

And I can't dumb everything down to the lowest common denominator either. And I think what you see is sort of this vicious death spiral of people can't transfer, you can't transform your technology because you can't transform your people and you can't transform your people because you can't transform your technology, right? And I think this is where surprisingly, as we start to talk about the VMware stack and why we're excited to have you on, Dom, is when you guys first announced VMware Cloud on AWS a couple of years ago or a year and a half ago, it's amazing how fast you moved.

I was one of the naysayers and I looked at it, I'm like, this makes no sense to me. I don't understand the value of this. But as you start to deal with these very tangible cultural issues of where Marcus said, you know what, I need to focus on where there's value. I'm going to offend a lot of my vSphere administrators out there. There's no value in administering vSphere to the business. Mark, you agree or disagree? No, if you're an insurance company, the value is writing policy, has nothing to do with the application, has nothing to do with the server.

The value is what your business user produces that makes money. Everything else is just in support of that. So I think you gotta be careful when you say that because when we're saying there's no business value, we're not saying that that's not an important feature or function of an organization, right? The application has to run. If it needs servers, the servers have to run. Those are very critical and important. But when we talk about business value, we're talking about bottom line impacting services.

So this is something that we talked to the CTO of New York Times about a few weeks ago, which was, you know what, he had this challenge. He needed to get his people out of the business of turning knobs and building applications. So serverless for him provided that opportunity. I think I equate, oddly enough, I equate VMware Cloud on AWS to serverless. I get out of the business of managing physical hardware, the VMware stack layer, and just start consuming that stack as a service.

And now I can start talking about, now I can redirect my internal resources, my most valuable resources to people, the people who can think and solve problems, to solving the harder problems, such as how do I meet the needs of net new applications while integrating it with this legacy stuff, with these legacy apps that I no longer have to worry about or worry as much about the physical underlying. So when you think about what you're saying there, is let's just take a step back.

Let's say, you know, I wanna get people out of the business of turning knobs. Right? I wanna get out of the business of building infrastructure, and I just wanna be in the business of consuming it, right? Or consuming it in a simple way, based on the business needs, the applications that support those, and then, you know, that'll dictate the infrastructure needs. You know, if you're a large, sophisticated enterprise customer, which there are many of them, you certainly have the means, the budget, and the know-how to do it.

The reality is, it hasn't happened because you're stuck in your legacy, right? So if you look at what VMC on AWS, what VMC on AWS is, or the VMware Cloud on AWS is, it's simply our software-defined data center stack running inside Amazon's data centers, right? So you can do the exact same thing on-prem, and I think when you think about it, you've gotta have a little self-reflection as an infrastructure person to say, the reasons application developers have gone around me and gone to the public cloud is because I have failed them.

I have made it too difficult, too time-consuming, too slow, too expensive for them to consume that infrastructure internally, so they've outsourced me, right? And so that's effectively what's happened, right? But the technology now exists there. We have that offering, by the way, we've also got it available via containers, that'll GA Monday with PKS as well, to allow you to build that capability in-house as well. And I think the first thing that's required to do that within infrastructure is to break the silos down.

You can't be the network team anymore, or the compute team, or the virtualization team, or the security team, or the storage team. You've gotta be an infrastructure team because the app developers don't care. Network goes down, infrastructure down. Storage down, infrastructure down. They don't care. They draw application-aligned infrastructure underneath it, right? So that's the vision that you have to have is that whether I offer up this infrastructure as a consumable service in the private cloud or the public cloud, it shouldn't matter, and it should be transparent to my application owners and my application developers, right?

I should be able to offer the same features, the same functions to an extent, right? Obviously, there's a massive catalog of services that you can get in the public cloud from the public cloud providers, but the technology exists now to build just as good as a private cloud architecture as you can get in the public clouds today. Yeah, I would actually take that a step further and say that we need to be an IT team, not an infrastructure team. Right, right, good example, you're right.

Right, because- I was starting at the lowest common denominator trying to break those barriers down first. And that's very difficult from a cultural perspective. The only way I've seen that actually work is by dividing and conquering. Take a few people from each team, you build a cloud team, and you align that with whatever applications that you want that are most critical or most agile or whatever's providing the value to you, and they become the infrastructure team for them. Slowly, old legacy stuff should go down, new hotness should rise up, and you're kind of moving stuff from column A to column B.

So let's shift the conversation over to careers, because I think this is a great career segment on, if I'm on that legacy team, if I'm, and Mark, me and you are both very active in the VMUG community. When we tell VMUG members, people who've earned a great living, getting VMware-certified professional certifications, installing vSphere, investing in home labs, learning the stack from the lowest levels of the hardware to the highest levels of automation, and we tell them that, hey, your legacy and what you do needs to morph, and not just morph overnight, that's a difficult conversation.

It is, no one wants to hear that their job is effectively going away, that's not fun. Right, and it's not just that their job is going away. So Don, the insight that we wanted to get from you is that you run a really large team at VMware, a team that stretches across stacks. How do you help your people prepare themselves for the ever-shifting, you know, from a practical, you know, you run sales. I have to imagine the comp package for selling vSphere has changed over the past five to seven years to now, to what's important to the enterprise.

How do you help your team develop the skills necessary to not just stay, you know, keep the same earning level, you're in sales, so, you know, let's talk about it in sales perspective. Sales guys like to make money. How do you help them move their career as the technology and the culture shifts? Yeah, you know, this is a great question because I think the only thing that is constant in this industry is change, right? So, and, you know, this has been a problem for many, many years where you'll see people who say, hey, I don't really wanna kind of, I like what I'm doing now, I don't wanna go learn the new thing, I'm really good at this.

The people who continue to rely what they're good on and not build skills in the areas that are up and coming that they're not good at, have a going out of business strategy. And I can tell you the only place that that's worked and been successful is for mainframe administrators because so many people have retired and died out of the business, but it's back to being a valuable skill that everybody needs again. So, I think the people who work in technology, if you work for a high tech company, if you work for Cisco or VMware or Microsoft or Dell, you sort of know this, right?

Because you see the changes happening, you know, technology comes in, it gets adopted, it goes through its acceleration phase, it goes through a maturation phase, and then something new comes out. So, if you're a VMware administrator today, you know, chances are that, you know, moving forward, you're gonna be more valuable if you either move up the stack or across the stack. It, you know, kind of difficult to do both, but understanding more about containers and DevOps and app dev, or understanding more about networking, storage, security, how it all fits together is an opportunity for you to build off of your existing skillsets, not about an abandonment of your skillset, but build off of it and get wider and get a broader view of things as well.

And I think that's really one of the things that you have to constantly be in an evaluation of, you know, as you go through your career and as technologies progress, you know, staying static is a going out of business strategy for anybody in this industry. You know, maybe not in the next one to two to three years, but beyond that, it's a difficult thing to do. Or, and maybe it's not a going out of business strategy, but maybe it's not a career progression strategy, it may be a career stagnation strategy.

And I mean, look, if you're a vSphere administrator today, could you learn more about hyper-converged infrastructure? Certainly you're capable of that, right? And, you know, does that now encompass more of not only computing and cloud-like architectures, but also, you know, storage virtualization and DR and data protection and data retention. So you can broaden your skillset, but building off of the base that you already have and you'd invested so much time and energy in. Does that make sense to you? I think what I'm hearing is if you're a specialist, broaden your skillset and be a generalist in some other areas.

Yeah, or if you're gonna be a specialist, you've gotta be prepared to be really, really deep and become a specialist in something different every couple of years. All right, Dom, I really appreciate that feedback. So let's wrap up. Dom, where can people find you online? On Twitter, at Dom Delfino, or on LinkedIn. All right. Love to see you guys. Mark, we'll both be on the VMware campus doing the CTO dose from VMware, so stay tuned for that. Pass the podcast along, rate us in iTunes, talk to you guys next CTO dose or CTO advisor podcast.