Screaming in the Cloud - Episode 66: VMware? VMhere with Sean O’Dell

Episode Date: June 27, 2019

About Sean O'DellSean is a troublemaker living on the bleeding edge of technology and innovation. As a member of the VMware Cloud Services - Solution and Technology team, Sean is responsible for Evangelism, Developer Relations and assists in many GTM functions. Sean joined VCS in February of 2017 and helped shape and launch the set of SaaS solutions at VMworld 2017. Prior roles include Global Technical Lead for Network Insight (vRNI), Sales Engineer Leader for Arkin, VMware Cloud Management SE and CUSTOMER.Links Referenced: Twitter: @theseanodellVMware

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode is generously sponsored by DigitalOcean. I'd argue that every cloud platform biases for different things. Some bias for having nearly every feature you could possibly want as a managed service at varying degrees of complexity.

Others bias for, hey, we heard there was money in the cloud, and we'd like it if you would give us some of that. Digital buy us for, hey, we heard there was money in the cloud, and we'd like it if you would give us some of that. DigitalOcean is neither. From my perspective, they buy us for simplicity. I wanted to validate that, so I polled a few friends of mine about why they were using DigitalOcean for a few things, and they pointed out a few things. They said it was very easy and clear to understand what you were doing and what it took to get up and running when you started something with DigitalOcean. That other offerings have a whole bunch of shenanigans with root access and IP addresses and effectively consulting the bones to make those things work together. DigitalOcean makes it simpler.

In 60 seconds, they were able to get root access to a Linux box with an IP. That's it. That was a direct quote, except for the part where I took out a bunch of profanity about other cloud providers. The fact that the bill wasn't a whodunit murder mystery was compelling as well. It's a fixed price offering. You always know what you're going to wind up paying in a given month. Best of all, you don't have to spend 12 weeks going to cloud school to understand all their different offerings. They also include monitoring and alerting across the board, and they're not exactly small time.

Over 150,000 businesses and 3.5 million developers are using them. So give them a try. Visit do.co slash screaming, and they'll give you a free $50 credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Welcome to Screaming in the Cloud. I'm Corey Quinn. I feel the need to point out at the beginning of this show that guests are always invited to speak.

Sometimes people suggest themselves, but it's always something that's based around whether or not it makes sense, whether there's a story I think is there. You cannot buy your way into being a guest on this show. Bearing that in mind, please welcome Sean O'Dell, developer and cloud advocate from VMware. Welcome to the show, Sean. Thanks, Corey. Glad to be here and looking forward to the banter today.

Absolutely. And the reason I feel the need to caveat your presence here is that lately, VMware has been on a little bit of a buying spree. You've acquired a bunch of interesting companies that we'll get to a little bit later. And it's very strange. It seems like a company that is moving very determinedly in a particular direction, but it's not clear what that direction is. So what is VMware and what do you folks do? Yeah, absolutely. So VMware, historically, right, I think everybody knows VMware is vSphere or ESXi, right? And it's prime 86% of the hypervisor market, you know, VMware owned it, I think was the highest number,

kind of the crazy number that we saw. And then from that, we built an ecosystem around, obviously, with plenty of partners. But then, obviously, VMware went into the hybrid cloud management space with the vRealize stack, went into the end user computing space and mobility with AirWatch and some of our own solutions. Obviously, AirWatch was another acquisition we made. And then I think kind of the two pivots before, or I guess maybe the last pivot before we talk about what we're going now is into the networking and security space, right? With the acquisition of Nythera

and a few other things around them. And really, VMware solidified kind of the next generation data center, if you want to call it that, and then ultimately the hybrid cloud. And now, I think if you go back to VMworld two years ago and then solidified last year, both in U.S. and Barcelona, is becoming a multi-cloud company. So no longer focused purely on the vSphere hypervisor. And so that's a little bit nervy for a lot of folks. But at the same time, we firmly believe, because our customers are telling us this,

