Severless Hero, Got Severs in His Eyes with Ant Stanley

Ant 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.

Announcer: 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.

Corey: This episode is sponsored in part by Thinkst. This is going to take a minute 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, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.

Corey: This episode is sponsored in part my Cribl Logstream. Cirbl 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 not only helps you improve visibility into what the hell is 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 in a company name. To learn more visit: cribl.io

Corey: 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.

Ant: 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.

Corey: 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?

Ant: 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.

Corey: 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.

Ant: Yeah, exactly. There are more Jeffs than women in the exec team if I remember correctly.

Corey: I think it’s now it’s a Dave problem instead.

Ant: 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.”

Corey: 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?

Ant: 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.

Corey: I love the Serverless Stack. They had a great way of building things out.

Ant: Yeah.

Corey: 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.

Ant: 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.

Corey: 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?

Ant: No, CloudFront Functions.

Corey: 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?

Ant: Yeah, exactly. And it’s bizarre. So, the CloudFront Functions thing, it’s based on Nginx’s [little 00:08:39] 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—

Corey: No one willingly uses or knowingly uses it.

Ant: 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—

Corey: 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.

Ant: Yeah, exactly. If you compare Amazon to Apple, Apple releases a net-new product once a year, once every two years.

Corey: 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—

Ant: Yeah.

Corey: —I can really think of is probably going to be AirPods, at least of any significance.

Ant: AirTags is the new one.

Corey: Oh, AirTags. AirTags is recent, which is a neat—but it’s an accessory to the rest of those things. It is—

Ant: 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.

Corey: 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.

Ant: 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.

Corey: 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.

Ant: And all these fun things. How are you’re going to test this, and how are you’re going to do all that?

Corey: 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.

Ant: Yeah. And they just love complexity. Have you looked at the second edition—so the third version of the AWS SDK for JavaScript?

Corey: 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.

Ant: 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.

Corey: But let’s face it, a lot of things grow organically.

Ant: Yeah.

Corey: 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.

Ant: 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?

Corey: They added two to get up to 16; one less than the numbers of ways to run containers in AWS.

Ant: 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?”

Corey: 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?

Ant: 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.

Corey: 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.

Ant: 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—

Corey: Oh, yeah. They still do in some corners.

Ant: 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].

This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking 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 asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.

Corey: 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.

Ant: 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.

Corey: 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?

Ant: 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.

Corey: Oh, teaching is very much its own skill set.

Ant: Oh, yeah.

Corey: 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.

Ant: 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.

Corey: 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.

Ant: 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.

Corey: 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.

Ant: Yeah, exactly.

Corey: And there’s nothing wrong with doing that, but it is obnoxious they’re not doing themselves favors here.

Ant: 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.

Corey: The whole re:Invent release is a whole separate series of arguments.

Ant: [laugh]. Yeah, yeah.

Corey: 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.

Ant: [laugh]. Yeah. That’s exactly it.

Corey: 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.

Ant: Yeah, exactly. Microsoft will announce yet another print spooler bug malware.

Corey: 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?

Ant: Twitter is probably the easiest place to find me, @iamstan—

Corey: It is a place for outrage. Yes. Your Twitter user account is?

Ant: [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 00:32:02], 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.

Corey: 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.

Ant: Yes, Corey. Thank you.

Corey: 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.