Screaming in the Cloud - Serverless Hero, Got Servers in His Eyes with Ant Stanley

Episode Date: August 31, 2021

About AntAnt Co-founded A Cloud Guru, ServerlessConf, JeffConf, ServerlessDays and now running Senzo/Homeschool, in between other things. He needs to work on his decision making.Links:A Cloud Guru: https://acloudguru.comhomeschool.dev: https://homeschool.devaws.training: https://aws.traininglearn.microsoft.com: https://learn.microsoft.comTwitter: https://twitter.com/iamstan

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me.

I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that, that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more because they also have an enterprise option that you should be very much aware of. Canary.tools. Take a look at this. What it does is provides an

enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever you want it to. Whenever it gets NMAP scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at and say, this is an amazing idea. I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools. And the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into. Take a look. I'm a big fan. More to come from Thinkst Canary in the weeks ahead.

This episode is sponsored in part by Cribble Logstream. Cribble Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere to anywhere. Simple, right? As a nice bonus, it helps you not only improve visibility into what the hell's going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell into a company name. To learn more, visit Cribble.io. That's C-R-I-B-L dot I-O, and tell them Corey sent you, and wait for the wince. 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. 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 service hero, effectively, I've been recognized for my contribution to the service community. What that contribution is, is potentially dubious. But yeah, I was one of the original co-founders of Aclide 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 serverless conf. So I led and ran the first serverless conf. 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. Very amicable, split with my former co-founders, my mates. 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 jeff conf which was a take on a blog that paul johnson who was one of the folks who ran jeff conf 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. Bezos. 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 were more Jeffs than women in the exec team, if I remember correctly. I think now it's a Dave problem instead. Yeah, it's a Dave problem. Yeah. It's still a problem either way. Yeah, so Jeff Conf morphed into Serverless Days, 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 there's a few directions we 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 the whole serverless movement started to gather momentum in 2015. The early adopters were all extremely experienced technologists. You know, folks like Ben Keogh, the chief robotics scientist at iRobot, he's incredibly smart, and folks of that caliber. And those are the kind 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 or 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 who are going to complain about it, but the serverless stack just got a million dollars to solve this problem. I love the serverless stack just got a million dollars to solve this problem. Oh, I love the serverless stack. They had a great way of building things out. 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 last week in AWS.com, I paid 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 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, their status 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, you know, what's the most adopted tools? You know, and they had the service framework in there. They had SAM in there. They had CloudFormation. I think they had Terraform in there. But basically service framework had 70% of the respondents, 70% of folks using Datadog and using service tools

were using service 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 users at the service developer advocates push heavily. And it's the official solution, but the service application model is just not being adopted. And there are reasons for that.

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 there's CDK out there. So that's the other AWS organizational complexity as well. You've got another team within AWS, another product team, who have developed this different way of CDK. 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'd 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 the CloudFront pops. 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 rather than fixing that, they've created their CloudFront workers. Is it CloudFront workers or is it CloudFront functions? No, CloudFront functions. I don't even remember it because it's 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'm 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 a really small number of users. It's tiny. It's no foundation behind it. So you've got this massive company 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 modern JavaScript with it, which also means you can't use any of the 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. And then like, why have you even done that? Why have you now gone off and taken an engine no one uses? They will say someone uses it, but basically no one uses it. 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 that the thought process is behind Amazon. Every single GM in Amazon is effectively incentivized to release stuff and build stuff and to get stuff out the door.

It's how they make money. You know, 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 service 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, we'll launch a new one that doesn't have those constraints and it 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. You're talking about an actual new product? Not that frequently.

The last one 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 neat, but it's an accessory to the rest of those things. And then there's AirPods. But yeah, it's once because everything works. If you're in that Apple ecosystem, everything works.

And everything's backported 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, you know, 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 CodeParplan

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 light sale 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. Let's say that's one of the major barriers with serverless.

You know, you can't use serverless for any of the major cloud providers until you understand that cloud provider. So yeah, do your 12 weeks at cloud school. And there's more than that. Well, 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 going to test this? And how are you 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 it 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 days. 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