is that they are becoming multi-cloud companies, right? So we need to be able to support AWS, Azure, Google, just as well, or treat them as first-class citizens, just like we do vSphere. So that's kind of the future direction. And obviously we can talk a little bit about Kubernetes as well or treat them as first-class citizens just like we do vSphere. So that's kind of the future direction. And obviously, we can talk a little bit about Kubernetes as well. So if I take a look back, I've been seeing VMware in the marketplace for about 20 years, give or take.

I consider you folks the beast of many products. And instinctively, that sort of got me stuck somewhere where I think of you folks as cutting-edge technology from 2002. If I'm being less charitable, I've referred to you as the payday lender of technical debt. And I wouldn't have had you on the show if I thought that this was a truism and there was no value in anything that you were going to say that would not go to change my mind. And even before having you on this, I've started to find that my own view of your company is starting to change.

I will admit that you folks do have a serious problem of taking random words and putting the letter V in front of them. That's a little okay. I get it. Branding, it's a thing. But let's start with what we, I guess, what you just alluded to. There have been a number of interesting companies that you've acquired. Most recently, you have Wavefront, Heptio, or Heptio, however they want to pronounce it, CloudHealth, and Bitten AMI, which some people mispronounce as Bitnami.

So the easy and facile answer is that you've acquired these things just to ruin them, and you're this decade's Symantec. I imagine, based upon conversations with folks at those companies, that there's something else in mind. What is, I guess, the vision of the future as you see it? Yeah, 100%. And I would also argue we are not a mainframe company. So we're not that old in legacy. No, just kidding.

No, that would have been the 70s or 60s. Exactly, right? So you got the 30-year advance, right? Now, to be very clear, Corey, VMware solidified itself, right, as you mentioned, in the private cloud, hybrid cloud, in the vCloud, if you want to call it that, right? And I think as an organization, obviously top-down, we realized our customers were moving to the public cloud, right? They were moving to Kubernetes or cloud native architectures in a lot of ways. So it was either stay in the past and only support vSphere or move to the future while continuing to improve vSphere, right? And I think we probably won't get into it a lot today, but we now have partnerships with Amazon,

Azure, Google to run the vSphere hypervisor in their public cloud. Right. So that, yes, your partner strategy looks a lot like AWS is product strategy. It's a post-it note that says yes on it. And that's about it.

I mean, again, again, given what you do, that's not a terrible decision. The challenge that I see is that the selling point for VMware in a modern day cloud, and maybe I'm misinterpreting this, has been that you can take whatever VMs you're running today in your data centers and, without changing a thing, move them seamlessly into public cloud providers. And that is a thing that occasionally is extremely useful as a component of a larger vision, as a transitional step, but rarely as an end goal in and of itself.

And it almost feels to a number of folks out here that that story is more or less kicking the can down the road yet again on modernizing a legacy architecture that fundamentally will not do well in a cloud environment. If you have a specific virtual machine that if that goes down, so does your application, that's an architectural problem that is going to become much more pronounced in a public cloud environment than it likely will in your on-prem environment. And a lack of awareness around that or trying to paper over that idea seems to be doing, in some respects, the industry a bit of a disservice because people believe what you say. You're VMware.

Your words carry weight. So let me answer this in kind of two parts. I'll actually address the kick the can down the road, right? I'm not a huge fan of the term. I think I understand where everybody is attempting to drive with that. asking for ways to utilize the resources, the knowledge, the historical utilization, consumption, you know, understanding of the VMware ecosystem in the public cloud, right? And that's only part of the picture, right? If we only focus there, sure, maybe you could say, well, yeah, they're just kicking the can down the road.

They're trying to be, you know, the same thing they've been for 20 years and not really modernized. But what most people don't understand, or I guess we haven't done the best job of articulating, is while we're continuing that strategy, we have invested heavily in this idea of instead of using the vSphere hypervisor everywhere, why don't we provide things like operations management, visibility, cost analysis, security on native public cloud workloads, right? So consuming those native public cloud workloads and making sure, you know, really based upon customer desires, needs, concerns, that they are meeting enterprise standards.

You know, oftentimes you talk with customers, give one customer specifically, obviously without naming names, but in their case, they have a vSphere team or a VMware team that runs their private cloud, hybrid cloud on vSphere. They have an entirely separate team that's running AWS and an entirely separate team running GCP.

