Screaming in the Cloud - Innovating in the Cloud with Craig McLuckie

Episode Date: August 26, 2021

About CraigCraig McLuckie is a VP of R&D at VMware in the Modern Applications Business Unit.  He joined VMware through the Heptio acquisition where he was CEO and co-founder. Heptio was a startup that supported the enterprise adoption of open source technologies like Kubernetes.  He previously worked at Google where he co-founded the Kubernetes project, was responsible for the formation of CNCF, and was the original product lead for Google Compute Engine.Links:VMware: https://www.vmware.comTwitter: https://twitter.com/cmcluckLinkedIn: https://www.linkedin.com/in/craigmcluckie/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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 episode is sponsored in part by Cribble Logstream. Cribble Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere to anywhere.

Simple, right? As a nice bonus, it helps you not only improve visibility into what the hell's going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell into a company name. To learn more, visit Cribble.io. That's C-R-I-B-L dot I-O. And tell them Corey sent you and wait for the wince. This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, CanaryTokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything

else like that that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more because they also have an enterprise option that you should be very much aware of. Canary.tools. Take a look at this. What it does is provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever

you want it to. Whenever it gets NMAP scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at and say, this is an amazing idea.

I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools. And the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into. Take a look.

I'm a big fan. More to come from Thinkst Canary in the weeks ahead. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Craig McClucky, who's a VP of R&D at VMware, specifically in their modern applications business unit. Craig, thanks for joining me. VP of R&D sounds almost like it's what's sponsoring a Sesame Street episode. What do you do exactly? Hey, Corey, it's great to be on with you. So I'm obviously working within the VMware company, and my charter is really looking at modern applications. So the Modern Application Platform Business Unit is really grounded in the work that we're

doing to make technologies like Kubernetes and containers and a lot of developer-centric technologies like Spring more accessible to developers to make sure that, you know, as developers are using those technologies, they shine through on the VMware infrastructure technologies that we are working on. Before we get into, I guess, the depths of what you're focusing on these days, let's look a little bit backwards into the past. Once upon a time in the dawn of the modern cloud era, I guess we'll call it, you were the original product lead for Google Compute Engine or GCE. How did you get there? That seems like a very strange thing to be something that, well, what am I going to build? Well, that's right. Basically, a VM service for a giant company that is just starting down the cloud path back when that was

not an obvious thing for a company to do. Yeah, I mean, it was as much kind of luck and serendipity as anything else, if I'm going to be completely honest. I spent a lot of time working at Microsoft building enterprise technology. And one of the things I was extremely excited about was obviously the emergence of cloud. I saw this as being a fascinating disruptor. And I was also kind of highly motivated at a personal level to just make IT simpler and more accessible. You know, I'd spend a fair amount of time building systems within Microsoft, and then even a very small amount of time running systems within a hedge fund. So I got kind of both of those perspectives. And I just saw this cloud thing

as being an extraordinarily exciting way to drive out the cost of operations, to enable organizations to just focus on what really mattered to them, which was getting those production systems deployed, getting them updated, maintained, and just having to worry a little bit less about infrastructure. And so when that opportunity arose, I jumped with both feet. Google obviously had a reputation as a company that was born in the cloud. It had a reputation of being extraordinarily strong from a technical perspective. So having a chance to bridge the gap between enterprise technology and that cloud was very exciting to me. This was back in an era when, in my own technical evolution, I was basically tired of working with Puppet as much as I had been. And I was one of the very early developers behind SaltStack once upon a time, which since then you folks have purchased.

Which shows that someone didn't do their due diligence because something like 41 lines of code in the current release version is still assigned to me as per git blame. So, you know, nothing is perfect. And right around then, I started hearing about this thing that was at one point leveraging Saltzack, kind of, called Kubernetes, which I can't even pronounce that, so I'm just going to ignore it. Surely this is never going to be something that I'm going to have to hear about once this fad passes. It turns out that the world moved on a little bit differently, and you were also one of the co-founders of the Kubernetes project, which means that