or 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. So basically it's a bit like the English language in that it adopts things from other languages

and through osmosis and co-ops, 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 2 was written in old JavaScript from ES 2015, ES 5, ES 6 kind of level. So from 2015, 2016. And at 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 2. So there is no path from version 2 to version 3 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 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. 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, 16 principles now. Did they add two principles? They added two to get up to 16. One less, the numbers of ways to run containers in AWS. Yeah, they could barely contain themselves.

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've got the Facebook chart and the Google chart and the Amazon chart. There's 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. 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 our 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've put out that people disambiguate what you've built

and what parts to trust, what parts not to trust, what parts are going to be hard, etc., etc., etc., etc. 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, like 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? Yeah, 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 out there. You really don't have many providers doing card-specific training anymore. On one level, you don't. But then on another level, you've got lots of independent folk doing tons of stuff. So you've got this explosion at the bottom end. If you go to Udemy, which is where A-Card Guru actually started on

Udemy, you will see tons of folks offering card courses at $10 a pop. And then there's what I'm doing now, homeschool.dev. There's service-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 same 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's actually one of Amazon's first early problems with their trainings, why Card Guru even exists and Linux Academy and Card Academy all actually came into being because Amazon hired a bunch of folk 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 $1,500, $2,000 training course you'd go on for three to five days, and then you'd have a couple hundred dollars to do the certification.

And it was a profit center because VMware didn't really have that much competition. Zen and Microsoft's HarperV were so late to the market. They basically owned the market at the time. Oh, yeah. They still do in some corners. Yeah, they still massively do in these places. They still exist. And so 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. It 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. databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite

make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. 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 cloud formation from scratch without pulling up some reference somewhere, because most people don't have that stuffed into 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 5,000 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 I've ever written. I don't think it's up anymore. When I was at iCloud Guru, it was 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 10 people and you get a thousand CVs or resumes for those 10 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 certified, thousands, millions of people 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 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 DevLounge at reInvent. 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 that'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's only paying a little money to

you. I used to work at a web hosting company. The $3,000 a month customers were great to work with. The $29.99 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 handholding someone needs. The more money someone spends, the less hand-holding they need generally. But the other side of it, what most 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. Udemy is a perfect example of

that. People who have hundreds of Udemy courses they've never done, but they spend 10 bucks on each. So there is 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, they're 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 you know, those folks don't feel bad because they only spent 10, 20 bucks on it. It's like, that'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. Like 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've 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. 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 cheaper, smaller courses. And how do you find that quality as well? That's the other side of it. And also people will just trade on 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. 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 need 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 a skill of teaching right there.

But curriculum development is usually not the same thing. And when you're bootstrapping, learning, I'm gonna 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 even 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 something out 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 can search for anything, the only way to really find

out if something's 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 the 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 that 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 CloudGuru. I think when we were in 2015 and we had problems with Lambda and you got a 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 it, who was the former head of product on Lambda. But it was painful, and in general, you don't want to do it. Whenever AWS comes out with a new product, I've done it a few times where I 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 of what I thought it would be. I basically went, while the keynote was on, I logged in to my 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 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 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 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 like i don't want to blame the product teams too much there that's don't build something as a finished glossy product when it's not picture that where it is hey 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 does not live up to the billing, the harp 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 harp that they promoted 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 reInvent release is a whole separate series of arguments. There are very few substantial releases throughout the year, and then they drop a whole bunch of them at reInvent. 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.

Yeah, that's exactly it. What do I want to bury? Whenever Adam Solipski gets on stage and starts talking, great, then it's time to push the button on the we regret to inform you dance. Yeah, exactly. Microsoft will announce yet another print spooler bug. No way. 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, at IamStan. That is a place for outrage, yes. Your Twitter user account is? My Twitter user account's all over the place. It's probably about 20% serverless. So yeah, at 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. 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 folk after this. I'm waiting for you to say hi, as I always do. So yeah, that's probably the easiest place to get a 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, and they'll find me. Thank you so much for taking the time to speak with me. I appreciate it. Cheers, people really need me and they'll find me. Thank you so much for taking the time to speak with me. I appreciate it. Cheers, 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. 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.