Screaming in the Cloud - Summer Replay - The Future of Kubernetes with Bryan Liles

Episode Date: July 18, 2024

Is there true value in using cloud optimization tools when they may be phased out in the near future? You may be surprised. In this Summer Replay of Screaming of the Cloud, Corey is joined by former VMware Senior Staff Engineer Bryan Liles. Since this episode was originally released, Bryan wasn’t just promoted to the Vice President of Principal Engineering at VMware, he’s also transitioned to a new role as a Senior Principal Engineer with AWS! Listen as the pair talk about the long-term viability of Kubernetes, what’s in a tech company’s name, flipping the script surrounding the discussion of diversity in the field, and why the words you use matter the most in criticism. If anything, this throwback will show the value of intention, whether in the tech industry or your everyday life. Show Highlights: (0:00) Intro to episode(0:30) Backblaze sponsor read(0:56) The struggles of setting up interview times(2:22) What Bryan does at VMware(4:14) What Kubernetes has accomplished(5:39) Corey’s qualms with Kubernetes(8:16) The shelf life of Kubernetes(10:36) Optimizing Kubernetes in the cloud(13:25) What is Project Pacific?(15:28) Firefly sponsor read(16:04) Woes of the multicloud(19:09) VMware’s branding and Tanzu(21:00) Mispronouncing company names(22:07) Punching down and diversity discourse in tech(25:18) Intentional language in company critiques(28:50) Learning lessons from getting fired(30:36) Where you can find BryanAbout Bryan LilesBryan Liles is a Senior Principal Engineer with AWS where his team oversees all of S3. When not working, Bryan builds and races cars and drones.Over the past 20 years, Bryan has worked around cloud technology and distributed systems. His approaches to technology are: simplify with fidelity and technology should give access to all.Links Referenced: https://vmware.comSponsorsBackblaze: https://www.backblaze.com/Firefly: https://www.firefly.ai/

We expected that this thing was going to be a panacea and solve all of our problems, but us being well-adjusted adults should know that there's no such thing, and that new tech takes a long time, especially big tech, takes a long time to integrate. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Brian Lyles, Senior Staff Engineer at VMware. Brian, welcome to the show. Thanks for having me. Backblaze B2 Cloud Storage helps you scale applications and deliver services globally. Egress is free up to 3x of the amount of data you have stored and completely free between S3ible Backblaze and leading CDN and compute providers like Fastly, Cloudflare, Vulture, and Coreweave.

Visit backblaze.com to learn more. Backblaze. Cloud storage built better. We've been trying to set this up for about a year or so now since we first crossed paths, I want to say, at KubeCon in Barcelona in 2019. Yeah, so I have this thing where people ask me to do podcasts and they send me DMs and DMs is like purgatory for me. I get just enough where if I don't respond to you in about two hours, I'll never see it again. So what happened is I promptly forgot and Corey just pinged me and here I am.

I do my best. The hard part is I find myself in the same exact, I guess, position when it comes to dealing with losing track of DMs. Twitter's automatic sorting of randos into the spam folder is always interesting, but I also wind up with people. I follow them, they follow me, and they're still for some reason sitting there as if I've never spoken to them before. It's great. Yeah. Yeah, so that's about what happens. And really, it's about how I use Twitter.

I mean, I hate to be selfish, but I don't like the DM feature. If I really want to talk to you, I'll give you my email. The problem is that some folks take the exact opposite approach, where Twitter is the public face, email is good lord, you could spam me with that. And I think we've all wound up on enough marketing lists to understand how that winds up having a failure mode that's awful. I know, but real talk, I could ignore you on any platform. So I would just try to be nice. Oh, absolutely. Even in person or on a podcast, it works super well. So in your day job, you work on developer experience at VMware, which to my understanding is aimed at helping developers

be more productive in Kubernetes. If I were to be uncharitable, I'd say that doesn't sound like a particularly high bar given how much time I see people investing, tilting at that particular windmill. But tell me about what you do before I start savaging it undeservedly. Oh, and it's fine.

I mean, those who do, do. Those who can't, talk about it. So I'm always good with that. But what do I do? Right now, I'm looking at Kubernetes as a platform for deploying applications. And with that comes a whole smattering of challenges, something that we at VMware are trying to call the secure software supply chain. And what is that? Well, not quite sure yet, but really here's what it comes down to. As a application developer, why do you need to be