it seems like we have been passing each other in weird ways for the past decade or so. So you're working on GCE, and then one day you wound up, what, sitting up and deciding, I know, we're going to build a container orchestration system because I want to have something that's going to take me 20 minutes to explain to someone who's never heard of these concepts before. How did this come to be? It's really interesting. And a lot of it was driven by necessity, driven by a view that to make a technology like Google Compute Engine successful, we needed to kind of go a little bit further.

When you look at a technology like Google Compute Engine, we built something that was fabulous, and Google's infrastructure is world-class. But there's so much more to building a successful cloud business than just having a great infrastructure technology. There's obviously everything that goes with that in terms of being able to meet enterprises where they are. Oh yeah, everything at Google is designed for Google scale. We built this thing and we can use it to stand up something that is world scale and get 10 million customers on the first day that it launches. And that's great. I'm trying to get a

Hello World page up and maybe if I shoot for the moon, it can also run WordPress. There's a very different scale of problem. It's just a very different thing. You know, when you look at what an organization needs to use a technology, it's nice that you can take that sort of science fiction data center and carve it up into smaller pieces and offer it, you know, as a virtual machine to someone. But you also need to, you know, look at the ISV ecosystem, the people that are building the software, making sure that it's qualified.

You need to make sure that you have the ability to engage with the enterprise customer and support them through a variety of different functions. And so as we were looking at what it would take to really succeed, it became clear that we needed a little more. We needed to kind of go a little bit further. And around that time, Docker was really coming into its fore. You know, Docker solved some of the problems that organizations had always, you know, struggled with. Virtual machine's great, but it's difficult to think about. And inside Google, you know, containers were a thing. Well, containers have a long and storied history in different areas. From my perspective, Docker solved the problem of, well, it works on my machine.

Because before something like Docker, the only answer was, well, back up your email because your laptop's about to be in production. Yeah, and that's exactly right. You know, I think when I look at what Docker did, and it was this sort of moment of clarity because a lot of us had been kind of talking about this and thinking about it. I remember turning to Joe while we were building Computer Engine and basically said, whoever solves the packaging the way that Google did internally and makes that accessible to the world is ultimately going to walk away with the game. And I think Docker put lightning in a bottle. They really just focused on making some of these

technologies that underpinned the hyperscalers, that underpinned the way that a Google or a Facebook or a Twitter tended to operate, just accessible to developers. And they solved one very specific thing, which was that packaging problem. You could take a piece of software and you could not package it up and deploy it as an immutable thing. So, you know, in some ways, you know, back to your own origins with SaltStack and some of the technologies you've worked on, it really was an epoch of DevOps.

Like, let's give developers tools so that they can code something up that renders a production system. And now, with Docker, you were able to kind of shift that all left. So, what you produced was the actual deployable artifact, but that obviously wasn't enough by itself. No, there needed to be something else. And according to your biography, not only, it says here that, and I quote, you were responsible for the formation of the CNCF, or Cloud Native Computing Foundation. And the whole thesis behind Kubernetes, if you just step back a little bit, was we didn't need to own it. Google didn't need to own it. We just needed to move the innovation boundary forwards into an area that we had some very strong advantages. And if you look at the way that Google runs, it kind of felt like when people were working with Docker and you had technologies

like Mesos and a lot of these other things, they were trying to put together a puzzle. And we already had the puzzle box in front of us because we saw how that technology worked. So we didn't need to control it. We just needed people to embrace it. And we were confident that we could run it better. But for people to embrace it, it couldn't be seen as just a Google thing. It had to be a Google thing and a Red Hat thing and an Amazon thing and a Microsoft thing and something that was really owned by the community. So the inspiration behind CNCF was to really put the technology forwards to build a collaborative community around it and to enable and foster this disruption? At some point after Kubernetes was established and it was no

