December 19, 2024 • 35 mins
The tech industry is getting long enough in the teeth that now there are some bonafide old fogeys. Nevertheless there, fortunately, are plenty of younger tech folks out there pushing the thought and mentality of the industry forward. Andrew Brown, Co-Founder and Cloud Instructor at ExamPro Training Inc certainly is, but his presence in the community is so much more! On this Screaming in the Cloud Replay, Andrew talks about the various internet platforms that he stays active on, and his mission to provide education on the cloud. Importantly so, Andrew does so with an immense amount of generosity. As he puts it, he couldn’t imagine taking money for the courses that he has created. Andrew and Corey discuss at length their thoughts on cloud certifications, the worth of multicloud, and much more!
Show Highlights
(0:00) Intro
(0:41) The Duckbill Group sponsor read
(1:15) Why Corey struggles to keep up with Andrew’s impressive online presence
(2:47) Explaining ExamPro
(6:39) The troubles of online “experts”
(13:01) Andrew’s thoughts on using certifications as proxies
(18:14) The value of certification vs. your level of experience
(22:47) The Duckbill Group sponsor read
(23:30) Should engineers learn more than one cloud provider?
(27:10) Is multi-cloud actually the way to go?
(34:31) Where you can find more from Andrew
About Andrew Brown
Andrew Brown has been working in tech 15 years. Today, he creates free cloud certification courses where he teaches people Cloud, DevOps, Data, ML, Security, K8s and Serverless.
Links
- ExamPro Training, Inc.: https://www.exampro.co/
- PolyWork: https://www.polywork.com/andrewbrown
- LinkedIn: https://www.linkedin.com/in/andrew-wc-brown
- Twitter: https://twitter.com/andrewbrown
Original Episode
Sponsor
The Duckbill Group: duckbillgroup.com
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
A lot of people I don’t think have actually gone across the cloud, right?
(00:02):
So, they’re sitting from their chair, only staying in one vertical
saying, “Well, you can’t learn them all at the same time.” And
I’m going, “I see a way that you could teach them all at the
same time.” And I might be the first person that will do it.
Welcome to Screaming in the Cloud.
I’m Corey Quinn.
My guest today is… well, he’s challenging to describe.
(00:24):
He’s the co-founder and cloud instructor at ExamPro Training, Inc.
but everyone knows him better as Andrew Brown because he does so
many different things in the AWS ecosystem that it’s sometimes
challenging—at least for me—to wind up keeping track of them all.
Andrew, thanks for joining.
Hey, thanks for having me on the show, Corey.
This episode is sponsored in part by my day job, the Duckbill Group.
(00:46):
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
Negotiating your next long term contract with AWS.
Or just figuring out why it increasingly resembles a
phone number, but nobody seems to quite know why that is.
To learn more, visit duckbillgroup.com.
(01:07):
Remember, you can't duck the duck bill, Bill.
And my CEO informs me that is absolutely not our slogan.
How do I even begin describing you?
You’re an AWS Community Hero and have been for almost two years, I believe;
you’ve done a whole bunch of work as far as training videos; you’re, I
think, responsible for #100daysofcloud; you recently started showing up
(01:30):
on my TikTok feed because I’m pretending that I am 20 years younger than I
am and hanging out on TikTok with the kids, and now I feel extremely old.
And obviously, you’re popping up an awful lot of places.
Oh, yeah.
A few other places like PolyWork, which is an alternative to LinkedIn,
so that’s a space that I’m starting to build up on there as well.
Active in Discord, Slack channels.
I’m just kind of everywhere.
(01:51):
There’s some kind of internet obsession here.
My wife gets really mad and says, “Hey, maybe tone
down the social media.” But I really enjoy it.
So.
You’re one of those folks where I have this challenge of I wind up
having a bunch of different AWS community Slacks and cloud community,
Slacks and Discords and the past, and we DM on Twitter sometimes.
And I’m constantly trying to figure out where was
that conversational thread that I had with you?
(02:14):
And tracking it down is an increasingly large search problem.
I really wish that—forget the unified messaging platform.
I want a unified search platform for all the different
messaging channels that I’m using to talk to people.
Yeah, it’s very hard to keep up with all the channels for myself there.
But somehow I do seem to manage it, but
just with a bit less sleep than most others.
Oh, yeah.
It’s like trying to figure out, like, “All
(02:35):
right, he said something really useful.
What was that?
Was that a Twitter DM?
Was it on that Slack channel?
Was it that Discord?
No, it was on that brick that he threw through my window with a note tied to it.
There we go.”
That’s always the baseline stuff of figuring out where things are.
So, as I mentioned in the beginning, you are the co-founder and cloud instructor
at ExamPro, which is interesting because unlike most of the community stuff
(02:56):
that you do and are known for, you don’t generally talk about that an awful lot.
What’s the deal there?
Yeah, I think a lot of people give me a hard time because they say,
Andrew, you should really be promoting yourself more and trying to
make more sales, but that’s not why I’m out here doing what I’m doing.
Of course, I do have a for-profit business called ExamPro, where we create
cloud certification study courses for things like AWS, Azure, GCP, Terraform,
(03:20):
Kubernetes, but you know, that money just goes to fuel what I really want
to do, is just to do community activities to help people change their lives.
And I just decided to do that via cloud because that’s my domain expertise.
At least that’s what I say because I’ve
learned up on in the last four or five years.
I’m hoping that there’s some kind of impact I can make doing that.
I take a somewhat similar approach.
(03:40):
I mean, at The Duckbill Group, we fixed the horrifying AWS bill, but I’ve always
found that’s not generally a problem that people tend to advertise having.
On Twitter, like, “Oh, man, my AWS bill is killing me this month.
I’ve got to do something about it,” and you check
where they work, and it’s like a Fortune 50.
It’s, yeah, that moves markets and no one talks about that.
So, my approach was always, be out there, be present in the
(04:01):
community, talk about this stuff, and the people who genuinely
have billing problems will eventually find their way to me.
That was always my approach because turning
everything I do into a sales pitch doesn’t work.
It just erodes confidence, it reminds people of the used mattress
salesman, and I just don’t want to be that person in that community.
My approach has always been if I can help someone with a
(04:22):
15-minute call or whatnot, yeah, let’s jump on a phone call.
I’m not interested in nickel-and-diming folks.
Yeah.
I think that if you’re out there doing a lot of hard work, and
a lot of it, it becomes undeniable the value you’re putting out
there, and then people just will want to give you money, right?
And for me, I just feel really bad about taking anybody’s money, and so
even when there’s some kind of benefit—like my courses, I could charge for
(04:45):
access for them, but I always feel I have to give something in terms of
taking somebody’s money, but I would never ask anyone to give me their money.
So, it’s bizarre.
[laugh] so.
I had a whole bunch of people a year or so after I
started asking, like, “I really find your content helpful.
Can I buy you a cup of coffee or something?” And it’s, I don’t know
how to charge people a dollar figure that doesn’t have a comma in
(05:05):
it because it’s easy for me to ask a company for money; that is the
currency of effort, work, et cetera, that companies are accustomed to.
People view money very differently, and if I ask you personally for
money versus your company for money, it’s a very different flow.
So, my solution to it was to build the annual charity t-shirt drive, where it’s,
great, spend 35 bucks or whatever on a snarky t-shirt once a year for ten days
(05:28):
and all proceeds go to benefit a nonprofit that is, sort of, assuaged that.
But one of my business philosophies has always been, “Work
for free before you work for cheap.” And dealing with
individuals and whatnot, I do not charge them for things.
It’s, “Oh, can you—I need some advice in my career.
Can I pay you to give me some advice?” “No, but you can jump
on a Zoom call with me.” Please, the reason I exist at all is
(05:51):
because people who didn’t have any reason to did me favors,
once upon a time, and I feel obligated to pay that forward.
And I appreciate, you know, there are people out
there that you know, do need to charge for their time.
Like—
Oh.
Oh, yes.
—I won’t judge anybody that wants to.
But you know, for me, it’s just I can’t do it because of the way I was raised.
Like, my grandfather was very involved in the community.
Like, he was recognized by the city for all of his volunteer work,
(06:11):
and doing volunteer work was, like, mandatory for me as a kid.
Like, every weekend, and so for me, it’s just like,
I can’t imagine trying to take people’s money.
Which is not a great thing, but it turns out that the community
is very supportive, and they will come beat you down with a stick,
to give you money to make sure you keep doing what you’re doing.
But you know, I could be making lots of money, but it’s
just not my priority, so I’ve avoided any kind of funding so
(06:34):
like, you know, I don’t become a money-driven company, and
I will see how long that lasts, but hopefully, a lot longer.
I wish you well.
And again, you’re right; no shade to anyone who
winds up charging for their time to individuals.
I get it.
I just always had challenges with it, so I decided not to do it.
The only time I find myself begrudging people who do that are
someone who picked something up six months ago and decided, oh,
I’m going to build some video course on how to do this thing.
(06:56):
The end.
And charge a bunch of money for it and
put myself out as an expert in that space.
And you look at what the content they’re putting out is, and
one, it’s inaccurate, which just drives me up a wall, and two,
there’s a lack of awareness that teaching is its own skill.
In some areas, I know how to teach certain things,
and in other areas, I’m a complete disaster at it.
(07:18):
Public speaking is a great example.
A lot of what I do on the public speaking stage
is something that comes to me somewhat naturally.
So, can you teach me to be a good public speaker?
Not really, it’s like, well, you gave that talk and it was bad.
Could you try giving it only make it good?
Like, that is not a helpful coaching statement, so I stay out of that mess.
Yeah, I mean, it’s really challenging to know, if you feel
(07:41):
like you’re authority enough to put something out there.
And there’s been a few courses where I didn’t feel like I was the most
knowledgeable, but I produced those courses, and they had done extremely well.
But as I was going through the course, I was just like, “Yeah, I don’t
know how any this stuff works, but this is my best guess translating
from here.” And so you know, at least for my content, people have
seen me as, like, the lens of AWS on top of other platforms, right?
(08:03):
So, I might not know—I’m not an expert in Azure, but I’ve made a lot
of Azure content, and I just translate that over and I talk about the
frustrations around, like, using scale sets compared to AWS auto-scaling
groups, and that seems to really help people get through the motions of it.
I know if I pass, at least they’ll pass, but
by no means do I ever feel like an expert.
Like, right now I’m doing, like, Kubernetes.
(08:23):
Like, I have no idea how I’m doing it, but
I have, like, help with three other people.
And so I’ll just be honest about it and say, “Hey, yeah,
I’m learning this as well, but at least I know I passed,
so you know, you can pass, too.” Whatever that’s worth.
Oh, yeah.
Back when I was starting out, I felt like a bit of a fraud
because I didn’t know everything about the AWS billing system and
(08:44):
how it worked and all the different things
people can do with it, and things they can ask.
And now, five years later, when the industry basically acknowledges
I’m an expert, I feel like a fraud because I couldn’t possibly
understand everything about the AWS billing system and how it works.
It’s one of those things where the more you learn,
the more you realize that there is yet to learn.
I’m better equipped these days to find the answers to the
(09:05):
things I need to know, but I’m still learning things every day.
If I ever get to a point of complete and total
understanding of a given topic, I’m wrong.
You can always go deeper.
Yeah, I mean, by no means am I even an expert in AWS, though
people seem to think that I am just because I have a lot
of confidence in there and I produce a lot of content.
But that’s a lot different from making a course than implementing stuff.
(09:25):
And I do implement stuff, but you know,
it’s just at the scale that I’m doing that.
So, just food for thought for people there.
Oh, yeah.
Whatever, I implement something.
It’s great.
In my previous engineering life, I would work on large-scale
systems, so I know how a thing that works in your test
environment is going to blow up in a production scale environment.
And I bring those lessons, written on my bones the painful
(09:47):
way, through outages, to the way that I build things now.
But the stuff that I’m building is mostly to keep my head in
the game, as opposed to solving an explicit business need.
Could I theoretically build a podcast transcription system on
top of Transcribe or something like that for these episodes?
Yeah.
But I’ve been paying a person to do this for many years to
do it themselves; they know the terms of art, they know how
(10:10):
this stuff works, and they’re building a glossary as they go,
and understanding the nuances of what I say and how I say it.
And that is the better business outcome; that’s the answer.
And if it’s production facing, I probably shouldn’t be
tinkering with it too much, just based upon where the—I
don’t want to be the bottleneck for the business functioning.
I’ve been spending so much time doing the same thing over and over
(10:32):
again, but for different cloud providers, and the more I do, the less
I want to go deep on these things because I just feel like I’m dumping
all this information I’m going to forget, and that I have those broad
strokes, and when I need to go deep dive, I have that confidence.
So, I’d really prefer people were to build up confidence in saying, “Yes, I
think I can do this.” As opposed to being like, “Oh, I have proof that I know
every single feature in AWS Systems Manager.” Just because, like, our platform,
(10:56):
ExamPro, like, I built it with my co-founder, and it’s a quite a system.
And so I’m going well, that’s all I need to know.
And I talk to other CTOs, and there’s only so much you need to know.
And so I don’t know if there’s, like, a shift between—or difference
between, like, application development where, let’s say you’re doing
React and using Vercel and stuff like that, where you have to have super
deep knowledge for that technical stack, whereas cloud is so broad or
(11:19):
diverse that maybe just having confidence and hypothesizing the work
that you can do and seeing what the outcome is a bit different, right?
Not having to prove one hundred percent that you know
it inside and out on day one, but have the confidence.
And there’s a lot of validity to that and a lot of value to it.
It’s the magic word I always found in interviewing, on both
sides of the interview table, has always been someone who’s
(11:40):
unsure about something start with, “I’m not sure, but if I had
to guess,” and then say whatever it is you were going to say.
Because if you get it right, wow, you’re really good at
figuring this out, and your understanding is pretty decent.
If you’re wrong, well, you’ve shown them how you think
but you’ve also called them out because you’re allowed to
be wrong; you’re not allowed to be authoritatively wrong.
Because once that happens, I can’t trust anything you say.
(12:01):
Yeah.
In terms of, like, how do cloud certifications help you for your career path?
I mean, I find that they’re really well structured,
and they give you a goal to work towards.
So, like, passing that exam is your
motivation to make sure that you complete it.
Do employers care?
It depends.
I would say mostly no.
I mean, for me, like, when I’m hiring, I actually do care
(12:21):
about certifications because we make certification courses but—
In your case, you’re a very specific expression of this that is not typical.
Yeah.
And there are some, like, cases where, like, if you work for a
larger cloud consultancy, you’re expected to have a professional
certification so that customers feel secure in your ability to execute.
But it’s not like they were trying to hire you with that requirement, right?
(12:43):
And so I hope that people realize that and that they look at
showing that practical skills, by building up cloud projects.
And so that’s usually a strong pairing I’ll have, which is like, “Great.
Get the certifications to help you just have a structured journey, and
then do a Cloud project to prove that you can do what you say you can do.”
One area where I’ve seen certifications act as an interesting
(13:04):
proxy for knowledge is when you have a company that has
5000 folks who work in IT in varying ways, and, “All right.
We’re doing a big old cloud migration.” The certification program, in many
respects, seems to act as a bit of a proxy for gauging where people are on
upskilling, how much they have to learn, where they are in that journey.
(13:26):
And at that scale, it begins to make some sense to me.
Where do you stand on that?
Yeah.
I mean, it’s hard because it really depends on how those paths are built.
So, when you look at the AWS certification roadmap, they
have the Certified Cloud Practitioner, they have three
associates, two professionals, and a bunch of specialties.
And I think that you might think, “Well, oh, solutions architect must be very
popular.” But I think that’s because AWS decided to make the most popular, the
(13:51):
most generic one called that, and so you might think that’s what’s most popular.
But what they probably should have done is renamed that Solution Architect
to be a Cloud Engineer because very few people become Solutions Architect.
Like that’s more… if there’s Junior Solutions Architect, I don’t know
where they are, but Solutions Architect is more of, like, a senior role
where you have strong communications, pre-sales, obviously, the role is
(14:11):
going to vary based on what companies decide a Solution Architect is—
Oh, absolutely take a solutions architect, give him a crash
course in finance, and we call them a cloud economist.
Sure.
You just add modifiers there, and they’re something else.
And so I really think that they should have named that one as the
cloud engineer, and they should have extracted it out as its own tier.
So, you’d have the Fundamental, the Certified Cloud Practitioner,
then the Cloud Engineer, and then you could say, “Look, now you could
(14:33):
do developer or the sysops.” And so you’re creating this path where
you have a better trajectory to see where people really want to go.
But the problem is, a lot of people come in and they just do the
solutions architect, and then they don’t even touch the other two
because they say, well, I got an associate, so I’ll move on the next one.
So, I think there’s some structuring there that comes into play.
You look at Azure, they’ve really, really caught up to AWS, and
may I might even say surpass them in terms of the quality and the
(14:56):
way they market them and how they construct their certifications.
There’s things I don’t like about them, but they
have, like, all these fundamental certifications.
Like, you have Azure Fundamentals, Data Fundamentals,
AI Fundamentals, there’s a Security Fundamentals.
And to me, that’s a lot more valuable than going over to an associate.
And so I did all those, and you know, I still think,
(15:17):
like, should I go translate those over for AWS because you
have to wait for a specialty before you pick up security.
And they say, like, it’s intertwined with
all the certifications, but, really isn’t.
Like—and I feel like that would be a lot better for AWS.
But that’s just my personal opinion.
So.
My experience with AWS certifications has been somewhat minimal.
I got the Cloud Practitioner a few years ago, under the working theory
(15:39):
of I wanted to get into the certified lounge at some of the events
because sometimes I needed to charge things and grab a cup of coffee.
I viewed it as a lounge pass with a really strange entrance questionnaire.
And in my case, yeah, I passed it relatively easily; if not, I would
have some questions about how much I actually know about these things.
As I recall, I got one question wrong because I was honest,
instead of going by the book answer for, “How long does
(16:01):
it take to restore an RDS database from a snapshot?”
I’ve had some edge cases there that give the
wrong answer, except that’s what happened.
And then I wound up having that expire and lapse.
And okay, now I’ll do it—it was in beta at the time,
but I got the sysops associate cert to go with it.
And that had a whole bunch of trivia thrown into it, like, “Which
of these is the proper syntax for this thing?” And that’s the kind
(16:24):
of question that’s always bothered me because when I’m trying to
figure things like that out, I have entire internet at my fingertips.
Understanding the exact syntax, or command-line option, or flag that
needs to do a thing is a five-second Google search away in most cases.
But measuring for people’s ability to memorize and retain that
has always struck me as a relatively poor proxy for knowledge.
(16:46):
It’s hard across the board.
Like Azure, AWS, GCP, they all have different approaches—like,
Terraform, all of them, they’re all different.
And you know, when you go to interview process,
you have to kind of extract where the value is.
And I would think that the majority of the industry, you know, don’t have best
practices when hiring, there’s, like, a superficial—AWS is like, “Oh, if you do
well, in STAR program format, you must speak a communicator.” Like, well, I’m
(17:08):
dyslexic, so that stuff is not easy for me, and I will never do well in that.
So like, a lot of companies hinge on those kinds of components.
And I mean, I’m sure it doesn’t matter; if you have
a certain scale, you’re going to have attrition.
There’s no perfect system.
But when you look at these certifications, and you say, “Well,
how much do they match up with the job?” Well, they don’t, right?
It’s just Jeopardy.
But you know, I still think there’s value for
(17:28):
yourself in terms of being able to internalize it.
I still think that does prove that you have done something.
But taking the AWS certification is not
the same as taking Andrew Brown’s course.
So, like, my certified cloud practitioner was built after I did GCP, Oracle
Cloud, Azure Fundamentals, a bunch of other Azure fundamental certifications,
cloud-native stuff, and then I brought it over because was missing, right?
(17:48):
So like, if you went through my course, and that I had a qualifier,
then I could attest to say, like, you are of this skill level, right?
But it really depends on what that testament is and whether somebody
even cares about what my opinion of, like, your skillset is.
But I can’t imagine like, when you have a security
incident, there’s going to be a pop-up that shows you
multiple-choice answer to remediate the security incident.
(18:10):
Now, we might get there at some point, right, with
all the cloud automation, but we’re not there yet.
It’s been sort of thing we’ve been chasing and never quite get there.
I wish.
I hope I live to see it truly I do.
My belief is also that the value of a certification
changes depending upon what career stage someone is at.
Regardless of what level you are at, a hiring manager or a company
(18:31):
is looking for more or less a piece of paper that attests that
they’re to solve the problem that they are hiring to solve.
And entry-level, that is often a degree or a certification or
something like that in the space that shows you have at least
the baseline fundamentals slash know how to learn things.
After a few years, I feel like that starts to shift into okay, you’ve
(18:52):
worked in various places solving similar problems on your resume
that the type that we have—because the most valuable thing you can
hear when you ask someone, “How would we solve this problem?” Is,
“Well, the last time I solved it, here’s what we learned.” Great.
That’s experience.
There’s no compression algorithm for experience?
Yes, there is (19:07):
Hiring people with experience.
Then, at some level, you wind up at the very far side of people
who are late-career in many cases where the piece of paper
that shows that they know what they’re doing is have you tried
googling their name and looking at the Wikipedia article that
spits out, how they built fundamental parts of a system like that.
I think that certifications are one of those
(19:27):
things that bias for early-career folks.
And of course, partners when there are other business reasons to get it.
But as people grow in seniority, I feel
like the need for those begins to fall off.
Do you agree?
Disagree?
You’re much closer to this industry in that aspect of it than I am.
The more senior you are, and if you have big names under your resume
there, no one’s going to care if you have certification, right?
(19:48):
When I was looking to switch careers—I used to have a
consultancy, and I was just tired of building another
failed startup for somebody that was willing to pay me.
And I’m like—I was not very nice about it.
I was like, “Your startup’s not going to work out.
You really shouldn’t be building this.” And they still give me
the money and it would fail, and I’d move on to the next one.
It was very frustrating.
So, closed up shop on that.
And I said, “Okay, I got to reenter the market.” I don’t
(20:10):
have a computer science degree, I don’t have big names
on my resume, and Toronto is a very competitive market.
And so I was feeling friction because people were not valuing my projects.
I had, like, full-stack projects, I would show them.
And they said, “No, no.
Just do these, like, CompSci algorithms and stuff like that.”
And so I went, “Okay, well, I really don’t want to be doing that.
I don’t want to spend all my time learning algorithms just so
(20:33):
I can get a job to prove that I already have the knowledge I
have.” And so I saw a big opportunity in cloud, and I thought
certifications would be the proof to say, “I can do these things.”
And when I actually ended up going for the interviews, I didn’t
even have certifications and I was getting those opportunities
because the certifications helped me prove it, but nobody cared
about the certifications, even then, and that was, like, 2017.
(20:54):
But not to say, like, they didn’t help me, but it wasn’t
the fact that people went, “Oh, you have a certification.
We’ll get you this job.”
Yeah.
When I’m talking to consulting clients, I’ve never once been
asked, “Well, do you have the certifications?” Or, “Are you
an AWS partner?” In my case, no, neither of those things.
The reason that we know what we’re doing is because we’ve done this before.
It’s the expertise approach.
I question whether that would still be true if we were saying, “Oh,
(21:16):
yeah, and we’re going to drop a dozen engineers on who are going to build
things out of your environment.” “Well, are they certified?” is a logical
question to ask when you’re bringing in an external service provider?
Or is this just a bunch of people you found somewhere on Upwork or
whatnot, and you’re throwing them at it with no quality control?
Like, what is the baseline level experience?
That’s a fair question.
People are putting big levels of trust when they bring people in.
(21:37):
I mean, I could see that as a factor of some clients caring, just because
like, when I used to work in startups, I knew customers where it’s
like their second startup, and they’re flush with a lot of money, and
they’re deciding who they want to partner with, and they’re literally
looking at what level of SSL certificate they purchased, right?
Like now, obviously, they’re all free and they’re very easy to
get to get; there was one point where you had different tiers—as
(21:58):
if you would know—and they would look and they would say—
Extended validation certs attend your browser bar green.
Remember those?
Right.
Yeah, yeah, yeah.
It was just like that, and they’re like, “We should partner with them because
they were able to afford that and we know, like…” whatever, whatever, right?
So, you know, there is that kind of thought
process for people at an executive level.
I’m not saying it’s widespread, but I’ve seen it.
When you talk to people that are in cloud consultancy, like solutions
(22:19):
architects, they always tell me they’re driven to go get those
professional certifications [unintelligible] their customers matter.
I don’t know if the customers care or not, but they seem to think so.
So, I don’t know if it’s just more driven by those people because it’s
an expectation because everyone else has it, or it’s like a package of
things, like, you know, like the green bar in the certifications, SOC
2 compliance, things like that, that kind of wrap it up and say, “Okay,
(22:40):
as a package, this looks really good.” So, more of an expectation,
but not necessarily matters, it’s just superficial; I’m not sure.
Here at the Duckbill Group, one of the things we do with,
you know, my day job, is we help negotiate AWS contracts.
We just recently crossed five billion dollars of contract value negotiated.
It solves for fun problems such as how do you know that your
(23:03):
contract that you have with AWS is the best deal you can get?
How do you know you're not leaving money on the table?
How do you know that you're not doing what I do on this podcast
and on Twitter constantly and sticking your foot in your mouth?
To learn more, come chat at duckbillgroup.com.
Optionally, I will also do podcast voice when we talk about it.
(23:26):
Again, that's duckbillgroup.com.
You’ve been building out certifications for multiple cloud providers, so I’m
curious to get your take on something that Forrest Brazeal, who’s now head of
content over at Google Cloud, has been talking about lately, the idea that as
an engineer is advised to learn more than one cloud provider; even if you have
one as a primary, learning how another one works makes you a better engineer.
(23:49):
Now, setting aside entirely the idea that well, yeah, if I
worked at Google, I probably be saying something fairly similar.
Yeah.
Do you think there’s validity to the idea that most
people should be broad across multiple providers, or
do you think specialization on one is the right path?
Sure.
Just to contextualize for our listeners, Google Cloud is highly,
(24:10):
highly promoting multi-cloud workloads, and one of their flagship
products is—well, they say it’s a flagship product—is Anthos.
And they put a lot of money—I don’t know that was subsidized, but they put
a lot of money in it because they really want to push multi-cloud, right?
And so when we say Forrest works in Google Cloud, it should be no
surprise that he’s promoting it.
But I don’t work for Google, and I can tell you, like, learning
(24:32):
multi-cloud is, like, way more valuable than just staying in one vertical.
It just
opened my eyes.
When I went from AWS to Azure, it was just like, “Oh, I’m missing out on so much
in the industry.” And it really just made me such a more well-rounded person.
And I went over to Google Cloud, and it was just like… because
you’re learning the same thing in different variations, and then
you’re also poly-filling for things that you will never touch.
(24:53):
Or like, I shouldn’t say you never touch, but you would never
touch if you just stayed in that vertical when you’re learning.
So, in the industry, Azure Active Directory is, like,
widespread, but if you just stayed in your little AWS box,
you’re not going to notice it on that learning path, right?
And so a lot of times, I tell people, “Go get your CLF-C01 and then go get
your AZ-900 or AZ-104.” Again, I don’t care if people go and sit the exams.
(25:15):
I want them to go learn the content because it is a large eye-opener.
A lot of people are against multi-cloud from a learning perspective
because say, it’s too much to learn all at the same time.
But a lot of people I don’t think have actually gone across the cloud, right?
So, they’re sitting from their chair, only staying in one vertical
saying, “Well, you can’t learn them all at the same time.” And
I’m going, “I see a way that you could teach them all at the
same time.” And I might be the first person that will do it.
(25:37):
And the principles do convey as well.
It’s, “Oh, well I know how SNS works on AWS, so I would never
be able to understand how Google Pub/Sub works.” Those are
functionally identical; I don’t know that is actually true.
It’s just different to interface points and different guarantees, but fine.
You at least understand the part that it plays.
I’ve built things out on Google Cloud somewhat recently,
(25:58):
and for me, every time I do, it’s a refreshing eye-opener to
oh, this is what developer experience in the cloud could be.
And for a lot of customers, it is.
But staying too far within the bounds of one ecosystem does lend itself to a
loss of perspective, if you’re not careful.
I agree with that.
Yeah.
Well, I mean, just the paint more of a picture of differences,
like, Google Cloud has a lot about digital transformation.
(26:19):
They just updated their—I’m not happy that they changed it, but I’m fine that
they did that, but they updated their Google Digital Cloud Leader Exam Guide
this month, and it like is one hundred percent all about digital transformation.
So, they love talking about digital
transformation, and those kind of concepts there.
They are really good at defining migration strategies, like, at a high level.
Over to Azure, they have their own cloud adoption framework, and
it’s so detailed, in terms of, like, execution, where you go over
(26:44):
to AWS and they have, like, the worst cloud adoption framework.
It’s just the laziest thing I’ve ever seen produced in my
life compared to out of all the providers in that space.
I didn’t know about zero-trust model until I start using Azure because Azure
has Active Directory, and you can do risk-based policy procedures over there.
So, you know, like, if you don’t go over to these places,
you’re not going to get covered other places, so you’re just
going to be missing information till you get the job and, you
(27:06):
know, that job has that information requiring you to know it.
I would say that for someone early career—and I don’t know where this
falls on the list of career advice ranging from, “That is genius,”
to, “Okay, Boomer,” but I would argue that figuring out what companies
in your geographic area, or the companies that you have connections
with what they’re using for a cloud provider, I would bias for
(27:29):
learning one enough to get hired there and from there, letting what
you learn next be dictated by the environment you find yourself in.
Because especially larger companies, there’s always
something that lives in a different provider.
My default worst practice is multi-cloud.
And I don’t say that because multi-cloud doesn’t exist, and I’m not
saying it because it’s a bad idea, but this idea of one workload—to
(27:50):
me—that runs across multiple providers is generally a challenge.
What I see a lot more, done intelligently, is, “Okay, we’re going to use
this provider for some things, this other provider for other things, and
this third provider for yet more things.” And every company does that.
If not, there’s something very strange going on.
Even Amazon uses—if not Office 365, at least exchange to
(28:12):
run their email systems instead of Amazon WorkMail because—
Yeah.
Let’s be serious.
That tells me a lot.
But I don’t generally find myself in a scenario where I want to build
this application that is anything more than Hello World, where I want it
to run seamlessly and flawlessly across two different cloud providers.
That’s an awful lot of work that I struggle to
(28:33):
identify significant value for most workloads.
I don’t want to think about securing, like, multiple workloads,
and that’s I think a lot of friction for a lot of companies
are ingress-egress costs, which I’m sure you might have some
knowledge on there about the ingress-egress costs across providers.
Oh, a little bit, yeah.
A little bit, probably.
Oh, throwing data between clouds is always expensive.
Sure.
So, I mean, like, I call multi-cloud using
multiple providers, but not in tandem.
Cross-cloud is when you want to use something like Anthos or Azure
(28:57):
Arc or something like that where you extend your data plane or control
pla—whatever the plane is, whatever plane across all the providers.
But you know, in practice, I don’t think many people are doing
cross-cloud; they’re doing multi-cloud, like, “I use AWS to run my
primary workloads, and then I use Microsoft Office Suite, and so we
happen to use Azure Active Directory, or, you know, run particular VM
machines, like Windows machines for our accounting.” You know?
(29:19):
So, it’s a mixed bag, but I do think that using more
than one thing is becoming more popular just because you
want to use the best in breed no matter where you are.
So like, I love BigQuery.
BigQuery is amazing.
So, like, I ingest a lot of our data from, you
know, third-party services right into that.
I could be doing that in Redshift, which is expensive; I
could be doing that in Azure Synapse, which is also expensive.
(29:41):
I mean, there’s a serverless thing.
I don’t really get serverless.
So, I think that, you know, people are doing multi-cloud.
Yeah.
I would agree.
I tend to do things like that myself, and
whenever I see it generally makes sense.
This is my general guidance.
When I talk to individuals who say, “Well, we’re running
multi-cloud like this.” And my response is, “Great.
You’re probably right.”
Because I’m talking in the general sense, someone building something out
(30:02):
on day one where they don’t know, like, “Everyone’s saying multi-cloud.
Should I do that?” No, I don’t believe you should.
Now, if your company has done that intentionally, rather than by accident,
there’s almost certainly a reason and context that I do not have.
“Well, we have to run our SaaS application in multiple cloud providers
because that’s where our customers are.” “Yeah, you should probably
(30:23):
do that.” But your marketing, your billing systems, your back-end
reconciliation stuff generally does not live across all of those providers.
It lives in one.
That’s the sort of thing I’m talking about.
I think we’re in violent agreement here.
Oh, sure, yeah.
I mean, Kubernetes obviously is becoming very popular because people believe
that they’ll have a lot more mobility, Whereas when you use all the different
managed—and I’m still learning Kubernetes myself from the next certification
(30:46):
I have coming out, like, study course—but, you know, like, those managed
services have all different kind of kinks that are completely different.
And so, you know, it’s not going to be a smooth process.
And you’re still leveraging, like, for key things like your
database, you’re not going to be running that in Kubernetes Cluster.
You’re going to be using a managed service.
And so, those have their own kind of expectations in terms of configuration.
So, I don’t know, it’s tricky to say what to do, but I think that,
(31:08):
you know, if you have a need for it, and you don’t have a security
concern—like, usually it’s security or cost, right, for multi-cloud.
For me, at least, the lock-in has always
been twofold that people don’t talk about.
More—less lock-in than buy-in.
One is the security model where IAM is super fraught and challenging and
tricky, and trying to map a security model to multiple providers is super hard.
(31:29):
Then on top of that, you also have the buy-in story of a bunch
of engineers who are very good at one cloud provider, and that
skill set is not in less demand now than it was a year ago.
So okay, you’re going to start over and learn a new cloud provider
is often something that a lot of engineers won’t want to countenance.
If your team is dead set against it, there’s going to be
some friction there and there’s going to be a challenge.
(31:49):
I mean, for me at least, to say that someone knows a cloud
provider is not the naive approach of, “Oh yeah, they know
how it works across the board.” They know how it breaks.
For me, one of the most valuable reasons to run something on AWS
is I know what a failure mode looks like, I know how it degrades,
I know how to find out what’s going on when I see that degradation.
That to me is a very hard barrier to overcome.
(32:11):
Alternately, it’s entirely possible that I’m just old.
Oh, I think we’re starting to see some wins all over the place in
terms of being able to learn one thing and bring it other places, like
OpenTelemetry, which I believe is a cloud-native Kubernetes… CNCF.
I can’t remember what it stands for.
It’s like Linux Foundation, but for cloud-native.
And so OpenTelemetry is just a standardized way
of handling your logs, metrics, and traces, right?
(32:33):
And so maybe CloudWatch will be the 1.0 of observability in AWS, and
then maybe OpenTelemetry will become more of the standard, right, and so
maybe we might see more managed services like Prometheus and Grafa—well,
obviously, AWS has a managed Prometheus, but other things like that.
So, maybe some of those things will melt away.
But yeah, it’s hard to say what approach to take.
(32:53):
Yeah, I’m wondering, on some level, whether what the things
we’re talking about today, how well that’s going to map forward.
Because the industry is constantly changing.
The guidance I would give about should you be in cloud
five years ago would have been a nuanced, “Mmm, depends.
Maybe for yes, maybe for no.
Here’s the story.” It’s a lot less hedge-y and a lot
less edge case-y these days when I answer that question.
So, I wonder in five years from now when we look back at this podcast
(33:16):
episode, how well this discussion about what the future looks like,
and certifications, and multi-cloud, how well that’s going to reflect?
Well, when we look at, like, Kubernetes or Web3, we’re
just seeing kind of like the standardized boilerplate way
of doing a bunch of things, right, all over the place.
This distributed way of, like, having this generic API across the board.
And how well that will take, I have no idea, but we do see
(33:39):
a large split between, like, serverless and cloud-natives.
So, it’s like, what direction?
Or we’ll just have both?
Probably just have both, right?
[Like that] . I hope so.
It’s been a wild industry ride, and I’m really curious
to see what changes as we wind up continuing to grow.
But we’ll see.
That’s the nice thing about this is, worst case, if oh,
turns out that we were wrong on this whole cloud thing, and
(33:59):
everyone starts exodusing back to data centers, well, okay.
That’s the nice thing about being a small company.
It doesn’t take either of us that long to
address the reality we see in the industry.
Well, that or these cloud service providers are just going to
get better at offering those services within carrier hotels,
or data centers, or on your on-premise under your desk, right?
So… I don’t know, we’ll see.
It’s hard to say what the future will be, but I do believe
(34:20):
that cloud is sticking around in one form or another.
And it basically is, like, an essential skill or
table stakes for anybody that’s in the industry.
I mean, of course, not everywhere, but like, mostly, I would say.
So.
Andrew, I want to thank you for taking the time to speak with me today.
If people want to learn more about your
opinions, how you view these things, et cetera.
Where can they find you?
You know, I think the best place to find me right now is Twitter.
(34:42):
So, if you go to twitter.com/andrewbrown—all lowercase, no
spaces, no underscores, no hyphens—you’ll find me there.
I’m so surprised I was able to get that handle.
It’s like the only place where I have my
handle.
And we will of course put links to that in the [show notes]
. Thanks so much for taking the time to speak with me today.
I really
appreciate it.
Well, thanks for having me on the show.
(35:04):
Andrew Brown, co-founder and cloud instructor
at ExamPro Training and so much more.
I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
If you’ve enjoyed this podcast, please leave a five-star review on your
podcast platform of choice, whereas if you’ve hated this podcast, please
leave a five-star review on your podcast platform of choice, along with
an angry comment telling me that I do not understand certifications at all
(35:27):
because you’re an accountant, and certifications matter more in that industry.
A lot of people I don’t think have actually gone across the cloud, right?
(00:02):
So, they’re sitting from their chair, only staying in one vertical
saying, “Well, you can’t learn them all at the same time.” And
I’m going, “I see a way that you could teach them all at the
same time.” And I might be the first person that will do it.
Welcome to Screaming in the Cloud.
I’m Corey Quinn.
My guest today is… well, he’s challenging to describe.
(00:24):
He’s the co-founder and cloud instructor at ExamPro Training, Inc.
but everyone knows him better as Andrew Brown because he does so
many different things in the AWS ecosystem that it’s sometimes
challenging—at least for me—to wind up keeping track of them all.
Andrew, thanks for joining.
Hey, thanks for having me on the show, Corey.
This episode is sponsored in part by my day job, the Duckbill Group.
(00:46):
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
Negotiating your next long term contract with AWS.
Or just figuring out why it increasingly resembles a
phone number, but nobody seems to quite know why that is.
To learn more, visit duckbillgroup.com.
(01:07):
Remember, you can't duck the duck bill, Bill.
And my CEO informs me that is absolutely not our slogan.
How do I even begin describing you?
You’re an AWS Community Hero and have been for almost two years, I believe;
you’ve done a whole bunch of work as far as training videos; you’re, I
think, responsible for #100daysofcloud; you recently started showing up
(01:30):
on my TikTok feed because I’m pretending that I am 20 years younger than I
am and hanging out on TikTok with the kids, and now I feel extremely old.
And obviously, you’re popping up an awful lot of places.
Oh, yeah.
A few other places like PolyWork, which is an alternative to LinkedIn,
so that’s a space that I’m starting to build up on there as well.
Active in Discord, Slack channels.
I’m just kind of everywhere.
(01:51):
There’s some kind of internet obsession here.
My wife gets really mad and says, “Hey, maybe tone
down the social media.” But I really enjoy it.
So.
You’re one of those folks where I have this challenge of I wind up
having a bunch of different AWS community Slacks and cloud community,
Slacks and Discords and the past, and we DM on Twitter sometimes.
And I’m constantly trying to figure out where was
that conversational thread that I had with you?
(02:14):
And tracking it down is an increasingly large search problem.
I really wish that—forget the unified messaging platform.
I want a unified search platform for all the different
messaging channels that I’m using to talk to people.
Yeah, it’s very hard to keep up with all the channels for myself there.
But somehow I do seem to manage it, but
just with a bit less sleep than most others.
Oh, yeah.
It’s like trying to figure out, like, “All
(02:35):
right, he said something really useful.
What was that?
Was that a Twitter DM?
Was it on that Slack channel?
Was it that Discord?
No, it was on that brick that he threw through my window with a note tied to it.
There we go.”
That’s always the baseline stuff of figuring out where things are.
So, as I mentioned in the beginning, you are the co-founder and cloud instructor
at ExamPro, which is interesting because unlike most of the community stuff
(02:56):
that you do and are known for, you don’t generally talk about that an awful lot.
What’s the deal there?
Yeah, I think a lot of people give me a hard time because they say,
Andrew, you should really be promoting yourself more and trying to
make more sales, but that’s not why I’m out here doing what I’m doing.
Of course, I do have a for-profit business called ExamPro, where we create
cloud certification study courses for things like AWS, Azure, GCP, Terraform,
(03:20):
Kubernetes, but you know, that money just goes to fuel what I really want
to do, is just to do community activities to help people change their lives.
And I just decided to do that via cloud because that’s my domain expertise.
At least that’s what I say because I’ve
learned up on in the last four or five years.
I’m hoping that there’s some kind of impact I can make doing that.
I take a somewhat similar approach.
(03:40):
I mean, at The Duckbill Group, we fixed the horrifying AWS bill, but I’ve always
found that’s not generally a problem that people tend to advertise having.
On Twitter, like, “Oh, man, my AWS bill is killing me this month.
I’ve got to do something about it,” and you check
where they work, and it’s like a Fortune 50.
It’s, yeah, that moves markets and no one talks about that.
So, my approach was always, be out there, be present in the
(04:01):
community, talk about this stuff, and the people who genuinely
have billing problems will eventually find their way to me.
That was always my approach because turning
everything I do into a sales pitch doesn’t work.
It just erodes confidence, it reminds people of the used mattress
salesman, and I just don’t want to be that person in that community.
My approach has always been if I can help someone with a
(04:22):
15-minute call or whatnot, yeah, let’s jump on a phone call.
I’m not interested in nickel-and-diming folks.
Yeah.
I think that if you’re out there doing a lot of hard work, and
a lot of it, it becomes undeniable the value you’re putting out
there, and then people just will want to give you money, right?
And for me, I just feel really bad about taking anybody’s money, and so
even when there’s some kind of benefit—like my courses, I could charge for
(04:45):
access for them, but I always feel I have to give something in terms of
taking somebody’s money, but I would never ask anyone to give me their money.
So, it’s bizarre.
[laugh] so.
I had a whole bunch of people a year or so after I
started asking, like, “I really find your content helpful.
Can I buy you a cup of coffee or something?” And it’s, I don’t know
how to charge people a dollar figure that doesn’t have a comma in
(05:05):
it because it’s easy for me to ask a company for money; that is the
currency of effort, work, et cetera, that companies are accustomed to.
People view money very differently, and if I ask you personally for
money versus your company for money, it’s a very different flow.
So, my solution to it was to build the annual charity t-shirt drive, where it’s,
great, spend 35 bucks or whatever on a snarky t-shirt once a year for ten days
(05:28):
and all proceeds go to benefit a nonprofit that is, sort of, assuaged that.
But one of my business philosophies has always been, “Work
for free before you work for cheap.” And dealing with
individuals and whatnot, I do not charge them for things.
It’s, “Oh, can you—I need some advice in my career.
Can I pay you to give me some advice?” “No, but you can jump
on a Zoom call with me.” Please, the reason I exist at all is
(05:51):
because people who didn’t have any reason to did me favors,
once upon a time, and I feel obligated to pay that forward.
And I appreciate, you know, there are people out
there that you know, do need to charge for their time.
Like—
Oh.
Oh, yes.
—I won’t judge anybody that wants to.
But you know, for me, it’s just I can’t do it because of the way I was raised.
Like, my grandfather was very involved in the community.
Like, he was recognized by the city for all of his volunteer work,
(06:11):
and doing volunteer work was, like, mandatory for me as a kid.
Like, every weekend, and so for me, it’s just like,
I can’t imagine trying to take people’s money.
Which is not a great thing, but it turns out that the community
is very supportive, and they will come beat you down with a stick,
to give you money to make sure you keep doing what you’re doing.
But you know, I could be making lots of money, but it’s
just not my priority, so I’ve avoided any kind of funding so
(06:34):
like, you know, I don’t become a money-driven company, and
I will see how long that lasts, but hopefully, a lot longer.
I wish you well.
And again, you’re right; no shade to anyone who
winds up charging for their time to individuals.
I get it.
I just always had challenges with it, so I decided not to do it.
The only time I find myself begrudging people who do that are
someone who picked something up six months ago and decided, oh,
I’m going to build some video course on how to do this thing.
(06:56):
The end.
And charge a bunch of money for it and
put myself out as an expert in that space.
And you look at what the content they’re putting out is, and
one, it’s inaccurate, which just drives me up a wall, and two,
there’s a lack of awareness that teaching is its own skill.
In some areas, I know how to teach certain things,
and in other areas, I’m a complete disaster at it.
(07:18):
Public speaking is a great example.
A lot of what I do on the public speaking stage
is something that comes to me somewhat naturally.
So, can you teach me to be a good public speaker?
Not really, it’s like, well, you gave that talk and it was bad.
Could you try giving it only make it good?
Like, that is not a helpful coaching statement, so I stay out of that mess.
Yeah, I mean, it’s really challenging to know, if you feel
(07:41):
like you’re authority enough to put something out there.
And there’s been a few courses where I didn’t feel like I was the most
knowledgeable, but I produced those courses, and they had done extremely well.
But as I was going through the course, I was just like, “Yeah, I don’t
know how any this stuff works, but this is my best guess translating
from here.” And so you know, at least for my content, people have
seen me as, like, the lens of AWS on top of other platforms, right?
(08:03):
So, I might not know—I’m not an expert in Azure, but I’ve made a lot
of Azure content, and I just translate that over and I talk about the
frustrations around, like, using scale sets compared to AWS auto-scaling
groups, and that seems to really help people get through the motions of it.
I know if I pass, at least they’ll pass, but
by no means do I ever feel like an expert.
Like, right now I’m doing, like, Kubernetes.
(08:23):
Like, I have no idea how I’m doing it, but
I have, like, help with three other people.
And so I’ll just be honest about it and say, “Hey, yeah,
I’m learning this as well, but at least I know I passed,
so you know, you can pass, too.” Whatever that’s worth.
Oh, yeah.
Back when I was starting out, I felt like a bit of a fraud
because I didn’t know everything about the AWS billing system and
(08:44):
how it worked and all the different things
people can do with it, and things they can ask.
And now, five years later, when the industry basically acknowledges
I’m an expert, I feel like a fraud because I couldn’t possibly
understand everything about the AWS billing system and how it works.
It’s one of those things where the more you learn,
the more you realize that there is yet to learn.
I’m better equipped these days to find the answers to the
(09:05):
things I need to know, but I’m still learning things every day.
If I ever get to a point of complete and total
understanding of a given topic, I’m wrong.
You can always go deeper.
Yeah, I mean, by no means am I even an expert in AWS, though
people seem to think that I am just because I have a lot
of confidence in there and I produce a lot of content.
But that’s a lot different from making a course than implementing stuff.
(09:25):
And I do implement stuff, but you know,
it’s just at the scale that I’m doing that.
So, just food for thought for people there.
Oh, yeah.
Whatever, I implement something.
It’s great.
In my previous engineering life, I would work on large-scale
systems, so I know how a thing that works in your test
environment is going to blow up in a production scale environment.
And I bring those lessons, written on my bones the painful
(09:47):
way, through outages, to the way that I build things now.
But the stuff that I’m building is mostly to keep my head in
the game, as opposed to solving an explicit business need.
Could I theoretically build a podcast transcription system on
top of Transcribe or something like that for these episodes?
Yeah.
But I’ve been paying a person to do this for many years to
do it themselves; they know the terms of art, they know how
(10:10):
this stuff works, and they’re building a glossary as they go,
and understanding the nuances of what I say and how I say it.
And that is the better business outcome; that’s the answer.
And if it’s production facing, I probably shouldn’t be
tinkering with it too much, just based upon where the—I
don’t want to be the bottleneck for the business functioning.
I’ve been spending so much time doing the same thing over and over
(10:32):
again, but for different cloud providers, and the more I do, the less
I want to go deep on these things because I just feel like I’m dumping
all this information I’m going to forget, and that I have those broad
strokes, and when I need to go deep dive, I have that confidence.
So, I’d really prefer people were to build up confidence in saying, “Yes, I
think I can do this.” As opposed to being like, “Oh, I have proof that I know
every single feature in AWS Systems Manager.” Just because, like, our platform,
(10:56):
ExamPro, like, I built it with my co-founder, and it’s a quite a system.
And so I’m going well, that’s all I need to know.
And I talk to other CTOs, and there’s only so much you need to know.
And so I don’t know if there’s, like, a shift between—or difference
between, like, application development where, let’s say you’re doing
React and using Vercel and stuff like that, where you have to have super
deep knowledge for that technical stack, whereas cloud is so broad or
(11:19):
diverse that maybe just having confidence and hypothesizing the work
that you can do and seeing what the outcome is a bit different, right?
Not having to prove one hundred percent that you know
it inside and out on day one, but have the confidence.
And there’s a lot of validity to that and a lot of value to it.
It’s the magic word I always found in interviewing, on both
sides of the interview table, has always been someone who’s
(11:40):
unsure about something start with, “I’m not sure, but if I had
to guess,” and then say whatever it is you were going to say.
Because if you get it right, wow, you’re really good at
figuring this out, and your understanding is pretty decent.
If you’re wrong, well, you’ve shown them how you think
but you’ve also called them out because you’re allowed to
be wrong; you’re not allowed to be authoritatively wrong.
Because once that happens, I can’t trust anything you say.
(12:01):
Yeah.
In terms of, like, how do cloud certifications help you for your career path?
I mean, I find that they’re really well structured,
and they give you a goal to work towards.
So, like, passing that exam is your
motivation to make sure that you complete it.
Do employers care?
It depends.
I would say mostly no.
I mean, for me, like, when I’m hiring, I actually do care
(12:21):
about certifications because we make certification courses but—
In your case, you’re a very specific expression of this that is not typical.
Yeah.
And there are some, like, cases where, like, if you work for a
larger cloud consultancy, you’re expected to have a professional
certification so that customers feel secure in your ability to execute.
But it’s not like they were trying to hire you with that requirement, right?
(12:43):
And so I hope that people realize that and that they look at
showing that practical skills, by building up cloud projects.
And so that’s usually a strong pairing I’ll have, which is like, “Great.
Get the certifications to help you just have a structured journey, and
then do a Cloud project to prove that you can do what you say you can do.”
One area where I’ve seen certifications act as an interesting
(13:04):
proxy for knowledge is when you have a company that has
5000 folks who work in IT in varying ways, and, “All right.
We’re doing a big old cloud migration.” The certification program, in many
respects, seems to act as a bit of a proxy for gauging where people are on
upskilling, how much they have to learn, where they are in that journey.
(13:26):
And at that scale, it begins to make some sense to me.
Where do you stand on that?
Yeah.
I mean, it’s hard because it really depends on how those paths are built.
So, when you look at the AWS certification roadmap, they
have the Certified Cloud Practitioner, they have three
associates, two professionals, and a bunch of specialties.
And I think that you might think, “Well, oh, solutions architect must be very
popular.” But I think that’s because AWS decided to make the most popular, the
(13:51):
most generic one called that, and so you might think that’s what’s most popular.
But what they probably should have done is renamed that Solution Architect
to be a Cloud Engineer because very few people become Solutions Architect.
Like that’s more… if there’s Junior Solutions Architect, I don’t know
where they are, but Solutions Architect is more of, like, a senior role
where you have strong communications, pre-sales, obviously, the role is
(14:11):
going to vary based on what companies decide a Solution Architect is—
Oh, absolutely take a solutions architect, give him a crash
course in finance, and we call them a cloud economist.
Sure.
You just add modifiers there, and they’re something else.
And so I really think that they should have named that one as the
cloud engineer, and they should have extracted it out as its own tier.
So, you’d have the Fundamental, the Certified Cloud Practitioner,
then the Cloud Engineer, and then you could say, “Look, now you could
(14:33):
do developer or the sysops.” And so you’re creating this path where
you have a better trajectory to see where people really want to go.
But the problem is, a lot of people come in and they just do the
solutions architect, and then they don’t even touch the other two
because they say, well, I got an associate, so I’ll move on the next one.
So, I think there’s some structuring there that comes into play.
You look at Azure, they’ve really, really caught up to AWS, and
may I might even say surpass them in terms of the quality and the
(14:56):
way they market them and how they construct their certifications.
There’s things I don’t like about them, but they
have, like, all these fundamental certifications.
Like, you have Azure Fundamentals, Data Fundamentals,
AI Fundamentals, there’s a Security Fundamentals.
And to me, that’s a lot more valuable than going over to an associate.
And so I did all those, and you know, I still think,
(15:17):
like, should I go translate those over for AWS because you
have to wait for a specialty before you pick up security.
And they say, like, it’s intertwined with
all the certifications, but, really isn’t.
Like—and I feel like that would be a lot better for AWS.
But that’s just my personal opinion.
So.
My experience with AWS certifications has been somewhat minimal.
I got the Cloud Practitioner a few years ago, under the working theory
(15:39):
of I wanted to get into the certified lounge at some of the events
because sometimes I needed to charge things and grab a cup of coffee.
I viewed it as a lounge pass with a really strange entrance questionnaire.
And in my case, yeah, I passed it relatively easily; if not, I would
have some questions about how much I actually know about these things.
As I recall, I got one question wrong because I was honest,
instead of going by the book answer for, “How long does
(16:01):
it take to restore an RDS database from a snapshot?”
I’ve had some edge cases there that give the
wrong answer, except that’s what happened.
And then I wound up having that expire and lapse.
And okay, now I’ll do it—it was in beta at the time,
but I got the sysops associate cert to go with it.
And that had a whole bunch of trivia thrown into it, like, “Which
of these is the proper syntax for this thing?” And that’s the kind
(16:24):
of question that’s always bothered me because when I’m trying to
figure things like that out, I have entire internet at my fingertips.
Understanding the exact syntax, or command-line option, or flag that
needs to do a thing is a five-second Google search away in most cases.
But measuring for people’s ability to memorize and retain that
has always struck me as a relatively poor proxy for knowledge.
(16:46):
It’s hard across the board.
Like Azure, AWS, GCP, they all have different approaches—like,
Terraform, all of them, they’re all different.
And you know, when you go to interview process,
you have to kind of extract where the value is.
And I would think that the majority of the industry, you know, don’t have best
practices when hiring, there’s, like, a superficial—AWS is like, “Oh, if you do
well, in STAR program format, you must speak a communicator.” Like, well, I’m
(17:08):
dyslexic, so that stuff is not easy for me, and I will never do well in that.
So like, a lot of companies hinge on those kinds of components.
And I mean, I’m sure it doesn’t matter; if you have
a certain scale, you’re going to have attrition.
There’s no perfect system.
But when you look at these certifications, and you say, “Well,
how much do they match up with the job?” Well, they don’t, right?
It’s just Jeopardy.
But you know, I still think there’s value for
(17:28):
yourself in terms of being able to internalize it.
I still think that does prove that you have done something.
But taking the AWS certification is not
the same as taking Andrew Brown’s course.
So, like, my certified cloud practitioner was built after I did GCP, Oracle
Cloud, Azure Fundamentals, a bunch of other Azure fundamental certifications,
cloud-native stuff, and then I brought it over because was missing, right?
(17:48):
So like, if you went through my course, and that I had a qualifier,
then I could attest to say, like, you are of this skill level, right?
But it really depends on what that testament is and whether somebody
even cares about what my opinion of, like, your skillset is.
But I can’t imagine like, when you have a security
incident, there’s going to be a pop-up that shows you
multiple-choice answer to remediate the security incident.
(18:10):
Now, we might get there at some point, right, with
all the cloud automation, but we’re not there yet.
It’s been sort of thing we’ve been chasing and never quite get there.
I wish.
I hope I live to see it truly I do.
My belief is also that the value of a certification
changes depending upon what career stage someone is at.
Regardless of what level you are at, a hiring manager or a company
(18:31):
is looking for more or less a piece of paper that attests that
they’re to solve the problem that they are hiring to solve.
And entry-level, that is often a degree or a certification or
something like that in the space that shows you have at least
the baseline fundamentals slash know how to learn things.
After a few years, I feel like that starts to shift into okay, you’ve
(18:52):
worked in various places solving similar problems on your resume
that the type that we have—because the most valuable thing you can
hear when you ask someone, “How would we solve this problem?” Is,
“Well, the last time I solved it, here’s what we learned.” Great.
That’s experience.
There’s no compression algorithm for experience?
Yes, there is (19:07):
Hiring people with experience.
Then, at some level, you wind up at the very far side of people
who are late-career in many cases where the piece of paper
that shows that they know what they’re doing is have you tried
googling their name and looking at the Wikipedia article that
spits out, how they built fundamental parts of a system like that.
I think that certifications are one of those
(19:27):
things that bias for early-career folks.
And of course, partners when there are other business reasons to get it.
But as people grow in seniority, I feel
like the need for those begins to fall off.
Do you agree?
Disagree?
You’re much closer to this industry in that aspect of it than I am.
The more senior you are, and if you have big names under your resume
there, no one’s going to care if you have certification, right?
(19:48):
When I was looking to switch careers—I used to have a
consultancy, and I was just tired of building another
failed startup for somebody that was willing to pay me.
And I’m like—I was not very nice about it.
I was like, “Your startup’s not going to work out.
You really shouldn’t be building this.” And they still give me
the money and it would fail, and I’d move on to the next one.
It was very frustrating.
So, closed up shop on that.
And I said, “Okay, I got to reenter the market.” I don’t
(20:10):
have a computer science degree, I don’t have big names
on my resume, and Toronto is a very competitive market.
And so I was feeling friction because people were not valuing my projects.
I had, like, full-stack projects, I would show them.
And they said, “No, no.
Just do these, like, CompSci algorithms and stuff like that.”
And so I went, “Okay, well, I really don’t want to be doing that.
I don’t want to spend all my time learning algorithms just so
(20:33):
I can get a job to prove that I already have the knowledge I
have.” And so I saw a big opportunity in cloud, and I thought
certifications would be the proof to say, “I can do these things.”
And when I actually ended up going for the interviews, I didn’t
even have certifications and I was getting those opportunities
because the certifications helped me prove it, but nobody cared
about the certifications, even then, and that was, like, 2017.
(20:54):
But not to say, like, they didn’t help me, but it wasn’t
the fact that people went, “Oh, you have a certification.
We’ll get you this job.”
Yeah.
When I’m talking to consulting clients, I’ve never once been
asked, “Well, do you have the certifications?” Or, “Are you
an AWS partner?” In my case, no, neither of those things.
The reason that we know what we’re doing is because we’ve done this before.
It’s the expertise approach.
I question whether that would still be true if we were saying, “Oh,
(21:16):
yeah, and we’re going to drop a dozen engineers on who are going to build
things out of your environment.” “Well, are they certified?” is a logical
question to ask when you’re bringing in an external service provider?
Or is this just a bunch of people you found somewhere on Upwork or
whatnot, and you’re throwing them at it with no quality control?
Like, what is the baseline level experience?
That’s a fair question.
People are putting big levels of trust when they bring people in.
(21:37):
I mean, I could see that as a factor of some clients caring, just because
like, when I used to work in startups, I knew customers where it’s
like their second startup, and they’re flush with a lot of money, and
they’re deciding who they want to partner with, and they’re literally
looking at what level of SSL certificate they purchased, right?
Like now, obviously, they’re all free and they’re very easy to
get to get; there was one point where you had different tiers—as
(21:58):
if you would know—and they would look and they would say—
Extended validation certs attend your browser bar green.
Remember those?
Right.
Yeah, yeah, yeah.
It was just like that, and they’re like, “We should partner with them because
they were able to afford that and we know, like…” whatever, whatever, right?
So, you know, there is that kind of thought
process for people at an executive level.
I’m not saying it’s widespread, but I’ve seen it.
When you talk to people that are in cloud consultancy, like solutions
(22:19):
architects, they always tell me they’re driven to go get those
professional certifications [unintelligible] their customers matter.
I don’t know if the customers care or not, but they seem to think so.
So, I don’t know if it’s just more driven by those people because it’s
an expectation because everyone else has it, or it’s like a package of
things, like, you know, like the green bar in the certifications, SOC
2 compliance, things like that, that kind of wrap it up and say, “Okay,
(22:40):
as a package, this looks really good.” So, more of an expectation,
but not necessarily matters, it’s just superficial; I’m not sure.
Here at the Duckbill Group, one of the things we do with,
you know, my day job, is we help negotiate AWS contracts.
We just recently crossed five billion dollars of contract value negotiated.
It solves for fun problems such as how do you know that your
(23:03):
contract that you have with AWS is the best deal you can get?
How do you know you're not leaving money on the table?
How do you know that you're not doing what I do on this podcast
and on Twitter constantly and sticking your foot in your mouth?
To learn more, come chat at duckbillgroup.com.
Optionally, I will also do podcast voice when we talk about it.
(23:26):
Again, that's duckbillgroup.com.
You’ve been building out certifications for multiple cloud providers, so I’m
curious to get your take on something that Forrest Brazeal, who’s now head of
content over at Google Cloud, has been talking about lately, the idea that as
an engineer is advised to learn more than one cloud provider; even if you have
one as a primary, learning how another one works makes you a better engineer.
(23:49):
Now, setting aside entirely the idea that well, yeah, if I
worked at Google, I probably be saying something fairly similar.
Yeah.
Do you think there’s validity to the idea that most
people should be broad across multiple providers, or
do you think specialization on one is the right path?
Sure.
Just to contextualize for our listeners, Google Cloud is highly,
(24:10):
highly promoting multi-cloud workloads, and one of their flagship
products is—well, they say it’s a flagship product—is Anthos.
And they put a lot of money—I don’t know that was subsidized, but they put
a lot of money in it because they really want to push multi-cloud, right?
And so when we say Forrest works in Google Cloud, it should be no
surprise that he’s promoting it.
But I don’t work for Google, and I can tell you, like, learning
(24:32):
multi-cloud is, like, way more valuable than just staying in one vertical.
It just
opened my eyes.
When I went from AWS to Azure, it was just like, “Oh, I’m missing out on so much
in the industry.” And it really just made me such a more well-rounded person.
And I went over to Google Cloud, and it was just like… because
you’re learning the same thing in different variations, and then
you’re also poly-filling for things that you will never touch.
(24:53):
Or like, I shouldn’t say you never touch, but you would never
touch if you just stayed in that vertical when you’re learning.
So, in the industry, Azure Active Directory is, like,
widespread, but if you just stayed in your little AWS box,
you’re not going to notice it on that learning path, right?
And so a lot of times, I tell people, “Go get your CLF-C01 and then go get
your AZ-900 or AZ-104.” Again, I don’t care if people go and sit the exams.
(25:15):
I want them to go learn the content because it is a large eye-opener.
A lot of people are against multi-cloud from a learning perspective
because say, it’s too much to learn all at the same time.
But a lot of people I don’t think have actually gone across the cloud, right?
So, they’re sitting from their chair, only staying in one vertical
saying, “Well, you can’t learn them all at the same time.” And
I’m going, “I see a way that you could teach them all at the
same time.” And I might be the first person that will do it.
(25:37):
And the principles do convey as well.
It’s, “Oh, well I know how SNS works on AWS, so I would never
be able to understand how Google Pub/Sub works.” Those are
functionally identical; I don’t know that is actually true.
It’s just different to interface points and different guarantees, but fine.
You at least understand the part that it plays.
I’ve built things out on Google Cloud somewhat recently,
(25:58):
and for me, every time I do, it’s a refreshing eye-opener to
oh, this is what developer experience in the cloud could be.
And for a lot of customers, it is.
But staying too far within the bounds of one ecosystem does lend itself to a
loss of perspective, if you’re not careful.
I agree with that.
Yeah.
Well, I mean, just the paint more of a picture of differences,
like, Google Cloud has a lot about digital transformation.
(26:19):
They just updated their—I’m not happy that they changed it, but I’m fine that
they did that, but they updated their Google Digital Cloud Leader Exam Guide
this month, and it like is one hundred percent all about digital transformation.
So, they love talking about digital
transformation, and those kind of concepts there.
They are really good at defining migration strategies, like, at a high level.
Over to Azure, they have their own cloud adoption framework, and
it’s so detailed, in terms of, like, execution, where you go over
(26:44):
to AWS and they have, like, the worst cloud adoption framework.
It’s just the laziest thing I’ve ever seen produced in my
life compared to out of all the providers in that space.
I didn’t know about zero-trust model until I start using Azure because Azure
has Active Directory, and you can do risk-based policy procedures over there.
So, you know, like, if you don’t go over to these places,
you’re not going to get covered other places, so you’re just
going to be missing information till you get the job and, you
(27:06):
know, that job has that information requiring you to know it.
I would say that for someone early career—and I don’t know where this
falls on the list of career advice ranging from, “That is genius,”
to, “Okay, Boomer,” but I would argue that figuring out what companies
in your geographic area, or the companies that you have connections
with what they’re using for a cloud provider, I would bias for
(27:29):
learning one enough to get hired there and from there, letting what
you learn next be dictated by the environment you find yourself in.
Because especially larger companies, there’s always
something that lives in a different provider.
My default worst practice is multi-cloud.
And I don’t say that because multi-cloud doesn’t exist, and I’m not
saying it because it’s a bad idea, but this idea of one workload—to
(27:50):
me—that runs across multiple providers is generally a challenge.
What I see a lot more, done intelligently, is, “Okay, we’re going to use
this provider for some things, this other provider for other things, and
this third provider for yet more things.” And every company does that.
If not, there’s something very strange going on.
Even Amazon uses—if not Office 365, at least exchange to
(28:12):
run their email systems instead of Amazon WorkMail because—
Yeah.
Let’s be serious.
That tells me a lot.
But I don’t generally find myself in a scenario where I want to build
this application that is anything more than Hello World, where I want it
to run seamlessly and flawlessly across two different cloud providers.
That’s an awful lot of work that I struggle to
(28:33):
identify significant value for most workloads.
I don’t want to think about securing, like, multiple workloads,
and that’s I think a lot of friction for a lot of companies
are ingress-egress costs, which I’m sure you might have some
knowledge on there about the ingress-egress costs across providers.
Oh, a little bit, yeah.
A little bit, probably.
Oh, throwing data between clouds is always expensive.
Sure.
So, I mean, like, I call multi-cloud using
multiple providers, but not in tandem.
Cross-cloud is when you want to use something like Anthos or Azure
(28:57):
Arc or something like that where you extend your data plane or control
pla—whatever the plane is, whatever plane across all the providers.
But you know, in practice, I don’t think many people are doing
cross-cloud; they’re doing multi-cloud, like, “I use AWS to run my
primary workloads, and then I use Microsoft Office Suite, and so we
happen to use Azure Active Directory, or, you know, run particular VM
machines, like Windows machines for our accounting.” You know?
(29:19):
So, it’s a mixed bag, but I do think that using more
than one thing is becoming more popular just because you
want to use the best in breed no matter where you are.
So like, I love BigQuery.
BigQuery is amazing.
So, like, I ingest a lot of our data from, you
know, third-party services right into that.
I could be doing that in Redshift, which is expensive; I
could be doing that in Azure Synapse, which is also expensive.
(29:41):
I mean, there’s a serverless thing.
I don’t really get serverless.
So, I think that, you know, people are doing multi-cloud.
Yeah.
I would agree.
I tend to do things like that myself, and
whenever I see it generally makes sense.
This is my general guidance.
When I talk to individuals who say, “Well, we’re running
multi-cloud like this.” And my response is, “Great.
You’re probably right.”
Because I’m talking in the general sense, someone building something out
(30:02):
on day one where they don’t know, like, “Everyone’s saying multi-cloud.
Should I do that?” No, I don’t believe you should.
Now, if your company has done that intentionally, rather than by accident,
there’s almost certainly a reason and context that I do not have.
“Well, we have to run our SaaS application in multiple cloud providers
because that’s where our customers are.” “Yeah, you should probably
(30:23):
do that.” But your marketing, your billing systems, your back-end
reconciliation stuff generally does not live across all of those providers.
It lives in one.
That’s the sort of thing I’m talking about.
I think we’re in violent agreement here.
Oh, sure, yeah.
I mean, Kubernetes obviously is becoming very popular because people believe
that they’ll have a lot more mobility, Whereas when you use all the different
managed—and I’m still learning Kubernetes myself from the next certification
(30:46):
I have coming out, like, study course—but, you know, like, those managed
services have all different kind of kinks that are completely different.
And so, you know, it’s not going to be a smooth process.
And you’re still leveraging, like, for key things like your
database, you’re not going to be running that in Kubernetes Cluster.
You’re going to be using a managed service.
And so, those have their own kind of expectations in terms of configuration.
So, I don’t know, it’s tricky to say what to do, but I think that,
(31:08):
you know, if you have a need for it, and you don’t have a security
concern—like, usually it’s security or cost, right, for multi-cloud.
For me, at least, the lock-in has always
been twofold that people don’t talk about.
More—less lock-in than buy-in.
One is the security model where IAM is super fraught and challenging and
tricky, and trying to map a security model to multiple providers is super hard.
(31:29):
Then on top of that, you also have the buy-in story of a bunch
of engineers who are very good at one cloud provider, and that
skill set is not in less demand now than it was a year ago.
So okay, you’re going to start over and learn a new cloud provider
is often something that a lot of engineers won’t want to countenance.
If your team is dead set against it, there’s going to be
some friction there and there’s going to be a challenge.
(31:49):
I mean, for me at least, to say that someone knows a cloud
provider is not the naive approach of, “Oh yeah, they know
how it works across the board.” They know how it breaks.
For me, one of the most valuable reasons to run something on AWS
is I know what a failure mode looks like, I know how it degrades,
I know how to find out what’s going on when I see that degradation.
That to me is a very hard barrier to overcome.
(32:11):
Alternately, it’s entirely possible that I’m just old.
Oh, I think we’re starting to see some wins all over the place in
terms of being able to learn one thing and bring it other places, like
OpenTelemetry, which I believe is a cloud-native Kubernetes… CNCF.
I can’t remember what it stands for.
It’s like Linux Foundation, but for cloud-native.
And so OpenTelemetry is just a standardized way
of handling your logs, metrics, and traces, right?
(32:33):
And so maybe CloudWatch will be the 1.0 of observability in AWS, and
then maybe OpenTelemetry will become more of the standard, right, and so
maybe we might see more managed services like Prometheus and Grafa—well,
obviously, AWS has a managed Prometheus, but other things like that.
So, maybe some of those things will melt away.
But yeah, it’s hard to say what approach to take.
(32:53):
Yeah, I’m wondering, on some level, whether what the things
we’re talking about today, how well that’s going to map forward.
Because the industry is constantly changing.
The guidance I would give about should you be in cloud
five years ago would have been a nuanced, “Mmm, depends.
Maybe for yes, maybe for no.
Here’s the story.” It’s a lot less hedge-y and a lot
less edge case-y these days when I answer that question.
So, I wonder in five years from now when we look back at this podcast
(33:16):
episode, how well this discussion about what the future looks like,
and certifications, and multi-cloud, how well that’s going to reflect?
Well, when we look at, like, Kubernetes or Web3, we’re
just seeing kind of like the standardized boilerplate way
of doing a bunch of things, right, all over the place.
This distributed way of, like, having this generic API across the board.
And how well that will take, I have no idea, but we do see
(33:39):
a large split between, like, serverless and cloud-natives.
So, it’s like, what direction?
Or we’ll just have both?
Probably just have both, right?
[Like that] . I hope so.
It’s been a wild industry ride, and I’m really curious
to see what changes as we wind up continuing to grow.
But we’ll see.
That’s the nice thing about this is, worst case, if oh,
turns out that we were wrong on this whole cloud thing, and
(33:59):
everyone starts exodusing back to data centers, well, okay.
That’s the nice thing about being a small company.
It doesn’t take either of us that long to
address the reality we see in the industry.
Well, that or these cloud service providers are just going to
get better at offering those services within carrier hotels,
or data centers, or on your on-premise under your desk, right?
So… I don’t know, we’ll see.
It’s hard to say what the future will be, but I do believe
(34:20):
that cloud is sticking around in one form or another.
And it basically is, like, an essential skill or
table stakes for anybody that’s in the industry.
I mean, of course, not everywhere, but like, mostly, I would say.
So.
Andrew, I want to thank you for taking the time to speak with me today.
If people want to learn more about your
opinions, how you view these things, et cetera.
Where can they find you?
You know, I think the best place to find me right now is Twitter.
(34:42):
So, if you go to twitter.com/andrewbrown—all lowercase, no
spaces, no underscores, no hyphens—you’ll find me there.
I’m so surprised I was able to get that handle.
It’s like the only place where I have my
handle.
And we will of course put links to that in the [show notes]
. Thanks so much for taking the time to speak with me today.
I really
appreciate it.
Well, thanks for having me on the show.
(35:04):
Andrew Brown, co-founder and cloud instructor
at ExamPro Training and so much more.
I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
If you’ve enjoyed this podcast, please leave a five-star review on your
podcast platform of choice, whereas if you’ve hated this podcast, please
leave a five-star review on your podcast platform of choice, along with
an angry comment telling me that I do not understand certifications at all
(35:27):
because you’re an accountant, and certifications matter more in that industry.
Popular Podcasts
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.