So effectively, the bigger fish scenario, it’s making
the market smaller in terms of providers are there.
You really don’t have many providers doing cloud-specific training anymore.
Welcome to Screaming in the Cloud.
I’m Corey Quinn.
Every once in a while I talk to someone about, “Oh, yeah, remember
that time that you appeared on Screaming in the Cloud?” And it
turns out that they didn’t; it was something of a fever dream.
Today is one of those guests that I’m, frankly,
astonished I haven’t had on before: Ant Stanley.
Ant, thank you so much for indulging me and somehow
forgiving me for not having you on previously.
Hey, Corey, thanks for that.
Yeah, I’m not too sure why I haven’t been on previously.
You can explain that to me over a beer one day.
Absolutely, and I’m sure I’ll be the one that
buys it because that is just inexcusable.
This episode is sponsored in part by my day job, the Duckbill Group.
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.
Remember, you can't duck the duck bill, Bill.
And my CEO informs me that is absolutely not our slogan.
So, who are you?
What do you do?
I know that you’re a Serverless Hero at AWS, which is probably the
most self-aggrandizing thing you can call someone because who in the
world in their right mind is going to introduce themselves that way?
That’s what you have me for.
I’ll introduce you that way.
So, you’re an AWS Serverless Hero.
What does that mean?
So, the Serverless Hero, effectively I’ve been recognized for my contribution
to the serverless community, what that contribution is potentially dubious.
But yeah, I was one of the original co-founders of A Cloud Guru.
We were a serverless-first company, way back when.
So, from 2015 to 2016, I was with A Cloud Guru
with Ryan and Sam, the two other co-founders.
I left in 2016 after we’d run ServerlessConf.
So, I led and ran the first ServerlessConf.
And then for various reasons, I decided, hey, the pressure was too much;
I needed a break, and a few other reasons I decided to leave A Cloud Guru.
A very amicable split with my former co-founders.
And then yeah, I kind of took a break, took some time off, de-stressed, got
the serverless user group in London up and running; ran a small conference
in London called JeffConf, which was a take on a blog that Paul Johnson, who
was one of the folks who ran JeffConf with me, wrote a while ago saying we
could have called it serverless—and we might as well have called it Jeff.
Could have called it anything; might as well have called it Jeff.
So, we had this joke about JeffConf.
Not a reference to Mr.
Bazos.
No, no.
Though they do have an awful lot of Jeffs working over there.
But that’s neither here nor there.
‘The Land of the Infinite Jeffs’ as it were.
Yeah, exactly.
There are more Jeffs than women in the exec team if I remember correctly.
I think it’s now it’s a Dave problem instead.
Yeah, it’s a Dave problem.
Yeah.
[laugh] . It’s not a problem either way.
Yeah.
So, JeffConf morphed into SeverlessDays, which
is a group of community events around the world.
So, I think AWS said, “Hey, this guy likes
running serverless events for some silly reason.
Let’s make him a Serverless Hero.”
And here we are.
Which is interesting because a few directions you can take this in.
One of them, most recently, we were having a conversation, and you were opining
on your thoughts of the current state of serverless, which can succinctly
be distilled down to ‘serverless sucks,’ which is not something you’d expect
to hear from a Serverless Hero—and I hope you can hear the initial caps
when I say ‘Serverless Hero’—or the founder of a serverless conference.
So, what’s the deal with that?
Why does it suck?
So, whole serverless movement started to gather momentum in 2015.
The early adopters were all extremely experienced technologists,
folks like Ben Kehoe, the chief robotics scientist at
iRobot—he’s incredibly smart—and folks of that caliber.
And those were the kinds of people who spoke at the first
serverless conference, spoke at all the first serverless events.
And, you know, you’d kind of expect that with a new technology where there’s
not a lot of body of knowledge, you’d expect these high-level, really advanced
folks being the ones putting themselves out there, being the early adopters.
The problem is we’re in 2021 and that’s still the profile
of the people who are adopting serverless, you know?
It’s still not this mass adoption.
And part of the reason for me is because of the complexity around it.
The user experience for most serverless tools is not great.
It’s not easy to adopt.
The patterns aren’t standardized and well known—even though
there are a million websites out there saying that there are
serverless patterns—and the concepts aren’t well explained.
I think there’s still a fair amount of education that needs to happen.
I think folks have focused far too much on the technical aspects of
serverless, and what is serverless and not serverless, or how you
deploy something, or how you monitor something, observability, instead
of going back to basics and first principles of what is this thing?
Why should you do it?
How do you do it?
And how do we make that easy?
There’s no real focus on user experience and adoption for inexperienced folks.
The adoption curve, the learning curve for serverless, no matter
what platform you do, if you want to do anything that’s beyond a
side project it’s really difficult because there’s no easy path.
And I know there’s going to be folks that are going to complain about it,
but the Serverless Stack just got a million dollars to solve this problem.
I love the Serverless Stack.
They had a great way of building things out.
Yeah.
I cribbed a fair bit from what they built when I was building out my
own serverless project of the newsletter production pipeline system.
And that’s awesome.
And I built that, and I run it mostly as a technology testbed.
But my website, lastweekinaws.com?
I pay WP Engine to host it on WordPress and the reason behind that is
not that I can’t figure out the serverless pieces of it, it’s because
when I want to hire someone to do something that’s a bit off the
beaten path on WordPress, I don’t have to spend $400 an hour for a
consultant to do it because there’s more than 20 people in the world
who understand how all this stuff fits together and integrates well.
There’s something to be said for going in the direction the rest of the
market is when there’s not a lot of reason to differentiate yourselves.
Yeah, could I save thousands of dollars a year in
infrastructure costs if I’d gone with serverless?
Of course, but people’s time is worth more than that.
It’s expensive to have people work on these things.
And even on the serverless stuff that I’ve built, if it’s been more than
six months since I’ve touched a component, someone else may have written it;
I have to rediscover what the hell I was thinking and what the constraints
are, what the constraints I thought existed there in the platform.
And every time I deal with Lambda or API Gateway, I come
away with a spiraling sense of complexity tied to all of it.
And the vision of serverless I believe in, truly,
but the execution has lagged from all providers.
Yeah.
I agree with that completely.
The execution is just not there.
I look at the situation—so Datadog had their report, “The State of
Serverless Report” that came out about a month or two ago; I think
it’s the second year they’ve done it, now, might be the third.
And in the report, one of the sections, they talked about tooling.
And they said, “What’s the most adopted tools?” And they had
the Serverless Framework in there, they had SAM in there,
they had CloudFormation, I think they had Terraform in there.
But basically, Serverless Framework had 70% of the respondents.
70% of folks using Datadog and using serverless
tools were using Serverless Framework.
But SAM, AWS’s preferred solution, was like 12%.
It was really tiny and this is the thing that every single AWS demo
example uses, that the serverless developer advocates push heavily.
And it’s the official solution, but the Serverless Application Model
is just not being adopted and there are reasons for that, and it’s
because it’s the way they approach the market because it’s highly
opinionated, and they don’t really listen to end-users that much.
And their CDK out there.
So, that’s the other AWS organizational complexity as
well, you’ve got another team within AWS, another product
team who’ve developed this different way—CDK—doing things.
This is all AWS’s fault, by the way.
For the longest time, I’ve been complaining about Lambda edge functions
because they are not at all transparent; you have to wait for a
CloudFront deployment for it to update every time, only to figure out
that in my case, I forgot a comma because I’ve never heard of a linter.
And it becomes this awful thing.
Only recently did I find out they only run at regional edge caches,
not just in all of the CloudFront pop, so I said, “The hell with
it,” ripped it out of everything I was using it with, and wound
up implementing it in bog-standard Lambda because it was easier.
But then rather than fixing that, they’ve created
their—what was it—their CloudFront Workers.
Or is it—is it CloudFront Workers, or is it CloudFront Functions?
No, CloudFront Functions.
I don’t even remember it because rather than fixing the thing,
you just released a different thing that addresses these
problems in very different ways that aren’t directly compatible.
And it’s oh, great, awesome.
Terrific.
As a customer, I want absolutely not this.
It’s one of these where, honestly, I’ve left in many cases with the
resigned position of, if you’re not going to take this seriously, why am I?
Yeah, exactly.
And it’s bizarre.
So, the CloudFront Functions thing, it’s
based on Nginx’s [little] JavaScript engine.
So, it’s the Nginx team supporting it—the engine—which is really
small number of users; it’s tiny, there’s no foundation behind it.
So, you’ve got these massive companies reliant on some tiny organization
to support the runtime of one of their businesses, one of their services.
And they expect people to adopt it.
And on top of that, that engine supports primary language
is JavaScript’s ES5 or ES2015, which is the 2015 edition of
JavaScript, so it’s a six-year-old version of JavaScript.
You cannot use one JavaScript with it which also means you
can’t use any other tools in the JavaScript ecosystem for it.
So basically, anything you write for that is going to
be vanilla, you’re going to write yourself, there’s no
tooling, no community to really leverage to use that thing.
Again, like, why have you even done that?
Why if you now gone off and taken an engine no one uses—they
will say someone uses it, but basically no one uses—
No one willingly uses or knowingly uses it.
Yeah.
No one really uses.
And then decided to run that.
Why not look at WebAssembly—it’s crazy—which has a
foundation behind it and they’re doing great things,
and other providers are using WebAssembly on the edge.
I just don’t understand the thought process—well, I say I don’t
understand, but I do understand the thought processes behind Amazon.
Every single GM in Amazon is effectively incentivized to
release stuff, and build stuff, and to get stuff out the door.
That’s how they make money.
You hear the stories—
Oh, it’s been clear for years.
They only recently stopped—in their keynotes every year—talking about
the number of feature releases that they’ve had over the past 12 months.
And I think they finally had it clued into them by someone snarky
on Twitter—ahem—that the only people that feel good about that
are people internal to AWS because customers see that and get
horrified of, “I haven’t kept up with most of those things.
How many of those are important?
How many of them are nonsense?”
And I’m sure somewhere you have released a serverless that will solve
my business problem perfectly so I don’t have to build it together
myself out of Lambda functions, and string, and popsicle sticks, but
I’ll never hear about it because you’re too busy talking about nonsense.
And that problem still exists and it’s writ large.
There’s a philosophy around not breaking existing workloads—which
I get; that’s a hard problem to solve for—but their solution is,
rather than fixing existing services will launch a new one that
doesn’t have those constraints and takes a different approach to it.
And it’s horrible.
Yeah, exactly.
If you compare Amazon to Apple, Apple releases a
net-new product once a year, once every two years.
You’re talking about new generations of products, that comes out
on an annualized basis, but when you’re talking about actual new
product, not that frequently.
The last one—
Yeah.
—I can really think of is probably going to
be AirPods, at least of any significance.
AirTags is the new one.
Oh, AirTags.
AirTags is recent, which is a neat—but it’s
an accessory to the rest of those things.
It is—
And then there’s AirPods.
But yeah, it’s once—because they—everything works.
If you’re in that Apple ecosystem, everything works.
And everything’s back-ported and supported.
My four-year-old phone still works and had a five-year-old MacBook
before this current one, still worked, you know, not a problem.
And those two philosophies—and the Amazon folk are heavily incentivized
to release products and to grow the usage of those products.
And they’re all incentivized within their bubbles.
So, that’s why you get competing products.
That’s why Proton exists when CodeBuild and
CodePipeline, and all of those things exist,
and you have all these competing products.
I’m waiting for the container team to fully recreate AWS on top of containers.
They’re not far away.
They’re already in the process of recreating AWS on top of Lightsail.
It’s more or less the, “Oh, we’re making
this the simpler version.” Which is great.
You know who likes simplicity?
Freaking everyone.
So, it’s the vision of a cloud, we could have had but didn’t.
“Oh, you want a virtual machine.
Spin up a Lightsail instance; you’re going to get a fixed amount
of compute, disk, RAM, and CPU that you can adjust, and it’s going
to cost you a flat fee per month until you exceed some fairly
high limits.” Why can’t everything be like that, on some level?
Because in many cases, I don’t care about wanting
to know exactly to the penny shave things off.
I want to spin up a fleet of 20 virtual machines, and if they cost
me 20 bucks a pop each a month, I can forecast that, I can budget for
that, I can do a lot and I don’t actually care in any business context
about the money there, but dialing it in and having the variable
charges and the rest, and, “Oh, you went through a managed NAT gateway.
That’s going to double your bandwidth price and it’s going to be expensive.
Surprise, you should have looked more closely at it,”
is sort of the lesson of the original AWS services.
At some level, they’ve deviated away from anything resembling simplicity and
increasingly we’re seeing a world where in order to do something effectively
with cloud, you have to spend 12 weeks going to cloud school first.
Oh, yeah.
Completely.
See, that’s one of the major barriers with serverless.
You can’t use serverless for any of the major cloud
providers until you understand that cloud provider.
So yeah, do your 12 weeks of cloud school.
And there’s more than enough providers.
Whoa, whoa, whoa.
Before you spin up a function that runs code, you have to understand
the identity and security model, and how the network works, and a bunch
of other ancillary nonsense that isn’t directly tied to business value.
And all these fun things.
How are you’re going to test this, and how are you’re going to do all that?
How do you write the entry point?
Where is it going to enter?
What is it expecting?
What objects are getting passed in, if any?
What format is it going to take?
I’ve spent days, previously, trying to figure out the exact
invocation for working with a JSON object in Python, what
that’s going to show up as, and how specifically to refer to it.
And once you’ve done that a couple of times, great, fine, it’s easy.
Copy and paste it from the last time you did it.
But figuring it out from first principles, particularly
in a time when there isn’t a lot of good public
demonstrations of this—especially early days—it’s hard to do.
Yeah.
And they just love complexity.
Have you looked at the second edition—so the
third version of the AWS SDK for JavaScript?
I don’t touch JavaScript with my hands most days, just
because I’m bad at it and I don’t understand the asynchronous
model and computers are really not my thing most.
So, unfortunately for my sins, I do use JavaScript a lot.
So, version two of the SDK is effectively the single most popular Cloud
SDK of any language, anything out there; 20 million downloads a week.
It’s crazy.
It’s huge—version two.
And JavaScript’s a very fast-evolving language, though.
Basically, it’s a bit like the English language in that
it adopts things from other languages through osmosis,
and co-opts various other features of other languages.
So, JavaScript has—if there’s a feature you love in your
language, it’s going to end up in JavaScript at some point.
So, it becomes a very broad Swiss Army knife that can do almost anything.
And there’s always better ways to do things.
So, the problem is, the version two was written in old JavaScript
from years twenty fifteen years five years six kind of level.
So, from 2015, 2016, I—you know, 2020, 2021, JavaScript has changed.
So, they said, “Oh, we’re going to rewrite this.” Which good; you should do.
But they absolutely broke all compatibility with version two.
So, there is no path from version two to
version three without rewriting what you’ve got.
So, if you want to take anything you’ve written—not even serverless—anything
in JavaScript you’ve written and you want to upgrade it to get some of the new
features of JavaScript in the SDK, you have to rewrite your code to do that.
And some instances, if you’re using hexagonal architecture and
you’re doing all the right things, that’s a really small thing to do.
But most people aren’t doing that.
But let’s face it, a lot of things grow organically.
Yeah.
And again, I can sit here and tell you how to build things
appropriately and then I look at my own environment and… yeah,
pay no attention to that burning dumpster fire behind the camera.
And it’s awful.
You want to make sure that you’re doing things the right way
but it’s hard to do and taking on additional toil because
the provider decides the time to focus on this is a problem.
But it’s completely not a user-centric way of thinking.
You know, they’ve got all their 14—is it 16 principles now?
Did they add two principles, didn’t they?
They added two to get up to 16; one less than
the numbers of ways to run containers in AWS.
Yeah.
They could barely contain themselves.
[laugh] . It’s just not customer-centric.
They’ve moved themselves away from that customer-centric view of the
world because the reality is, they are centered on the goals of the
team, the goals of the GM, and the goals of that particular product.
That famous drawing of all the different organizational charts, they
got the Facebook chart, and the Google Chart, and the Amazon chart
has all these little circles, everyone pointing guns at each other.
And the more Amazon grows, the more you feel like that’s reality.
And it’s hurting users, it’s massively hurting users.
And we feel the pain every day, absolutely every day, which is not great.
And it’s going to hurt Amazon in the long run, but short-term,
they’re not going to see that pain quarterly, they’re
not going to see that pain, probably within 12 months.
But they will see the pain long run.
And if they want to fix it, they probably
should have started fixing it two years ago.
But it’s going to take years to fix because that’s a massive cultural
shift to say, “Okay, how do we get back to being more customer-focused?
How do we stop that organizational targets and goals from
getting in the way of delivering value to the customer?”
It’s a good question.
The hard part is getting customers to understand enough of what
you put out there to be able to disambiguate what you’ve built,
and what parts to trust, what parts not the trust, what parts
are going to be hard, et cetera, et cetera, et cetera, et cetera.
The concern that I’ve got across the board here is, how do you learn?
How do you get started with this?
And the way that I came into this was I started off,
in the early days of AWS, there were a dozen services,
and okay, I could sort of stumble my way through it.
And the UI was rough, but it got better with time.
So, the answer for a lot of folks these days is training, which makes sense.
In the beginning, we learned through things like podcasts.
Like there was a company called Jupiter Broadcasting which did a
bunch of Linux-oriented podcasts and learned how this stuff works.
And then they were acquired by Linux Academy which really focused on training.
And then A Cloud Guru acquired Linux Academy.
And then Pluralsight acquired A Cloud Guru and is now in the
process of itself being acquired by Vista Equity Partners.
There’s always a bigger fish eating something somewhere.
It feels like a tremendous, tremendous consolidation in the training market.
Given that you were one of the founders of
A Cloud Guru, where do you stand on that?
So, in terms of that actual transaction, I don’t know the details
because I’m a long time out of A Cloud Guru, but I’ve stayed within the
whole training sphere, and so effectively, the bigger fish scenario,
it’s making the market smaller in terms of providers are there.
You really don’t have many providers doing cloud-specific training anymore.
On one level you don’t, but then another level, you’ve
got lots of independent folks doing tons of stuff.
So, you’ve got this explosion at the bottom end.
If you go to Udemy—which is where A Cloud Guru started, on Udemy—you
will see tons of folks offering courses at ten bucks a pop.
And then there’s what I’m doing now on homeschool.dev;
there’s serverless-focused training on there.
But that’s really focused on a really small niche.
So, there’s this explosion at the bottom end of lots of small people doing
lots of things, and then you’ve got this consolidation at the top end, all
the big providers buying each other, which leaves a massive gap in the middle.
And on top of that, you’ve got AWS themselves, and all the other
cloud providers, offering a lot of their own free training, whether
it’s on their own platforms—there’s aws.training now, and Microsoft
have similar as well—I think it’s learn.microsoft.com is theirs.
And you’ve got all these
different providers doing their own training, so there’s lots out there.
There’s actually probably more training for lower costs than ever before.
The problem is, it’s like the complexity of too
many services, it’s the 17 container problem.
Which training do you use because the actual cost of the training is your time?
It’s not the cost of the course.
Your time is always going to be more expensive.
Yeah, the course is never going to be anywhere
comparable to the time you spend on it.
And I’ve never understood, frankly, why these large companies charge money
for training on their own platform and also charge money for certifications
because I don’t care what you’re going to pay for those things, once you
know a platform well enough to hit a certification, you’re going to use
the thing you know, in most cases; it’s a great bottom-up adoption story.
Yeah, completely.
That was actually one of Amazon’s first early problems with their
trainings, why A Cloud Guru even exists, and Linux Academy, and
Cloud Academy all actually came into being is because Amazon hired
a bunch of folks from VMware to set up their training program.
And VMware’s training, back in the day, was a profit center.
So, you’d have a one-and-a-half thousand, two thousand dollar
training course you’d go on for three to five days, and then
you’d have a couple hundred dollars to do the certification.
It was a profit center because VMware didn’t really have that much competition.
Zen and Microsoft’s Hyper V were so late to the
market, they basically own the market at the time.
So—
Oh, yeah.
They still do in some corners.
Yeah.
They’re still massively doing in this place as they still exist.
And so they Amazon hired a bunch of ex-VMware folk, and they said, “We’re
just going to do what we did at VMware and do it at Amazon,” not realizing
Amazon didn’t own the market at the time, was still growing, and they tried
to make it a profit center, which basically left a huge gap for folks who
just did something at a reasonable price, which was basically everyone else.
[laugh]
. 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
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.
Again, that's duckbillgroup.com.
The challenge I found with a few of these courses as well, is that
they teach you the certification, and the certifications are, in some
ways, crap when it comes to things you actually
need to know to intelligently use a platform.
So, many of them distill down not to the things you need to know,
but to the things that are easy to test in a multiple-choice format.
So, it devolves inherently into trivia such as, “Which is the right
syntax for this thing?” Or, “Which one of these CloudFormations
stanzas or functions isn’t real?” Things like that where it’s,
no one in the real world needs to know any of those things.
I don’t know anyone these days—sensible—who can write
CloudFormation from scratch without pulling up some reference
somewhere because most people don’t have that stuff in their head.
And if you do, I’d suggest forgetting it so you can use
that space to remember something that’s more valuable.
It doesn’t make sense for how people interact with these things.
But I do see the value as well in large companies
trying to upskill thousands and thousands of people.
You have 5000 people that are trying to come up
to speed because you’re migrating into cloud.
How do you judge people’s progress?
Well, certifications are an easy answer.
Yeah, massively.
Probably the most successful blog post ever written—I
don’t think it’s up anymore, but it was when I was at A
Cloud Gurus—like, what’s the value of a certification?
And ultimately, it came down to, it’s a way for
companies that are hiring to filter people easily.
That’s it.
That’s really it.
It’s if you’ve got to hire ten people and you get 1000 CVs or resumes for those
ten roles, first thing you do is you filter by who’s certified for that role.
And then you go through anything else.
Does the certification mean you can actually do the job?
Not really.
There are hundreds of people who are not cer—thousands, millions
of people who are not certified to do jobs that they do.
But when you’re getting hired and there’s lots of people applying for
the same role, it’s literally the first thing they will filter on.
And it’s—so you want to get certified, it’s hard to get through that filter.
That’s what the certification does, it’s how you get through that
first filter of whatever the talent tracking system they’re using is.
That’s it.
And how to get into the dev lounge at re:Invent.
Oh yeah, that’s my reason for getting a certification, originally.
And again, for folks who learn effectively that way,
I have no problem with people getting certifications.
If you’re trying to advance in your career, especially early
stage, and you need a piece of paper that says you know what
you’re talking about, a certification is a decent approach.
In time, with seniority, that gets replaced by a piece of paper, it’s called
your resume or your CV, but that is a longer-term more senior-focused approach.
I don’t begrudge people getting certifications and
I don’t think that they’re foolish for doing it.
But in time, it feels like the market for training is
simultaneously contracting into only a few players left, and also,
I’m curious as to whether or not the large companies out there
are increasing their spend with the training providers or not.
On the community side, the direct-to-consumer approach, that is exploding,
but at the same time, you’re then also dealing—forgive me, listeners—with
the general public and there is nothing worse than a customer, from a
customer service perspective, who was only paying a little money to you.
I used to work in a web hosting company that
$3,000 a month customers were great to work with.
The $2999 a month customers were hell on earth who expected that
they were entitled to 80 hours a month of systems engineering time.
And you see something similar in the training space.
It’s always the small individual customers who are spending personal
money instead of corporate money that are more difficult to serve.
You’ve been in the space for a while.
What do you see around that?
Yeah, I definitely see that.
So, the smaller customers, there’s a correlation between the amount
of money you spend and the amount of hand-holding that someone needs.
The more money someone spends, the less hand-holding they need, generally.
But the other side of it, what training businesses—particularly
for subscription-based business—it’s the same model as most gyms.
You pay for it and you never use
it.
And it’s not just subscription; like, Udemy is a perfect
example of that, you know, people who have hundreds of Udemy
courses they’ve never done, but they spend ten bucks on each.
So, there’s a lot of that at the lower end,
which is why people offer courses at that level.
So, there’s people who actually do the course who are going to give
you a lot of a headache, but then you’re going to have a bunch of
folk who never do the course and you’re just taking their money.
Which is also not great, either, but those folks don’t
feel bad because I only spent 10, 20 bucks on it.
It’s like, oh, it’s their fault for not doing it, and you’ve made the money.
So, that’s kind of how a lot of the training works.
So, the other problem with training as well is you
get the quality is so variable at the bottom end.
It’s so, so variable.
You really struggle to find—there’s a lot of people just copying, like, you
see instances where folks upload videos to Udemy that are literally they’ve
downloaded someone’s, video resized it, cut out a logo or something like
that, and re-uploaded it and it’s taken a few weeks for them to get caught.
But they made money in the meantime.
That’s how blatant it does get to some level, but there are levels
where people will copy someone else’s content and just basically make
it their own slides, own words, that kind of thing; that happens a lot.
At the low end, it’s a bit all over the place, but you still have quality,
as well, at the low end, where you have these cheapest smaller courses.
And how do you find that quality, as well?
That’s the other side of it.
And also people will just trade in their name.
That’s the other problem you see.
Someone has a name for doing X whatever, and they’ll
go out and bring a course on whatever that is.
Doesn’t mean they’re a good teacher; it means they’re good at building a brand.
Oh, teaching is very much its own skill set.
Oh, yeah.
I learned to speak publicly by being a corporate
trainer for Puppet and it teaches you an awful lot.
But I had the benefit, in that case, of a team of people who spent
their entire careers building curricula, so it wasn’t just me throwing
together some slides; I would teach a well-structured curriculum
that was built by someone who knew exactly what they’re doing.
And yeah, I needed to understand failure modes, and how to get things to
work when they weren’t working properly, and how to explain it in different
ways for folks who learn in different ways—and that is the skill of teaching
right there—but curriculum development is usually not the same thing.
And when you’re bootstrapping, learning—I’m going to build my own
training course, you have to do all of those things, and more.
And it lends itself to, in many cases, what can
come across as relatively low-quality offerings.
Yeah, completely.
And it’s hard.
But one thing you will often see is sometimes you’ll see a course
that’s really high production quality, but actually, the content
isn’t great because folks have focused on making it look good.
That’s another common, common problem I see.
If you’re going to do training out there, just get
referrals, get references, find people who’ve done it.
Don’t believe the references you see on a website;
there’s a good chance they might be fake or exaggerated.
Put something out on Twitter, put out something on Reddit, whatever
communities—and Slack or Discord, whatever groups you’re in, ask questions.
And folks will recommend.
In the world of Google where you could search for anything, [laugh]
, the only way to really find out if something is any good is to find
out if someone else has done it first and get their opinion on it.
That’s really the right answer.
And frankly, I think that is sort of the network
effect that makes a lot of software work for folks.
Because you don’t want to wind up being the first
person on your provider trying to do a certain thing.
The right answer is making sure that you are basically 8,000th person
to try and do this thing so you can just Google it and there’s a
bunch of results and you can borrow code on GitHub—which is how we
call ‘thought leadership’ because plagiarism just doesn’t work the
same way—and effectively realizing this has been solved before.
If you find a brand new cloud that has no customers, you are
trailblazing every time you do anything with the platform.
And that’s personally never where I wanted to spend my innovation points.
We did that at Cloud Guru.
I think when we were—in 2015 and we had problems with Lambda and
you go to Stack Overflow, and there was no Lambda tag on Stack
Overflow, no serverless tag on Stack Overflow, but you asked
a question and Tim Wagner would probably be the one answering.
And he was the former head of product on Lambda.
But it was painful, and in general you don’t want to do it.
Like [sigh] whenever AWS comes out with a new product, I’ve done
it a few times, I’ll go, “I think I might want to use this thing.”
AWS Proton is a really good example.
It’s like, “Hey, this looks awesome.
It looks better than CodeBuild and CodePipeline,”
the headlines or what I thought it would be.
I basically went while the keynote was on, I logged in to
our console, had a look at it, and realized it was awful.
And then I started tweeting about it as well and then
got a lot of feedback [laugh] on my tweets on that.
And in general, my attitude from whatever the new shiny
thing is if I’m going to try it, it needs to work perfectly
and it needs to live up to its billing on day one.
Otherwise, I’m not going to touch it.
And in general with AWS products now, you announce
something, I’m not going to look at it for a year.
And it’s to their benefit that you don’t look at it for a year because
the answer is going to be, ah, if you’re going to see that it’s terrible,
that’s going to form your opinion and you won’t go back later when it’s
actually decent and reevaluate your opinion because no one ever does.
We’re all busy.
Yeah, exactly.
And there’s nothing wrong with doing that, but it is
obnoxious they’re not doing themselves favors here.
Yeah, completely.
And I think that’s actually a failure of marketing
and communication more than anything else.
I don’t blame the product
teams too much there.
Don’t bill something as a finished glossy product when it’s not.
Pitch it at where it is.
Say, “Hey, we are building”—like, I don’t think at the re:Invent stage
they should announce anything that’s not GA and anything that it does
not live up to the billing, the hype they’re going to give it to.
And they’re getting more and more guilty of that the last
few re:Invents, of announcing products that do not live up
to the hype that they promote it at and that are not GA.
Literally, they should just have a straight-up rule, they can announce
products, but don’t put it on the keynote stage if it’s not GA.
That’s it.
The whole re:Invent release is a whole separate series of arguments.
[laugh] . Yeah, yeah.
There are very few substantial releases throughout the year
and then they drop a whole bunch of them at re:Invent, and
it doesn’t matter what you’re talking about, whose problem
it solves, how great it is, it gets drowned out in the flood.
The only thing more foolish that I see than that is companies that
are not AWS releasing things during re:Invent that are not on the
re:Invent keynote stage, which in turn means that no one pays attention.
The only thing you should be releasing is news about your data breach.
[laugh] . Yeah.
That’s exactly it.
What do I want to bury?
Whenever Adam Selipsky gets on stage and starts talking, great, then
it’s time to push the button on the, “We regret to inform you,k” dance.
Yeah, exactly.
Microsoft will announce yet another print spooler bug malware.
Ugh, don’t get me started on that.
Thank you so much for taking the time to speak with me today.
If people want to hear more about your thoughts and how you
view these nonsenses, and of course to send angry emails
because they are serverless fans, where can they find you?
Twitter is probably the easiest place to find me, @iamstan—
It is a place for outrage.
Yes.
Your Twitter user account is?
[laugh] , my Twitter user account’s all over the place.
It’s probably about 20% serverless.
So, yeah @iamstan.
Tweet me; I will probably respond to you…
unless you’re rude, then I probably won’t.
If you’re rude about something else, I probably will.
But if you’re rude about me, I won’t.
And I expect a few DMs from Amazon after this.
I’m waiting for you, [unintelligible] , as I always do.
So yeah, that’s probably the
easiest place to get hold of me.
I check my email once a month.
And I’m actually not joking about that; I really do check my email once a month.
Yeah, people really need me then they’ll find me.
Thank you so much for taking the time to speak with me.
I appreciate it.
Yes, Corey.
Thank you.
Ant Stanley, AWS Serverless Hero, and oh 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 defending serverless’s good name just as soon as you
string together the 85 components necessary to submit that comment.