longer an internal Google project, but something that was handed over to a foundation, something started to become fairly clear in the larger ecosystem. And it's sort of a microcosm of my observation that the things that startups are doing today are what enterprises are going to be doing five years from now. Every enterprise likes to imagine itself a startup. The inverse is not particularly commonly heard. You left Google to go found Heptio, where you were focusing on enterprise adoption of open source technologies, specifically Kubernetes. But it also felt like it was more of a cultural shift in many respects, which is odd because there aren't that many startups, at least in that era, that were focused on bringing startup technologies to the enterprise and sneaking in, or at least that's how it felt, the idea of culture change as well. It's really interesting.

Every enterprise has to innovate, and people tend to look at startups as being a source of innovation, a source of incubation. What we were trying to do with Heptio was to kind of go the other way a little bit, which was when you look at what West Coast tech companies were doing and you look at a technology like Kubernetes or any new technology, Kubernetes or Knative or some of these kind of new observability capabilities that are starting to emerge in this ecosystem, there's this sort of trickle across effect where it starts with the West Coast tech companies that build something and then it trickles across to a lot of the progressive forward-leaning enterprise organizations that have the scale to consume those technologies. And then over time, it becomes mainstream. And when I looked at a technology like Kubernetes, and certainly through the lens of a company like Google, there was an opportunity to step back a little bit and think about like, well, Google's really kind of this West Coast tech company, and it's producing this technology,

and it's working to make that more kind of enterprise-centric. But how about going the other way? How about like meeting enterprise organizations where they are? Enterprise organizations that aspire to adopt some of these practices and build a startup that's really about just walking the journey with customers, advocating for their needs through the lens of these open source communities, making these open source technologies more accessible. And that was really the thesis around what we were doing with Heptio. And we worked very hard to do exactly as you said,

which is, it's not just about the tech, it's about how you use it. It's about how you operate it, how you set yourself up to manage it. And that was really the core thesis around what we were pursuing there. And it worked out quite well. Sitting here in 2021, if I were going to build something from scratch, I would almost certainly not use Kubernetes to do it. I'd probably pick a bunch of serverless primitives and go from there. But what I respect and admire about the Kubernetes approach is companies can't generally do that with existing workloads. You have to meet them where they are, as you said.

Legacy is a condescending engineering phrase for it makes money. It's, oh, what does that piece of crap do? Oh, about $4 billion a year. So yeah, we're going to be a little delicate with what it does. I love that observation. I always prefer the word heritage to the word legacy. You've got to have a little bit of respect. This is the stuff that's running the world. This is, this is the stuff that like every transaction is flowing through. And it's funny when you start looking at it, often you follow the train along and eventually you'll find a mainframe somewhere, right? Like it is definitely something that we need to be a little bit more thoughtful about. Right. And as cloud continues to eat the world, well, as of the time of this recording, there is no AWS 400. So there is no direct mainframe option in most cloud providers.

So there has to be a migration path. There has to be a path forward that doesn't include, oh, and by the way, take 18 months to rewrite everything that you've built. And containers, particularly with an orchestration model, solve that problem in a way that serverless primitives frankly don't. I agree with you. And it's really interesting to me as I work with enterprise organizations. I look at that modernization path as a journey. Cloud isn't just a destination. There's a lot of different permutations and steps that need to be taken. And every one of those has a return on investment. If you're an enterprise organization, you don't modernize for modernization sake. You don't embrace cloud for cloud sake. You have a specific outcome in mind. Hey, I want to drive down this cost or, hey, I want to accelerate my

innovation here. Hey, I want to be able to set my teams up to scale better this way. And so a lot of these technologies, whether it's a Kubernetes or even serverless is becoming increasingly important, is a capability that enables a business outcome at the end of the day. And when I think about something like Kubernetes, it really has, in a way, emerged as a Goldilocks abstraction. It's low enough level that you can run pretty much anything. It's high enough level that it hides away the specifics of the environment that you want to deploy it into.

And ultimately, it renders up what I think is like economies of scope for an organization. I don't know if that makes sense. You have these economies of scale and economies of scope. Given how down I am on Kubernetes across the board, and at least as it's presented, and don't take that personally. I'm down on most modern technologies. I'm the person that said that cloud was a passing fad, that virtualization was only going to see limited uptake, that containers were never going to eat the world. And I finally decided to skip

