Subscribe
Share
Share
Embed
Bryan Liles is a senior staff engineer at VMware who leads the developer experience group, which focuses on improving Kubernetes productivity. Previously, Bryan worked as an engineer at Heptio, served as the director of Capital One’s cloud engineering team, worked as a cloud engineer at DigitalOcean, and was the CTO at Thunderbolt Labs, among other positions.
Join Corey and Bryan as the explore what it’s like to be on the VMware engineering team, why Bryan spends a lot of his time conducting research, what Corey think the future of Kubernetes looks like and why Bryan agrees, why Twitter’s DM feature leaves much to be desired, what VMware is focusing on over the coming months and years, what Corey’s recipe for the best jokes looks like, how Bryan is focused on being “forever positive” and his advice for other people on taking control of their futures, how Bryan got fired from his first two jobs and what he learned from those experiences, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is brought to you by DigitalOcean, the cloud provider that makes it easy for startups to deploy and scale modern web applications with, and this is important to me, no billing surprises. With simple, predictable pricing that’s flat across 12 global data center regions and UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business. See what businesses are building on DigitalOcean and get started for free at do.co/screaming. That’s D-O-Dot-C-O-slash-screaming and my thanks to DigitalOcean for their continuing support of this ridiculous podcast.
Corey: This episode is sponsored in part by N2WS. You know what you care about? Many things, but never backups at least until right after you really, really, really needed to care about backups. That's what N2WS does for your AWS account. It allows you to cycle backups through different storage tiers so you can back things up cost-effectively and safely. For a limited time, N2WS is offering you a hundred dollars in AWS credits for setting up their free trial, and I encourage you to give it a shot. To learn more, visit snark.cloud/n2ws. That's snark.cloud/n2ws.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Bryan Liles, Senior Staff Engineer at VMware. Bryan, welcome to the show.
Bryan: Thanks for having me.
Corey: 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.
Bryan: 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.
Corey: 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.
Bryan: 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.
Corey: The problem is 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.
Bryan: I know. But real talk; I could ignore you on any platform. So—
Corey: Oh, absolutely.
Bryan: I was trying to be nice.
Corey: 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.
Bryan: 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, I’m 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.
Corey: 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?
Bryan: 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, I worked at Heptio, and Heptio got bought by VMware, and that's is a success in itself. We have companies like Red Hat, they 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 at the thread to get to the real answer.
Corey: 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 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. That's still the case?
Bryan: 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 [00:08:18 unintelligible] 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, in a lot of cases, Kubernetes doesn't have a lot of opinions on things like monitoring. You can get pod and node CPU 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, is that there is a lot of tooling out here and you might not know. 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 a strictly a Kubernetes problem. Kubernetes is—it's 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.
Corey: Yeah, no, you're absolutely right. If the stack call isn't working, that I lost calls, then we're having a different conversation. But until then, it's user-land.
Bryan: That’s right.
Corey: 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.
Bryan: Well, that's the whole point. I think that you are correct. If someone asked 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 problems. 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 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 HP-UX and we did AIX. And guess what? We've moved past all that right now. If you gave somebody an HP-UX box, or no, even better yet, you gave somebody an AIX box with their crazy Korn shell, people would look at you like you're crazy now. Where's my bash? Where's my sed shell? Where's my fish? So, we'll move past it.
Corey: 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?
Bryan: Yeah, you know, something interesting is so I built a cloud, I work for clouds, I work with things that became clouds, and now I work at a vendor. And I'll tell you what, from what I've seen, VMware is 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 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.
Corey: You mentioned Project Pacific a minute or two ago. What exactly is that?
Bryan: 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 as 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 of that, but 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 a impedance mismatch. But being able to run Kubernetes in more than one place, and actually being able to abstract away disk with CSI that's built into Kubernetes and abstract away network with CNI, does get you closer to that place where you can move workloads. Well, they work all the time? Probably not. But many times it will.
Corey: This episode has been sponsored by CHAOSSEARCH. If you have a log analytics problem, consider CHAOSSEARCH. They do sensible things like separating out the compute from the storage in your log analysis environment. You store the data in S3 in your account. You know where it lives, you know what it costs, and then they compress it heavily while indexing it, and then they query that data using a separately scalable fleet of containers. Therefore, the amount of data you’re storing no longer is bounded to how much compute you throw at it, as well. It’s broken that relationship, leading to over 80 percent cost savings in most environments, and being a sensible scaling strategy while still being able to access it through the API’s you’ve come to know and tolerate. To learn more visit CHAOSSEARCH.io.
Corey: 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 direction to go in. That said, if you take a look at existing workloads, 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 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 instead focused on the best way to achieve that goal, but have lost sight of that goal itself.
Bryan: 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 I bet—and the crazy thing is that, 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 our strategy, and do the right thing.
Corey: 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. Surprise, 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.
Bryan: 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, think they do a pretty good job at that. So, I think that the executives, they realize 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 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 TAWN-zoo, not TAN-zoo. TAWN-zoo.
Corey: We do care intimately about pronunciation of various things on this show. That has been a bastion since the beginning. In fact, we were still very happy with the story that you folks got out of your acquisition of BIT-n-ay-em-eye. Some folks call it BIT-nah-mee. Those folks are wrong.
Bryan: You said BIT-n-ay-em-eye. [laughs]. I'm sorry, that’s funny.
Corey: Oh, yes, both of the founders of BIT-n-ay-em-eye 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 GIF-huhb.
Bryan: 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.
Corey: 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.
Bryan: Yes, definitely. And that's an interesting segue if we were to take it.
Corey: By all means.
Bryan: 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 the 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 various 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.
Corey: 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 is 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.
Bryan: Yeah, when I was growing up, my dad used to say, “Be the change 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 a certain way. And that's 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 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.
Corey: From my perspective, I mean, I'm a white guy in tech. My failure mode is a board seat and a book deal. So, I feel like I have virtually nothing to risk. So, what I did is, 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.
Bryan: So, that's a actual interesting way of thinking about it. I 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's 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 angst, go crazy. Again.
Corey: It's different messages resonate in different ways. I find that sarcasm was my first language growing up. So, it was always a easy path for me to go ahead and alright, 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 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.
Bryan: No, it's not, and you know what, I envy people who can be sarcastic all the time. I mean, I'm mostly 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 them 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 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.
Corey: 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.
Bryan: 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 you're going to get promoted this cycle.” And I said, “Well, that's cool. If I don't, I'm taking me and the rest of the sysadmins with me today.” And he laughed. So, I took him—I took the rest of the sysadmins 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 it's definitely been a lot better. So, hey, kids, it can't get better. And then, also don't speak your mind all the time. Sometimes just keep it to yourself.
Corey: I have no ability to do that.
Bryan: Oh, I wish. I mean, this is why I have a wife.
Corey: Yes.
Bryan: I 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.
Corey: 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?
Bryan: So, I have a Twitter account. It's @bryanl. 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.
Corey: Thank you. I thought it was just me. The closest I get to Instagram is mispronouncing it as QUINN-stagram, and then everyone groans, and won't talk to me anymore.
Bryan: Yeah, I think I have like, eight posts over many years. And that's about where I am with Instagram.
Corey: Well, we will put the link to the Twitter account in the [00:32:16 show notes]. Bryan, thank you so much for taking the time to speak with me today. I appreciate it.
Bryan: Oh, thank you for having me.
Corey: Bryan 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 on 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.
Announcer: 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.