And in those scenarios, there's no cohesiveness. There's no knowledge that's transferred back and forth, and they end up managing independent systems. And so we're really kind of at the beginning stages of that. And that's why you see acquisitions like Cloud Help, or Bitnami. And then we'll talk about how to get into it. But to summarize that, there's really a two-prong approach. Continue to enhance the hybrid cloud and bringing on-premises data center into the public cloud in that fashion.

But secondarily, and just as important, is expanding to becoming a true multi-cloud company. Truly seeing all workloads, whether it's Amazon, EC2, RDS, Redshift, whatever you want to name it, Azure, AKS, or GKE, treating everything as a first-class citizen, which means something that doesn't run a vSphere hypervisor all the time, right? So it's definitely a transitional shift. And I think you'll continue to see that as we move forward. And I'm never going to be sitting here saying that the best approach is to be non-responsive to customer needs and customer pain. I think that if you start down the path

of correcting your customers when they tell you they have a pain and need to do a thing, that leads down to a very condescending place that I'm not sure benefits anyone. The counterpoint too, I think that also strengthens your argument argument is that a lot of your customers are not Twitter for pets born in the cloud companies that are three years old.

These are enterprise companies that predate either public cloud entirely or responsible use of public cloud. They have very different needs, very different workloads. When you start talking to that caliber of customer a lot of my ranting for lack of a better term against multi cloud changes form slightly when you have a bunch of different lines of business when you have different acquisitions for example running in different cloud providers you're right there's very little reason to start merging those to a single provider that that's a lot of

work that generates a unclear business value. Until you get clarity around exactly what that value looks like, you probably shouldn't do it. Where I've been ranting about the idea of multi-cloud being dumb is that you take a given workload and be able to seamlessly deploy that workload anywhere. It doesn't care where it lives. That, to be clear, is something that VMware is very good at doing. That was, in many respects, something you were doing even in on-prem environments, where we want to be able to have vMotion and move a VM off of a failed instance onto something else without dropping a packet.

And that can be done, which is amazing. And then the world changed. Now people are trying to do that between providers, and it very often doesn't make a whole lot of sense. Because as soon as you start doing that, you wind up in this unfortunate world where you are reduced to using the baseline primitives of what all of these lowest common denominator offerings tend to be, which means you're not going to be using a message queue that you get for effectively free. You're going to have to roll your own in a bunch of VMs running in

VMware, and that has to migrate too. And it just leads down a very unpleasant architectural path. It's strange because on the one hand, that is something that your company effectively was built on top of. And continuing to evangelize that is in the company's own best interest. The other side is with this new breed of acquisition that you've been doing, you are painting a path to a brighter tomorrow. When I hear that someone is considering engaging with VMware as a part of their public cloud strategy, I no longer immediately have the knee-jerk reaction to crap all over it. It's, well, let's talk about that more.

Oh, cloud health. Okay, that's a reasonable path forward. Heptio. Great. Awesome. We don't know what the bitten AMI acquisition is going to look like yet. I'm still biding my time on that one. But there's a lot of this stuff that makes a lot of sense. You're starting to diversify not just your product lines, but also your messaging. And that, I think, is one of the most interesting things

I've seen out of you folks. Yeah, and to be fair, when you go into this, as you mentioned, you know, the idea of moving a workload between clouds, I would argue that's lift and shift. And in most cases, lift and shift is more expensive in the public cloud, right? When you literally take an over-provisioned workload or a shrink wrap application and attempt to move to the public cloud, which we've seen organizations do it, right? I can name several off the top of my head. The problem is- I'm an advocate for that, but that's a separate argument.

Correct. But there's literally no optimization, right? Or at least it's the initial stage, and then they have to clean up. Right. To be clear, I'm a fan of it as a transitional step because shifting it while you move it means that now we have no idea where this problem is coming from. It's nicer to be able to move it first, take the financial hit, and then optimize this phase two. But you've got to do phase two and it's going to take a complete refactor. Well, the initial cost of that tends to be greater than actually doing the initial electric chip, right? We can get into, you know, and by the way, we're speaking in generic terms here. Every organization is different. The one thing I