a Kubernetes expert? And I don't want anyone to answer that question because the answer is you shouldn't be. You could deploy applications to Linux and not be a Linux expert. Tell me 15 syscalls. You can't do it, but you can write apps that run on Linux with Ruby or Python or even C for that matter. And I want that experience for Kubernetes. So a lot of my day is spent doing research. How do we get applications into clusters? How do we make sure that they can talk to other things? How do we manage what we have? How do we make it easier for others

to deploy applications into Kubernetes? How do we package them up? What do the workflows look like? This is what I'm actually looking at. And really what it is, is it's more research because anyone can come and say that they have the grand plan. But as we see right now in 2020, that's not true. It feels to me that Kubernetes offers an awful lot of value for the developer side of the world when it effectively, from my perspective at least,

sort of realizes a lot of the initial promise that Docker had, where you can write your application however you want, and then more or less throw it over the wall, and it doesn't really matter where it runs, as far as what provider it's on top of, as far as who's going to be supporting it in which environments. As long as you wind up structuring your application correctly, which is a minor detail we'll leave for the implementation folks, you should largely wind up being okay with it. And from my perspective, it seems like from that development point of view,

it has succeeded. Would you disagree with that? No, I would not disagree with that. So Kubernetes will be six years old this year. There's been lots of success. If you think about it, you know, I worked at Heptio and Heptio got bought by VMware. And that's a success in itself. We have companies like Red Hat that got bought by IBM.

And a big, I'm guessing I have no insider baseball on this one, but I bet a big piece of that was what is happening in OpenShift. And then you have companies like Weaveworks and Rancher, and they're all doing something interesting. There's a very interesting problem here. It's just a big problem, and it's taking us some time to basically pull up the thread to get to the real answer. Part of my, I guess, objection to it, for lack of a better term, is that I was never an application developer. If you've seen any of the code I've written, it is blindingly apparent why that is. Fizzbuzz is sort of the pinnacle of problems I don't know how to solve. But I do come from the ops world, where I was a grumpy Unix systems administrator, because it's not like there's a second kind of

Unix systems administrator. I automatically became dour and sarcastic and aged 40 years in the afternoon that I was first anointed. And my challenge with what I see of Kubernetes, and to be clear, it has been a couple of years since I last played with it in any real depth, that the implementation and rolling out a stable Kubernetes platform on top of a single cloud provider, let alone multiple cloud providers, was basically the sort of work that took months. And then by the time you were finished, the level of observability into what was going on inside of that platform when you started seeing intermittent issues was, back then at least, either non-existent or incredibly complicated. Is that still the case? Well, I don't think Kubernetes is solving that problem.

So that would be like saying, I deployed this fleet of Linux on bare metal, and how do I determine what the motherboard temperatures are? How do I determine what the Spitty disk or the SSD temperatures are? You have to have a framework for that. And what Kubernetes is doing is giving you a framework. It's basically giving you the base of an operating system

with which you can build on it. And fortunately, and this is actually the greatest thing, is that in a lot of cases, Kubernetes doesn't have a lot of opinions on things like monitoring. You can get pod and node CPU and memory statistics, but there's other tools out there like what Prometheus has done that needs to be applied that you can actually get the fidelity of what you want. The problem is that there is a lot of tooling out here, and you might not know, and if you do know, you might not be able to get it installed right, and that's still a problem. But I don't think it's strictly a Kubernetes problem.

Kubernetes is like blaming Linux for... Here's a great one. It's like blaming Linux for LS not working. And you might think, well, what are you talking about? My LS command doesn't work. Well, guess what? That's not Linux. Kubernetes is the kernel, and we need to really work on user land. Yeah, no, you're absolutely right. If the stat call isn't working that I lost calls, then we're having a different conversation. But until then, it's user land. That's right. My arguments, and I made this a little over a year ago now on Twitter, and it caused a stir that in five years from now, no one is going to care about Kubernetes, was my hot take. And I just re-upped it back in February and said, four years. And I maintain that I'm probably right on this, but from the perspective, not that it's going to

dry up and blow away. I think that only a moron would suggest such a thing now, but rather that it's going to slip below the surface of awareness. How many people need to be in-depth Linux systems experts today versus 10 years ago? It's still going to be there, but we don't really care how applications or workloads get orchestrated in the cloud or in our environment. It just happens. Well, that's the whole point.

I think that you are correct. If someone asks me about that, I will deny saying that. But Kubernetes will go away. So here's a good example. Let's see, about three years ago or four years ago, how do you install Kubernetes? That was the buzz. How do you install Kubernetes? And throughout the years where we have cloud providers and then we have vendors like Rancher, what we did at Heptio, and Red Hat, and others, installing Kubernetes is not really a problem anymore.