ahead of the Kubernetes thing for a minute. Now, I'm actually positive about serverless, given how wrong I am on these things. That almost certainly dooms it. But great. I was down on Kubernetes for a long time because I kept seeing these enterprises and other companies talking about their Kubernetes strategy. It always felt like Kubernetes was a means to an end, not an end in and of itself. And I want to be clear, I'm not talking about vendors here. Because if you are a software provider to a bunch of companies and providing Kubernetes as part and parcel of what you do, yeah, you kind of need a Kubernetes strategy. But the blue chip manufacturing company that is

modernizing its entire IT estate doesn't need a Kubernetes strategy as such. Am I completely off base with that assessment? No, I think you're pointing at something which is, I feel as well. Like, I mean, I'll be honest, I've been talking about Kubernetes since day one, and I'm kind of tired of talking about kubernetes it should just be something that's there you shouldn't have to worry about it you shouldn't have to worry about operationalizing it it's just an infrastructure abstraction like it's not in and of itself an end it's simply a means to an end which is being able to start looking at the destination you're deploying your software into as being more favorable for building distributed systems,

not having to worry about the mechanics of like, what happens if a single node fails? What happens if I have to scale this thing? What happens if I have to update this thing? So it's really not intended. And it never was intended to be an end unto itself. It was really just intended to raise the waterline and provide an environment

into which distributed applications can be deployed that felt entirely consistent, whether you're building those on-premises in the public cloud and increasingly out to the edge. I wound up making a tweet a couple of years back, specifically in 2019, that said, nuclear hot take, nobody will care about Kubernetes in five years. And I stand by it, but I also think that that's been wildly misinterpreted because I am not suggesting in any way that it's going to go away and no one is going to use it anymore. But I think it's going to matter in the same way as the operating system is starting to,

the way that the Linux virtual memory management subsystem does now. Yes, a few people in specific places absolutely care a lot about those things, but most companies don't because they don't have to. It's just the way things are. It's almost an operating system for the data center or the cloud environment, for lack of a better term. Is that assessment accurate? And if you don't wildly disagree with it, what do you think of the timeline? I think the assessment is accurate. You know, the way I always think about this is you want to present your engineers, your developers, the people that are actually taking a business problem and solving it with code. You want to deliver to them the highest possible abstraction, right? The less they have to worry about the infrastructure, the less they have to worry about setting up their environment, the less they have to worry about the sort of DevOps or DevSecOps pipeline, the better off they're going to be. And so if we as an industry do our job right,

you know, Kubernetes is just the water in which IT swims, you know, like the fish doesn't see the water, right? Like it's just there. We shouldn't be pushing the complexity of the system because it is a fancy and complex system directly to developers. We shouldn't be pushing the complexity of the system because it is a fancy and complex system directly to developers. They shouldn't necessarily have to think like, oh, I need to understand all of the X, Y, Zs about how this thing works to be able to build a system. There will be some engineers that benefit from it,

but there are going to be other engineers that don't. The one thing that I think is going to, is a potential change on what you said is we're going to see people starting to, you know, program Kubernetes more directly, you know, whether they know it or not. I don't know if that makes sense, but things like the ability for Kubernetes to offer up a way for organizations to describe the desired state of something and then using some of the patterns of Kubernetes to make the world into that shape is going to be quite pervasive. And I'm already seeing signs that we're seeing it. So yes, most developers are going to be working with higher abstractions.

Yes, technologies like Knative and all the work that VMware are doing within the ecosystem will render those higher abstractions to developers. But there's going to be some really interesting opportunities to take what made Kubernetes great beyond just, hey, I can put a Docker container down on a virtual machine and start to think about reconciler-driven IT, being able to describe what you want to have happen in the world, and then having a really smart system

that just makes the world into that shape. This episode is sponsored by our friends at Oracle HeatWave, a new high-performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel. While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work, while also performing 1,100 times faster than Amazon Aurora and 2.5 times faster than Amazon Red and two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.