would say though, is VMware is doing this kind of two-step, if you want to call it that, right? We absolutely are continuing to improve on what we've built over the past, you know, 18, 19, 20 years, right? But at the same time, we truly are embracing organizations, right? I'll use CloudHealth as an example. We looked at CloudHealth and pretty much most of the CloudHealth customers, when they purchased CloudHealth, it wasn't the traditional VMware team that was also buying CloudHealth, it wasn't the traditional VMware team that was also buying CloudHealth, right? It was two separate parts of the organization.

It was two separate buyers, in some cases, very unique buyers. And so that gives us a completely different view into this public cloud world, right? We now have a better understanding of how consumers, how end users are consuming the public cloud, why they move to the public cloud in the first place. And we're not going to take cloud health and be like, all right, well, let's go prove, you know, if you take all of your Azure workloads and you put them back on vSphere, we're not even doing that. That's not even in the question or in the equation. We are absolutely giving our customers options. If you want to run native GCP, go for it. If you want to run native VMware, go for it.

There was some talk that, oh, organizations were getting out of the VMware business or out of the data center business. And that was a couple of years ago. What we've actually seen is those organizations who came to us and said, yeah, we're going to slowly transition off VMware and maybe move to a 80-20 model or a 75-25 model public cloud versus on-prem. They're actually shifting back a little bit, right? Maybe 50-50, 40-60 and so on. And so now we have is the really the desire of VMware. And as I stated earlier, two years ago, we announced this focus on multi cloud, or the focus to support multiple workloads. That was really that entry point. And we're just two years into this now. And it's truly just

starting, right? That's what we end up making additional acquisitions, whether it's Bitnami. I love the Bitnami, by the way, so keep it going. It's actually perfect. Oh, yes. Their CEO continues to roll eyes whenever I say that. Their former COO actually tries to hit me. It's great. It just goes great. No. And actually, I saw Daniel this week. Just to be clear, the acquisition is final. Pat actually announced it on the earnings call last week. And we're excited to have the Bitnami team on board. We've got some fun things that we're doing. It really is a portfolio enhancement of helping our customers transition to public cloud. Or even if you want to go back to the idea of moving a workload from

on-prem to public cloud or, you know, between public clouds, having an enterprise catalog to do that makes sense, right? And then you only have to shift the data, but that's way in the weeds. But we are absolutely excited about the direction. And thank you. Obviously, you have plenty of snark and comments about VMware historically. And look, if we can chip away, whether it's monthly or yearly, whatever it may be to change the perception, we're happy to do it, right?

The next, I think for us, the next phase of the developer space or the cloud native space. So lots of opportunity to improve and learn from our customers and then go from there. Largely the cloud native and developer space is something of an on-tap market for VMware historically, other than things like VMware Workstation or VMware Fusion, so you can run

different operating systems on your Mac or Windows or Linux box. And things like Docker have more or less taken a chunk out of that, where that's no longer the workflow that people go with. They aren't going with license fees for enterprise commercial software for this problem anymore. And of course, with the rise of public cloud, click button, receive actual instance in environment, which means that even local dev is something of a controversial approach these days. Some people want to do their work entirely in a cloud environment. Cool.

I don't tend to be particularly prescriptive around workloads. The challenge, though, turns into how do you parlay the experience you have working and speaking to giant enterprise companies into a relatively smaller, definitionally, cloud native type of environment where they're not cloud migrants, they're cloud natives, and they have a relatively small team. What they start working with is likely what they'll continue working with as they become those larger corporate entities. How do you speak to them? How do you reach them? Yeah, 100%. I would say this VMware is a software company. At the end of the day, as an organization, we've been developing software for

a long time. You know, one could argue the hype, the VMware hypervisor kind of spun this idea of hyperscalers and all that good stuff. And so we as an organization, right, you know, traditionally, we would build software in a very waterfall. I called it aged. That's just my fun term because it would take, you know, 18 months to get a brand new vSphere release, right? Well, with this transition of becoming a SaaS company and becoming a, you know, modern, if you want to use that term or cloud native type, we started actually doing that with vSphere, right? We do that in the VMC model where in some cases we're, you know cases we can push out code every day if need be or every other day.

