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 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 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, um, 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, 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 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 works.
It winds up having a failure mode that's awful.
I know, but real talk, I could ignore you on any platform.
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 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 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.
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?
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, you know, 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, 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 command doesn't work.
Well, guess what?
That's not Linux.
Kubernetes is the kernel.
And we need to really work on userland.
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.
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, 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.
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 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.
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, 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?
Yeah, you know, something interesting is, So, I have built a cloud.
I have worked for clouds.
I work 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 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
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 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, 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.
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 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.
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 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 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.
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.
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 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 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 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.
You said Bitten AMI.
I'm sorry.
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.
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.
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, Oh, 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
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.
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'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 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.
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 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's, it 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.
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.
No, it's not.
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.
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 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 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, 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.
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?
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.
Uh, the closest I get to Instagram is mispronouncing it as Quinnstagram.
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 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.