Even on my development machine, I have a very large Mac, and right now I'm running six instances of Minikube, all 12 gigs of memory apiece. No problem. Spin them up, spin them down. What's going to happen with Kubernetes over the next few years is that these things that we consider hard and consider difficult, we're going to solve them. And we're going to solve them in a way

where they actually do disappear. And we're going to find a new set of problems because I'll tell you what, I've been doing, I've been coding for money for 25 years now, actually a little bit more. And when I started out like you, I was a sysadmin. And there was no, I mean, I had Linux on my desktop at home, but we did Sun and we did

HPUX and we did AIX. And guess what? We've moved past all that right now. If you gave somebody an HPUX box or no, even better yet, you gave somebody an AIX box with their crazy corn shell, people would look at you like you're right now. If you gave somebody an HPUX box, or no, even better yet, you gave somebody an AIX box with their crazy corn shell, people would look at you like you're crazy now. Where's my bash? Where's my Zed shell? Where's my fish? So we'll move past it. And I think that that type of shift becomes largely inevitable. It's just challenging as we go through the period before we get there. I mean, even from my somewhat removed

perspective as a cloud economist looking at companies' very interesting AWS bills, Kubernetes still causes challenges, where from the infrastructure point of view, when you have a full Kubernetes environment, there's a single application workload that's running from the cloud provider's perspective called Kubernetes. So when you see interesting data transfer patterns, interesting disk access patterns, it's just a very, very strange single-tenant application. Now, once you get a level of visibility into what namespaces are running,

what workloads have been migrated into Kubernetes, and how those things interact, suddenly you see an entire ecosystem of an entire microservices application, in most cases, that is working and humming away. But it is abstracted far enough away from what's happening underneath that it becomes almost incomprehensible. I'm not saying that's necessarily a problem from the user or operator experience, just from a billing optimization perspective, which, surprise,

was never anyone's first goal when building pretty much anything. Can I build this for the least amount of money possible is not usually the clearest path to success for most products. Who knew? Yeah, you know, something interesting is, so I have built a cloud. I have worked for clouds. I worked for things that became clouds. And now I work at a vendor. And I'll tell you what, from what I've seen of VMware's Project Pacific and the new way of thinking

about running Kubernetes on vSphere, if you're still running your own data center, I think that some of the things that you brought up, like making Kubernetes that opaque thing, are going to be a thing of the past. And I don't work on that team, so I actually can't tell you what they're doing because I have no idea. But from what I've seen of the past. And I don't work on that team, so I actually can't tell you what they're doing because I have no idea. But from what I've seen of the demos at various places is that I think

that once we've learned, so it took us a while to actually learn what Kubernetes was and how it felt and how it tasted. And now that we have that, what we can now do is start molding it into our environments. And we're seeing that with VMware and Project Pacific. We're seeing that Google, for better or for worse, GKE is actually a great Kubernetes experience. And I think Microsoft and maybe even Amazon are thinking about this in a little bit different way now. So I think what's going to happen is we expected that this thing was going to be a panacea and solve all of our problems. But us being well-adjusted adults should know that there's no such thing. And that new tech takes a long time, especially

big tech, takes a long time to integrate. And we're just going through that cycle right now. But people are seeing successes, and I enjoy that piece. You mentioned Project Pacific a minute or two ago. What exactly is that? So what Project Pacific is, and once again, disclaimer, I do not work on that team, and I am not really familiar with how vSphere works. So you have your vSphere cluster. You can enable Project Pacific on it whenever it comes out, and I don't know when. And then what happens is it gives you this concept of a supervisor cluster that can actually manage other customers or clusters. So you can give all your developers their own clusters, and it becomes a real part of vSphere. So if you're using VMware's networking technology, whatever NSX that you happen to be using,

I think it works well with that. And then you also get access to like vSAN and you have real access to disk and it just becomes another way to run your workloads on vSphere. And one neat piece about this, and I think AWS and Microsoft are able to do this right now as well,

is that whenever you boot up a pod and a pod in Kubernetes is just a container or actually a set of containers that run your applications, they boot up in a VM. So now you get all the same benefits that boot running in a VM. So you get your own set of isolation and things like that. So I'm enjoying seeing that we can take this thing like Kubernetes and we can apply it to different domains. And of course, everybody doesn't run VMware stuff, but most people do. If you're running in the cloud, and this is the crazy part, hold with me here for a second, is that we always talk about moving between clouds and it doesn't work. Yeah, it doesn't work because it's an impedance mismatch. But being able to run Kubernetes in more than one place and actually being able to abstract the way disk with CSI that's built into