And then ultimately that ends up pushing back into the on-premises and hybrid cloud solutions, right? So we are a software company. We use a lot of open source software, right? There is no, I think one thing a lot of folks struggle with in this developer enterprise space is, well, you're going to either use all shrink wrap or you're going to use all open source, right? If you're a true cloud native company. Well, the problem with that, when you get into the enterprise, it's really a conglomerate. And we have organizations that are using part us, part IBM, part Red Hat, part open source in some fashions.

Right. So it's finding the balance in all of that. And I think where my team, my organization, to be clear, right, we started the developer advocacy program here at VMware, focusing on developer needs, public cloud needs. And then obviously we'll bring that on back to the on-prem private cloud. But we need to be able to encompass multiple aspects, right? Everything starts with a pipeline. It should live and die in the pipeline, right? Our group, we run something called Cloud Journey.

It's kind of our take on this approach of public cloud into know, agility space, if you want to use that term. And so even for us, you know, as cloud journey continues to evolve our team, very small today, we're trying to do things like bringing cost analysis into the pipeline, right? We had a, we had a meetup this past week where we were highlighting how to take cloud health and the cost of an AKS cluster in Azure, and could I provision to it based upon my budget of that particular workload or project and so on.

That's really where this changes. And then the second thing that we have, and we've kind of looked at, not only from a continuous verification perspective, but it's looking at the security aspects, right? And making calls to open source solutions like Clare to look up CVEs inside of our containers, or, you know, all the way to let's make configuration changes to our open S3 bucket that may be okay, but it's unencrypted on the back.

There's so many things that we get into. What we wanted to do is just start the path and start the journey. And so as we've done this, really developers internally are starting to provide expertise, right? VMware has run an SRE team for about two years now, right, internally on our own solutions. So we are a software company. We're going to continue to be a software company. We've gotten rid of some of those pieces along the way that we failed at. But we want to make sure that we're listening to those customers. If it's open source or shrink wrap, whatever it may be,

we're here to bundle it together and really be an independent third party. In some cases, it may be our tools. In some cases, it may not be. And that's absolutely okay. That's a little bit different than, hey, you have to run our hypervisor. And so this transition has been a little bit fun, and we're just getting started there. I think that there's an interesting future ahead for you folks. Whether or not you're able to successfully navigate this this i guess complete landscape transformation is something i don't think we're going to have an answer to for another 20 years it's there's so much going on in this space and the companies that i guess you deal with

primarily as well as the company that you are is at such a scale that even small changes take forever to wind up percolating through there's an inertia problem where steering the ship takes years, if not decades. Can you talk at all about what that cultural transformation looks like internally? Is it something where it feels like you're swimming against the tide? Is the company relatively aligned on where it's going next? Is it a topic we don't want to get into? No, this is a fun topic. So I'll answer this in a couple of parts.

I think if you look at it from a leadership, from an investment perspective, right at the C-suite and the broad strategy as an organization, like we've been on this journey for a couple of years now, we've made multiple acquisitions. We've made changes internally to that. But the thing I would argue is there are still people buying mainframes, right? So when we get into that mainframe conversation, there's these what we call mainframe huggers. We have server huggers, right, before the hypervisor kind of took over. And now we have vSphere huggers, right? And that's okay to each his own or her own. But what we have to understand is while there may be still some mainframe huggers or vSphere huggers out there, there's actually a growing community of folks who realize that not everything is going to sit on a single hypervisor or inside a one methodology from a cloud perspective. perspective, right? And as internally, obviously leadership, as I mentioned before, but even across the board, right? You know, teams are fully embracing the idea of workload portability,

if you want to use that to allow for workloads to be on Kubernetes or on, you know, even OpenStack, right? We have one of the leading distributions of OpenStack. And so we are able to, I think, navigate that in a proper fashion. Are we perfect? No, not at all. But I think we're learning, we're growing. And I think that chasm has already been crossed, obviously, from a leadership perspective, from an investment perspective, but even in the weeds, right? VMware is absolutely focused on public cloud and on cloud native where we had not been traditionally. So one other thing that I mentioned somewhat recently that, of course, set off a tremendous reaction from folks, and I suspect that given where you work, your reaction will be no different than most,

