Subscribe
Share
Share
Embed
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.
Bryan Liles: [00:00:00] 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.
Corey Quinn: 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
Bryan Liles: having me.
Corey Quinn: 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 S3 compatible 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 [00:01:00] crossed paths, I want to say, at KubeCon in Barcelona in 2019.
Bryan Liles: 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, um, I promptly forgot, and Corey just pinged me, and here I am.
Corey Quinn: 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 Liles: Yeah, yeah, so that's about what happens, and really it's, it's, it's about how I use Twitter.
I mean, I hate to be selfish, but I don't like the DM feature. If I [00:02:00] really want to talk to you, I'll give you my email.
Corey Quinn: 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 works.
It winds up having a failure mode that's awful.
Bryan Liles: I know, but real talk, I could ignore you on any platform.
Corey Quinn: 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 Liles: 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 [00:03:00] applications. And with that comes a whole smathering 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 an 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. Um, you could deploy applications to Linux and not be a Linux developer. Expert. Tell me, 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 [00:04:00] up?
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 Quinn: 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.
Create 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 Liles: No, I would not disagree with that. So, Kubernetes will be six years [00:05:00] 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.
Corey Quinn: 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 [00:06:00] 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?
Bryan Liles: Well, I don't think Kubernetes is solving that problem. So that would be like saying, you know, I deployed this fleet of Linux on bare metal and. How do I determine what the motherboard temperatures are? How do I [00:07:00] determine what the, you know, SPDI 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 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, 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 a, strictly a Kubernetes problem. Kubernetes is, is, it's like blaming Linux for, um, 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 [00:08:00] command doesn't work. Well, guess what? That's not Linux. Kubernetes is the kernel. And we need to really work on userland.
Corey Quinn: Yeah, no, you're absolutely right. If the stat call isn't working, then we're having a different conversation.
But until then, it's userland.
Bryan Liles: That's right.
Corey Quinn: 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, 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 Liles: Well, that's the whole point. [00:09:00] I think that you are correct. Um, 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 [00:10:00] 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 crazy now. Where's my bash? Where's my zed shell? Where's my fish? So we'll move past it.
Corey Quinn: 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 [00:11:00] 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, uh, 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 Liles: Yeah, you know, something interesting is, So, I have built a cloud. I have worked for clouds. I work for [00:12:00] 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 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, it's 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, um, VMware and Project Pacific.
We're seeing that, um, Google, for better or for worse, uh, GKE is actually a great tool. Kubernetes experience. And I think Microsoft and, and maybe even Amazon are, are [00:13:00] 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 Quinn: You mentioned Project Pacific a minute or two ago.
What exactly is that?
Bryan Liles: 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 [00:14:00] 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 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 the crazy part, [00:15:00] 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, uh, impetus 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 extract away 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.
Corey Quinn: 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 binders 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 [00:16:00] DR ready with Firefly at firefly. com.
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 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, 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.[00:17:00]
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.
Bryan Liles: 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 [00:18:00] 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 you, 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, you know, To the people who don't prepare, it does look like magic.
But it is, it's [00:19:00] 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 Quinn: 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 Liles: So VMware is way older [00:20:00] 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 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, um, 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 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 [00:21:00] give it a new name.
And it's Tanzu. Not Tanzu. Tanzu.
Corey Quinn: We do care, intimately, about pronunciation of various things on this show. That has been a bastion since the beginning. In fact, we are 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.
Bryan Liles: You said Bitten AMI. I'm sorry.
Corey Quinn: Oh, yes. Both of the founders of Bitten AMI, um, basically Facepalm. My personal theory is that Erika Brescia left to go, uh, to get away from my mispronunciation of companies. And as a result, that's why she's now the COO of Jithub.
Bryan Liles: Right. Oh, well, of course. That's actually pretty funny and I actually work with the other founder on, on projects, so I will be sure to use that pronunciation.
Corey Quinn: 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. [00:22:00] That's the trick.
Bryan Liles: Yes, definitely. And that's actually, Oh, that's an interesting segue if we were to take it.
Corey Quinn: By all means.
Bryan Liles: 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 various backgrounds and, 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 Quinn: But things are [00:23:00] 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 [00:24:00] try again tomorrow.
Bryan Liles: 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, you know, 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, you know, 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 [00:25:00] 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 Quinn: 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 as soon as I had the platform was start attempting, with mixed success, to get this to a point where I could 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 [00:26:00] 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 Liles: 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's, it [00:27:00] basically de arms my message, but my message still gets across. And, and I think that we all need to find our ways with which we can share our message and, you know, get our, get those feelings out because I don't want to sit on some of my inks to go crazy.
Corey Quinn: 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 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.
Bryan Liles: No, it's not. [00:28:00] And I, 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 like, kind of like, I don't know, maybe we should punch up, but don't ever punch down.
Corey Quinn: 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 [00:29:00] 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 Liles: 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 was 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 sysadmins with me today. And he laughed. So I took him, I took the rest of the sysadmins with me today, and 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 [00:30:00] also, don't speak your mind all the time. Sometimes just keep it to yourself.
Corey Quinn: I have no ability to do that.
Bryan Liles: Oh, I wish. I mean, this is why I have a wife. I just save it, I save it all up for her. And then when I, 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, and then we're both better for it.
Corey Quinn: 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, 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 Liles: 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 [00:31:00] Instagram. I don't understand the whole picture thing. And so we'll just stick to Twitter.
Corey Quinn: Thank you. I thought it was just me.
Uh, the closest I get to Instagram is mispronouncing it as Quinnstagram. And then everyone groans and won't talk to me anymore.
Bryan Liles: Yeah, I think I have like eight posts over many years and that's about where I am with Instagram.
Corey Quinn: 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.
Bryan Liles: Oh, thank you for having me.
Corey Quinn: 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 5 star review in Apple Podcasts. And if you hated this podcast, please leave a 5 star review in Apple Podcasts and a funny comment so I know where to improve.