Kubernetes and extract the way network with CNI does get you closer to that place where you can move workloads. Will it work all the time? Probably not, but many times it will. Are you running critical operations in the cloud? Of course you are. Do you have a disaster recovery strategy for your cloud configurations? Probably not, though your finders will say otherwise. Your DevOps teams invested countless hours on those configs, so don't risk losing them. Firefly makes it easy. They continuously scan your cloud and then back it up using infrastructure as code, and most importantly, enable quick restoration. Because no one cares about backups, they care about restorations and recovery.

Be DR-ready with Firefly at firefly.ai. One of the, I think, common misconceptions about how I tend to approach things is I speak to the general case and people tend to assume as a result that I'm speaking to individual specific cases. Multi-cloud is a terrible best practice rant is a great example of this. I think that if you're designing something today, Greenfield, that you're aiming to deploy seamlessly into multiple clouds, barring a few edge cases, it's probably not the right this. I think that if you're designing something today, Greenfield, that you're aiming to deploy seamlessly into multiple clouds, barring a few edge cases, it's probably not the right direction to go in. That said, if you take a look at existing workloads or where there is a requirement

to do this, then full speed ahead, it's important that there be solutions that address all of these problems. I try and guide towards the common case of what people are considering as they're just dipping their toes into this cloud world. Big E Enterprise has so many interesting workloads and so many fascinating stories within it that I feel like it's not getting the kind of attention that it deserves. Oh, that's legacy code. By legacy, we of course mean revenue generating. And what does that nonsense do? Only about $8 billion a year in revenue. Why do you ask?

Oh, you should move it to serverless. You should move yourself somewhere else because that's not ever going to be a viable story. Being able to meet customers where they are and give them the ability to migrate where they are from where they are to where they want to be, to be able to address emerging technology trends and be able to effectively speed the time

from a developer having an idea to that code running in production is really what it's all about. And I feel like right now, a lot of the arguments in this space have lost sight of that and have instead focused on the best way to achieve that goal,

but have lost sight of that goal itself. Well, that's the problem. Whenever you look for the best way to solve something, that only works for you in that individual time and probably will never work again. And right before Heptio, I worked for an enterprise, large bank, and we did multi-cloud. And I'll tell you what, we were not moving workloads between cloud one and cloud two. We had workloads that ran in cloud one, and we had workloads that ran in cloud two. And maybe we backed up some data between them. But even with us, and literally had an army of developers and engineers that could do all these things, and more money than you could shake a stick at, and we could not do it.

But what we did is that we just found that best practices work everywhere. And the crazy thing is that, you know, you think that moving to the cloud is your biggest concern. I bet your CI and CD pipelines aren't very good. I bet the way that you actually deliver software to production isn't very good. Maybe we should spend more time focusing on those things. So whenever we have to move our platform, because we will one day, it'll be easier. We can just re-platform it. And I'm waving my hands now like it's magic because to the people who don't prepare, it does look like magic. But it's just that we work hard and that we have an actual goal and we have a plan to get to that goal.

And then we use that and form a strategy and do the right thing. It feels to me on some level, like one of the greatest challenges that VMware has as a company is in their name. It's progressed so far beyond, hey, I want to virtualize a machine somewhere. How do I do that? Once upon a time, that was super hard and expensive. And believe it or not, back then I was very anti-virtualization. I think I called it a flash in the pan. Surprised, I was wrong. Further surprise, as a futurist, if you get it wrong, no one ever calls

you to account for it, which is super awesome. Obviously, I was very wrong on that. And now there's so much more capability stories. VMware has exploded into the modern cloud era in a way that, honestly, I don't think most people saw coming. And on some level, it just sounds like it's aimed at the problems of yesteryear, even though it's very much not. So VMware is way older than my tenure there. They did a whole bunch of interesting things in virtualization and then networking and storage, this whole concept of a virtual data center, software-defined data center. You know, I think they do a pretty good job at that. So I think that the executives, they realized that, and that's why we have this new brand called Tanzu. It's our cloud-native brand. And what we'll see over, I actually don't know,