was that I wrote a blog post titled, Right-Sizing Your Instances is Nonsense. And in that post, I made the argument that yes, it does wind up saving a lot of money. And yes, it's absolutely a good thing to do. But whenever you look at an existing workload, modernizing it to a newer instance family type or resizing the one that you've got is nowhere near as trivial in many cases as people like to pretend it is and i got well actually to death but i stand by it hit me with it what are your thoughts on that yeah you know um i i wish you would not have put that out on late on a friday night or I probably would have commented too. But to be very clear, right, we absolutely work day in and day out

with organizations who are doing ride sizing, whether that is in the private cloud or in the public cloud. I can say personally, when I was, you know, six, seven years ago, when I was focused on the private cloud, we absolutely, or the hybrid cloud, the VMware cloud, we absolutely work with customers to improve usability of resources

and the consumption of said resources, right? We have organizations, you know, maybe we go back to the lift and shift methodology where they do need to do some right sizing, right? There needs to be an improvement. There are some workloads, right-sizing doesn't make sense. And I think this really goes back to the customer question. One of the things I know I have tried to do and our team and our organization tries to do is really give customers choice. I mean, I've got example, example where right-sizing saves money or the purchase of RIs or convertible RIs saves money. So, you know, there are absolute technical challenges. I think we could go into those in individual pieces and parts.

While I would say right sizing is not insane or unimportant, I would say it really depends on the scenario. It depends on the organization and the model. But I can tell you, if we could under NDA, I would absolutely show you some really good examples where customers do this, how they do it, and ultimately the savings that they gain from it. So to each his own, if you put me back in an organization where it didn't make sense, I'd probably say it doesn't make sense. I just think that it comes down to options and it really depends on context. Absolutely.

And that, I think, is the entire crux of the argument with less of a clickbait title. Yes. Where the idea being that, yes, there are tremendous financial and performance gains to be had. And when it makes sense, absolutely do it. But if it winds up having to recertify an application that is a process that was going to take months to do, and it winds up saving you good work out of $300 a month that's not generally worth doing it's if you can do it and it's a trivial change over the course of an hour or so and you just you have an auto scaling group that

now reprovisions it and there's no other changes that are workload impacting great awesome go for that that's absolutely fine i'm just i guess go for that. That's absolutely fine. I'm just, I guess by saying that, what I'm trying to achieve as an outcome is this idea that if you wind up going down this path, just make sure you know what you're getting into. It all comes down to context. Correct, and look, if you decouple, I mean, I would just pick the easiness of the public cloud.

If you've done this right, and we'll pick on Amazon, you can change from one class to another. As long as you've decoupled the data and you've not written everything to the OS partition, then you're probably fine, right? It just depends on how it was architected. In the context, if it is an application that the organization developed,

that probably is easier to do this. But if you get into some of the shrink wrap applications where they make sure you, you know, they dictate certain, you know, parameters and installation types and how it was deployed, probably don't support auto scaling, right? That's where you get into that gray area of does this make sense um and and i think you know depending on the organization maybe it does maybe it doesn't

right that comes down to the dollars and cents question um that uh that we all should look at in a much bigger picture um but because i know my cloud health team would hate me if i didn't say it we absolutely do have customers do it. And we're always here to kind of go back and forth and work with them to find those gaps. It's not just instance types. It could be our eyes. That's another area.

I mean, even VMware is a customer of cloud health. We save significantly with our eyes and see our eyes. And so it's just, it's just getting into the conversation past the clickbait. Clickbait's all good, man, that I actually laughed at it. And so, you know, let's just get into the context. Well, sounds good to me.

I think that a lot of the challenges that we'll see in this space is that, and to some extent coming from the type of company, like for example, cloud health. Now that's your problem, your responsibility, where you wind up, at least as I go through talking to companies

with large budget challenges, the dashboards that get spit out by any of the tooling in this space are effectively working from the same starting point, where there are

established APIs, at least in the AWS space, that you can wind up pulling this data from, and then what you do with that is up to you. And very often, it serves as a useful starting