So you went from driving Kubernetes adoption into the enterprise as the founder and CEO of Heptio to effectively acquired by one of the most enterprisey of enterprise companies in some respects, VMware, and your world changed. So I understand what Heptio does, because to my mind, a big company is one that is 200 people. VMware has slightly more than that at last count. And I sort of lose track of all the threads of the different things that VMware does and how it operates. I could understand what Heptio does. What I don't understand is what, I guess, your corner of VMware does. Modern applications means an awful lot of things to an awful lot of people. I prefer to speak it with a condescending accent when making fun of those legacy things that make money.

Not a popular take, but it's there. How do you define what you do now? So for me, it's, you know, when you talk about modern application platform, you can look at it one of two ways. You can say it's a platform for modern applications. And when people have modern applications, they have a whole variety of different ideas in their head. Okay, well, it's microservices based, or it's kind of API fronted, it's event driven, you know, it's supporting stream based processing, blah, blah, blah, blah, blah. There's all kinds of fun, cool, hip new patterns that are happening in the, you know, in the segment. The other way you can look at it is it's a modern platform for applications of any kind, right? So it's really about like, how do we make sense of going from where you are today to where you need to be in the future? How do we position the set of tools that you can use

as they make sense, as your organization evolves, as your organization changes? And so I tend to look at my role as being bringing these capabilities to our existing product line, which is obviously the vSphere product line. And it's almost a hyperscale unto itself, but it's really about that private cloud experience historically and making those capabilities accessible in that environment. But there's another part to this as well, which is it's not just about running technologies on vSphere. It's also about how can we make a lot of different public clouds look and feel consistent without hiding the things that they are particularly great at. So every public cloud has its own set of

capabilities, its own price performance profile, its own service ecosystem and richness around that. So what can we do to make it so that as you're thinking about your journey from taking an existing system, one of those heritage systems, and thinking through the evolution of that system to meet your business requirements, to be able to evolve quicker, to be able to go through that digital transformation journey, and package up and deliver the right tools at the right time in the right environment so that we can walk the journey with our customers. Does this tie into Tanzu or is that a different VMware initiative slash division?

And my apologies on that one, just because it's difficult for me to wrap my head around where Tanzu starts and stops, if I'm being frank. Yeah, so MapBU is the heart of Tanzu. So Tanzu in a way is a new branch, a new direction for VMware. It's about bringing this richness of capabilities to developers running in any cloud environment. It's an

amalgamation of a lot of great technologies that people aren't even aware of that VMware's been building or that VMware has sort of gained through acquisition. Certainly, Heptio, the ability to bring Kubernetes to an enterprise organization is a part of that. But we're also responsible for things like Spring. Spring is a critical anchor for Java developers. If you look at the Spring community, we participate in one and a half million new application starts a month.

And you wouldn't necessarily associate VMware with that, but we're absolutely driving critical innovation in that space. Things like full stack observability, being able to not only deploy these container packaged applications, but being able to actually deal with the day-to-day operations and how to deal with the APM considerations, et cetera. So Tanzu is an all-in push from VMware to bring the technologies like Kubernetes and everything that exists above Kubernetes to our customers, but also to new customers in the public cloud that are really looking for consistency across those environments. When I look at what you've been doing for the past decade or so, it really

tells a story of transitions where you went from product lead on GCE to working on Kubernetes. You took Kubernetes from an internal Google reimagining of Borg into an open source project that has been given over to the CNCF. You went from running Heptio, which was a startup, to working at one of the least startup-y-like companies by some measures in the world. You seem to have gone from transiting from one thing to almost its exact opposite repeatedly throughout your career. What's up with that theme? I think if you look back on the transitions and those kind of key steps, the one thing that I've consistently held in my head, and I think my personal motivation

was really grounded in this view that IT is too hard. IT is just too challenging. So the transition from Microsoft, where I was responsible building package software, to Google, which was about cloud, was really marking that transition of, hey, we just need to do better for the enterprise organization. The transition from, you know, focusing on a virtual machine-based system, which was the state of the art at the time, to unlocking these modern orchestrated container-based system was in service of that need, which was, hey, you know, if you can start to just treat a number of virtual machines as a destination that has a distributed operating system on top of it, we're going to be better off. The need to transition to a community-centric outcome,