over the next few months, over the next few years, we will start shipping a new breed of software on there. And whether it be things like Tanzu Mission Control, which is helping development teams or actually helping enterprises manage the clusters, Kubernetes clusters they have, or if it's something in actually boot manage the clusters, Kubernetes clusters they have, or if it's something in actually booting up clusters, whether it be on vSphere or not, or is it

something that I'm doing where we're looking at the developer experience? I think that the powers that be decided that that's a whole brand new experience for VMware, so let's give it a new name. And it's Tanzu, not Tanzu, Tanzu. We do care intimately about pronunciation of various things on this show. That has been a bastion since the beginning. In fact, we're still very happy with the story that you folks got out of your acquisition of Bitten AMI. Some folks call it Bitnami. Those folks are wrong. You said Bitnami. I'm sorry. Oh, yes. Both of the founders of Bitnami, basically Facepalm.

My personal theory is that Erica Brescia left to get away from my mispronunciation of companies. And as a result, that's why she's now the COO of Jithub. Right. Well, of course, that's actually pretty funny. And I actually work with the other founder on projects, so I will be sure to use that pronunciation. Oh, the best jokes needle at people to the point where they're lying awake at night, just angry about them, but they don't punch down at anyone. That's the trick. Yes, definitely. And that's actually, that's an interesting segue if we were to take it. By all means. So I think that one of the reasons why I do podcasts like this is people see me on Twitter and they see what I say and I want them to be able to hear the voice and then hear that

whenever we talk about things that are bad, we're just sharing what we see from our point of view and we're not punching down on it. If I say that, you know, I'm not underrepresented anymore and you're overrepresented, that's not me punching at you. That's me changing the conversation so I don't sound like I'm less than you. And I think that we need more people doing these things out there, speaking their voices, who come from varied backgrounds and have varied experiences. Because you know what? We've been doing this whole white guy thing for a couple hundred years in this country. And I don't know, we might need to hit the reset button and try over again. But things are going oh so very well for everyone right now. What could you possibly mean? No, I'm right there with you on that. I try mightily to reach out to folks who don't look exactly like me.

A weird dynamic that I've noticed has emerged in the general sense, where I invite people from all walks of life onto the show. Invariably, when I wind up reaching out to folks who look like me, I can't even get the word podcast out completely before I get a hell yes, let's do it. Other folks, because of the nature of the world in which we live, have to be more guarded with that. There's a whole series of questions that people want to know of. Am I a secret trash goblin? Am I trying to do this to push a narrative that's going to be awful? I hope the answer to that's no, and I continue to get folks from a tremendous variety of different backgrounds and different employment situations onto the show.

But no one knows their own reputation. I hope I'm doing the right things. But at some point, all we can do is guess and do our best and try again tomorrow. Yeah, when I was growing up, my dad used to say, be the change you want to see. And that's all I you want to see. And that's all I'm trying to do. I'm trying to be forever positive, even though I see all the weirdness around me. And show people that if we can take control of what's going on now, we can actually take control of our futures and never let anyone tell you that, no, you can't do that. Unless it's something wrong, then you shouldn't be doing that.

But for our careers and our careers in tech and our careers in tech-adjacent things, I want to go two years from now, I want to be the best JavaScript developer in the world. Put in the work, let's go do it. And I think that if anyone should be able to have those kinds of thoughts, if they can put in the work and they should go do it. And they shouldn't have to be scared that someone else is going to steal their thunder or someone's going to look over them because they are of a certain way. And that's just not right. And that's why I use myself.

I mean, I'm, I don't know, third highest level of engineer at VMware. I am the probably, I think I am, the highest ranked engineer of African engineer at VMware. I am the probably, I think I am the highest ranked engineer of African descent at VMware. I have a lot to lose, but I also have a lot to gain by helping you out. So that's why I'm out here having these conversations with people. From my perspective, I mean, I'm a white guy in tech. My failure mode is a board seat in a book deal. So I feel like I have virtually nothing to risk. So what I did as soon as I had the platform was start attempting, with mixed success,

to get this to a point where other people can use the platform to tell their stories. I've learned an awful lot along the way, and Lord knows I'm not done yet. One thing that continues to surprise me, and some folks may have noticed this, and I don't think I've talked about it yet on this podcast, but I've started making fun of things like service names a lot more than the actual substance of newly launched services. Because it turns out that, sure, you have these giant companies out there that are launching these things, and yeah, I can make fun and it's punching up at giant multinationals, but there's usually a small team internally who lost blood, sweat, tears, and weekends