point, but it doesn't get you there. It doesn't provide context. As soon as you wind up with that tool suggesting that, okay, now it's time to turn off those idle instances. And what were those? Oh, the DR site. Well, people start to take it less seriously. Two or three outings like that

and people tend to view it as largely useless. That's largely unfair, but it does wind up providing, I guess, a psychological reinforcement that tools are not to be trusted in this space. It lacks context and it lacks business awareness. And to be blunt, I don't know how you fix that from a SaaS perspective. Well, so to be right, there is an evolution or a journey that our customers are on, right? Everybody in the industry, you know, unless you're just a cloud native company like a Netflix where you, you know, you've done this, you've built this, you don't need to go back, right? You don't have the history to go along with it. If they're doing it right, and I'll use VMware as an example because we don't mind talking about it. If they're doing it right, and I'll use VMware as an example because we don't mind

talking about it. If you tag your workloads properly, if you are doing the necessary metadata layers to your applications and when you provision them, right, if it's Terraform or Ansible, you know, whatever solution you're using in the industry or even our own, if you don't tag those workloads, you're already setting yourself back. So context comes from the organization itself. And what we have is we have customers who use our perspectives, and they have tagged properly or they go back and tag properly to provide that context. And then that's where the slicing and dicing of

the data comes in. And I will say, it's not only about cost savings, right? We want to get into governance, right? Should Tim on my team be able to provision a $10,000 a day workload in Azure, right? Or should he be able to make changes to a security group or some firewall within one of the public clouds, right? So we're absolutely looking to expand it beyond cost, but the cost conversation is one that always comes up first. And then we kind of see the security, and then we kind of get into some other areas around governance and so on.

So this is a journey that everyone is on. If they want help with some of the context, let me know. I can give some tips, right? There's not only our stuff, but others out there who attempt to articulate the idea of using the metadata in your favor, but some organizations didn't do it at the start, right? So they obviously have to do a little bit of homework. Absolutely. And I don't think that you're ever going to get away from having to do homework. As much as we want to pretend that it's push button, receive cloud, I don't think that there's a particularly clear path to get there. And we can get close, but I don't think we're ever going to get there. And it's almost a question of,

do we find that answer here? Do we find it there? Do we find it VMware? And no, I'm not apologizing for that. Pun intended, right? I think everyone in this industry, right? We all want to come in and have our, you know, extremely opinionated view. And we know better than everyone else. But just like any net new technology or any, you know, truly differentiated organization. There's a series of learning and a series of opinions, right? And I think, obviously, I'm very biased in this fashion. I do think VMware has an opportunity because of our history

and because of what we were able to do in the on-prem space, right? We had, you know, hardware providers galore that we were able to work with from an ecosystem perspective. But now we want to be able to do the same thing in the public cloud. Do we have all the answers today? Not at all. Are we getting answers? Yes. And we're continuing to work and harbor the questions back and forth with our customers and non-customers alike. There are some non-VMware customers that are now coming to VMware and say, hey, I've got a challenge in the public clouds.

How can you help me? So we're here to do that. We're here to help in that fashion. And it's a fun journey to be on so far. I would agree with you. Sean, thank you so much for taking the time to speak with me today. Where can people find more of your wise thoughts? Wise thoughts.

Well, thank you for the kind words. Thank you for the opportunity to be on here. Follow me on Twitter. I am the Sean O'Dell. The Sean O'Dell. Yes, that's a Gaelic version. S-E-A-N. And then find our team. My fearless leader, Bill Shetty, Milan Desai,

teammates, Dan, Tim, we are in Shree. We're all on cloudjourney.io. We're about to do a quick refresh of the page here in the next couple of weeks. It's going to be fun. It's exciting. We write things that have nothing to do with vSphere. And we write things that oftentimes have nothing to do with VMware solutions, right? So that are focused on public cloud, cloud native, and so on. So give us a shout out. Reach us. Tweet us.

You know, beat us up. Whatever you want to do, we're here to engage. And always exciting to work with the community and to see what everyone's doing. Sounds good to me. Thanks once again. This is Sean O'Dell, developer and cloud advocate at VMware. I'm Corey Quinn,

and this is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.