because while Google is amazing in so many ways, being able to benefit from the perspective that traditional enterprise organizations brought to the table was significant, to transitioning into a startup where we're really serving enterprise organizations and providing that interface back into the community to ultimately joining VMware. Because at the end of the day, there's a lot of work to be done here. And when you're selling a startup, you're either selling out or you're buying in. And I'm not big on the idea of selling out. In this case, having access to the breadth of VMware, having access to the place where most of the customers I really cared about were living and all of those heritage systems that are just running the world's business.

So for me, it's really been about walking that journey on behalf of that individual that's just trying to make ends meet, just trying to make sure that their IT systems stay lit, that are trying to make sure that the debt that they're creating today in the IT environment isn't payday loan debt. It's more like a mortgage. I can get into an environment that's going to serve me and my family well. And so each of those transitions has really just been marked by need. And I tend to look at the needs of that enterprise organization that's walking this journey as being an anchor for me. And I'm pleased with every transition I've made. At every point, we've sort of joined myself, who's been on this journey for a while, have been able to better serve that

individual. Now, I know that it's always challenging to talk about the future, but do you think you're done with those radical transitions as you continue to look forward to what's coming? I mean, it's impossible to predict the future, but you're clearly where you are for a reason. And I'm assuming part of that reason is because you see an opportunity, you see a transformation that is currently unfolding. What does that look like from where you sit? Well, I mean, my work at VMware is very far from done. You know, there's just an amazing amount of continued opportunity to deliver value, not only to those existing customers where they're running on-prem, but to make the public cloud more intrinsically accessible and to increasingly solve the problems as more computational resources fanning back out to the edge. So, you know, I'm extremely excited about the opportunity ahead of us from the VMware perspective. I think we have some incredible advantages because at the end of the day, we're

both a neutral party. You know, we're not a hyperscaler. We're not here to compete with the hyperscalers on the economies of scale that they render. But we're also working to make sure that as the hyperscalers are offering up these new services and everything else, that we can help the enterprise organization make best use of that. We can help them make best use of that infrastructure environment. We can help them navigate the complexities of things like concentration risk or being able to manage through the lock-in potential

that some of these things represent. So I don't want to see the world collapse back into the mainframe era. I think that's sort of the thing that really motivates me. I think the transition from mainframe to client-server, the work that Wintel did, the Windows Intel Consortium, to kind of unlock that ecosystem just created massive efficiencies and massive benefits from everyone. And I do feel like with the combination of technologies like Kubernetes and everything that's happening on top of that,

and the opportunity that an organization like VMware has to be a neutral party to really bridge the gap between enterprises and those technologies, we're in a situation where we can create just tremendous value in the world, making it so that modernization is a journey rather than a destination, helping customers modernize at a pace that's reasonable to them, and ultimately serving both the cloud providers in terms of bringing some critical workloads to the cloud, but also serving customers so that as they live with the harsh realities of a multi-cloud universe where, you know, I don't know one enterprise

organization that's just all in on one cloud, we can provide some really useful capabilities and technologies to make them feel more consistent, more familiar without hiding what's great about each of them. Craig, thank you so much for taking the time to speak with me today about where you sit, how you see the world, where you've been, and little bits of where we're going. If people want to learn more, where can they find you? Well, I'm on Twitter, C McCluck, and obviously on LinkedIn. And we'll continue to invite folks to attend a lot of our events, you know, whether that's the spring conferences that VMware sponsors or VMworld. And I'm really excited to have an opportunity to talk more about what we're doing and some

of the great things we're up to. I will certainly be following up as the year continues to unfold. Thanks so much for your time. I really appreciate it. Thank you so much for your time as well. Craig McClucky, Vice President of R&D at VMware in their Modern Applications Business Unit. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment that I won't bother to read before designating it legacy or heritage. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group.

We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.