building a service. And if the first thing that comes out of it is me making fun of it, that doesn't feel too great. So making fun of service namings, which people did not spend 18 months on, I hope, is the sort of thing where it's still fun, it's still jocular, but no one hears what I have to say and feels crappy as a direct outgrowth of that. Some days I get it completely wrong, but I am trying. So that's an actual interesting way of thinking about it. It is about, I have to think about things that I say sometimes because if I typed or said what I thought, then people wouldn't have the context. So I started doing this whole whiteboard series, and it's all satire.

And it's all poorly done of me sitting in front of a whiteboard with a T-shirt and something on the whiteboard. And that's actually how I do it. It basically de-arms my message, but my message still gets across. And I think that we all need to find our ways with which we can share our message and get those feelings out because I don't want to sit on some of my inks to go crazy again. It's different messages resonate in different ways. I find that sarcasm was my first language growing up. So it was always an easy path for me to go ahead and, all right, that quiet voice inside, why don't you try using that and see if it resonates with anyone else? It turns out it does, but now it's a question of, great, what do I do beyond that? Just being snarky and crappy and

sarcastic about everything doesn't get very far. I mean, having you on the show, for example, and then if we'd spent the last half hour of me making uninformed but belligerent comments about Kubernetes, that doesn't build anything. And it just cements the idea that this entire industry has to be oppositional, where in order for one thing to succeed, other things have to fail. And I don't believe that that's the case, nor has it ever been. No, it's not. And you know what?

I envy people who can be sarcastic all the time. I mean, I'm mostly a cynic, but I can't be sarcastic because in a workplace, people get scared and they take me too seriously. So I have to really be direct with what I'm saying. So I'm envious of that. But on the other side, I respect it. And I also respect people who can inflect on themselves and understand that this is how they are being presented in the world and how they are presenting themselves in the world. So it takes all kinds to make a village. So we can't say how people should be. But as long as you're not doing anyone dirty, not punching down, or really, you know, not even punching up. You shouldn't be

punching up. You should be kind of like, I don you know, not even punching up. You shouldn't be punching up. You should be like, kind of like, I don't know, maybe we should punch up, but don't ever punch down. That's the rule. And if it helps anything, my sarcastic nature was the number one contributor to the reason that I spent most of my 20s getting fired energetically from all kinds of companies. It takes time to season it and find a path forward. I don't recommend this for anyone. I just do it because I don't know how to do anything else. I've only been fired twice for my first two jobs. And I learned very important lessons about the world. But ever since then, usually what happened is, oh, I'm not going to get promoted. Well, I'm out of here. And to the

point of, I would left on one day, the guy said, well, I don't think this is going to, promoted, well, I'm out of here. And to the point of, I would left on one day, the guy said, well, I don't think this is going to, you're going to get promoted this cycle. And I said, well, that's cool. And if I don't, I'm taking me and the rest of the assistive meds with me today. And he laughed. So I took him, I took the rest of the assistive meds with me today. We walked out of that office. But over the past few years, it's been getting better, where I find that at least at first, people are pretty welcoming. And now that I have this position at VMware, and I think it's definitely been a lot better.

So, hey, kids, it can get better. And then also, don't speak your mind all the time. Sometimes just keep it to yourself. I have no ability to do that. Oh, I wish. I mean, this is why I have a wife. I just save it all up for her. And then whenever she's done working,

I tell her all the things that I was going to tell somebody else. And she does the same to me. And then we're both better for it. I made the interesting life decision of marrying a corporate attorney, and suddenly I have a different level of scrutiny on some of my more energetic online stunts.

But it's definitely been an ongoing process. We do the best that we can. If people want to find you on the internet to hear more about your philosophy on these things, about how the Kubernetes developer experience is continuing to evolve, and other thoughts and commentary, where can they find you? So I have a Twitter account. It's B-R-Y-A-N-L. And then I also have an Instagram account that I'm not going to tell you about because I can't understand Instagram. I don't understand the

whole picture thing. And so we'll just stick to Twitter. Thank you. I thought it was just me. The closest I get to Instagram is mispronouncing it as Quinstagram, and then everyone groans and won't talk to me anymore. Yeah, I think I have like eight posts over many years, and that's about where I am with Instagram. Well, we will put the link to the Twitter account in the show notes.

Brian, thank you so much for taking the time to speak with me today. I appreciate it. Oh, thank you for having me. Brian Lyles, Senior Staff Engineer at VMware. 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 in Apple Podcasts. And if you hated this podcast, please leave a five-star review in Apple Podcasts and a funny comment so I know where to improve.