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

Episode Date: December 3, 2024

On this Screaming in the Cloud Replay, we’re revisiting our conversation with Co-Founder of Senzo, Ant Stanley. Ant sits down with Corey to do so. He offers up his history which has lead to his time as “Serverless Hero” to landing on the line that “serverless sucks.” Lend us your ears to see how that transition happened! Ant goes into detail on JeffConf (not the of the Bezos nomen), and working with servers and what to put where and why. Ant and Corey talk over the plague of AWS services where Ant offers his perspective how to trim the fat and keep things simple to make long-term objectives more attainable. They discuss the importance of training, the role of certifications for better and worse, and more. Tune in for his take!Show Highlights(0:00) Intro(0:51) Duckbill Group sponsor read(1:24) What does it mean to be an AWS Serverless Hero?(3:13) Why Ant and Corey are critical of the state of serverless(7:53) Woes with Lambda and CloudFront(10:12) The never-ending stream of new AWS services(13:36) Hurdles ahead of going serverless(17:33) Struggles of getting customers to understand a newly built service(21:31) Duckbill Group sponsor read(22:14) Pros and cons of certifications(32:17) Where you can find more from AntAbout Ant StanleyAnt Stanley is a community focused technologist with a passion for enabling better outcomes for society through technology. He is an AWS Serverless Hero, runs the Serverless London User Group, co-runs ServerlessDays London and is part of the ServerlessDays Global team. LinksA Cloud Guru: https://acloudguru.comhomeschool.dev: https://homeschool.devaws.training: https://aws.traininglearn.microsoft.com: https://learn.microsoft.comTwitter: https://twitter.com/iamstanOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/serverless-hero-got-servers-in-his-eyes-with-ant-stanley/SponsorThe Duckbill Group: duckbillgroup.com 

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. Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while, I talk to someone about, oh yeah, I 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 Duck Bill 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 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 A-Cli Guru. We were a serverless first company way back when. So from 2015 to 2016, I was with A-Cli Guru with Ryan and Sam, the two other co-founders. I left in 2016 after we'd run serverless comp. So I led and ran the first serverless comp.

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 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. 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 JeffConf 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 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 would 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 robotic 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 that are going to complain about it, but 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 service 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, what was it, 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. You know, 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. But 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, 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. 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, not a problem. And those two philosophies,

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 CodeParpline 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. 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 I 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 crazy. It's huge.

Version 2. And JavaScript's a very fast-evolving language. 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 years 2015, years 5, years 6 kind of level. So from 2015 to 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 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. They added 16. One less than 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. I'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, 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. 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 acquired Linux Academy, and then, plural site, 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-Cli 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-Cloud Guru actually started on Udemy, you will see tons of folks offering cloud courses at 10 bucks a pop. And then there's what I'm doing now, homeschool.dev, there's service focus 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 cost than ever before. 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 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 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 CardGuru 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 this place as 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. 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 $5 billion 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 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 cloud formations, 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 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. If you're going to hire 10 people and you get 1,000 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 if 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 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 hand-holding 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, you know, 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 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 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.

You know, I think when we were in 2015 and we hit 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. Like, 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, you know, 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, 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 want to blame the product teams too much there. Don't build something as a finished glossy product when it's not. Pitch it at where

it is. Hey, hey, we are building. 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 I am Stan. That is a place for outrage, yes. Your Twitter user count is? My Twitter user count's all over the place. It's probably about 20% serverless. So yeah, at I am Stan, 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 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, 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.