Screaming in the Cloud - Episode 18: Sitting on the curb clapping as serverless superheroes go by

Episode Date: July 11, 2018

What’s serverless? Are you serverless now? Is going from enterprise to serverless a natural evolution? Or, is it a “that was fun, now let’s go ride our bikes” moment? Is serverless ��just a toy?” Is it a wide and varied ecosystem, or is it Lambda plus some other randos? What's up with serverless vs. containers? Today, Forrest Brazeal is here to answer those questions and discuss pros and cons of serverless. He was a senior Cloud architect prior to joining Trek10. Forrest spent several years leading AWS and serverless engineering projects at Infor. He understands the challenges faced by enterprises moving to the Cloud and enjoys building solutions that provide maximum business value at a minimal cost.  Some of the highlights of the show include: Bimodality: Backend development going away and being replaced by managed services; undifferentiated items are being moved to the Cloud Serverless is application designs with “Backend as a Service” (BaaS) and/or “Functions as a Service” (FaaS) platforms; everything is managed for you AWS Lambda: Is it today’s trend or a bias that everyone is using it; Lambda makes up 80% of current FaaS adoption Serverless Ecosystem: You can build it however you want, and you’re doing it right; but don’t take that at face-value; no two Lambda environments are alike Cloud services at this scale have not been knitted together to form applications that are serving major workloads; best practices need to be established Native Cloud providers will consolidate, and individual frameworks will be created with components of application stacks tied together to build systems Serverless vs. Containers: No need for disparity - we can learn to get along; people use containers because it is easier than going serverless Serverless Heroes series features people thinking out-of-the-box and helps identify emerging trends; serverless is growing, and it’s not just about startups Went from working with a Sharpie to Procreate for the FaaS and Furious cartoon series; serverless component of process is for invoicing     Changes? Packaging to handle sharing; more knobs on console; unified process needed because too many building own workflow and tooling Certification: Proof-positive that you know what you’re talking about or is it questionable value if not backing up expertise in the real world? Links: Forrest Brazeal on Twitter Invoiceless Summon the vast power of certification - Dilbert cartoon Trek10 blog A Cloud Guru ThinkfaaS podcast A Cloud Guru - Serverless Superheros Why We’re Excited About AWS AppSync Serverless Architectures with Mike Roberts AWS Lambda AWS Serverless Application Model (SAM) Procreate AWS Certified Cloud Practitioner Serverlessconf Digital Ocean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist 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 week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as a managed service at

varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month,

so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It's click button or make an API call and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out.

That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Welcome to Screaming in the Cloud. My name's Corey Quinn. I'm joined this week by Forrest Brazil, who's a senior cloud architect at Trek 10. More notably, he's also fairly famous for his work with A Cloud Guru, both with the serverless superhero series and drawing the fast and furious cartoons. Welcome to the show, Forrest. Thanks for joining me. Well, hey, thanks, Corey. It's great to be here.

A pleasure. So historically, you have an enterprise background, which generally means relatively large, slow, sedentary companies, at least in the popular imagination. But your focus for a while now has been almost entirely in the serverless sphere. So is that a natural evolution? Is that a misunderstanding in what enterprises are? Or is that one of those, well, enterprise was fun, now let's go ride bikes instead style of transition? Sure. Well, I'm not sure most enterprises have a great understanding of what they are. So I don't think you can really go wrong, whichever way you go there. But I think what we're seeing in enterprises, and this is not original to me at all, but particularly in the IT departments, we've seen for a long time that there's this growing bimodalism. You've got your people that are on help desk, and they're answering the phones, and they're doing very basic, almost menial tasks. And then at the far end of the spectrum, you've got architects, you've got people that are

writing lots of YAML, and they are designing services and doing network design. And there used to be in the middle of all that, you'd have your basic mid-tier IT people that were Windows sysadmins and were clicking around in GUIs. And those people made up the backbone of particularly enterprise IT departments for a long time. I would put a lot of DBAs in that category, application sysadmins, all that kind of thing. And what we're seeing now in the cloud, as I said, is this increasing bimodalism where that middle role is actually going away. There's no longer place for those people. And I think serverless is just the next step on that road for enterprises. And so this actually plays right into, if you read my interview I did recently with Joe Emerson,

he talks about that same bimodalism cropping up on the development side of the fence, right? Where you have your backend development going away, that's being replaced by managed services. And so instead you have sort of some very high level architects on one side, and then you have your front end developers, and there's just nothing in the middle anymore. It's all being managed, the boilerplate, the undifferentiated stuff is moving out to the cloud provider. So enterprises are seeing that they're taking advantage of it. It means, you know, frankly, they don't have to have as many people in the IT department, which is a huge win for them. But it also actually has some real positive consequences from a technical standpoint. When I first started working with serverless in the

enterprise, first started doing background jobs, then started working on internal applications, actually built an application that saved about a million hours a month of EC2 instance usage. And that was just running on a very minimal amount of serverless code. It was something we were able to build in about a week. So once you start showing the enterprise that you can have these kinds of results with a very minimal investment of time, minimal investment of labor, that becomes very, very compelling because they're used to these terrible, terrible waterfall deployment cycles where things spend six months in development, they go over the wall to QA, and that train leaves the station, and then nobody can touch it except for application people who are terrified of the code and don't ever want to touch anything.

So being able to shake that up and go serverless absolutely has positive effects on the enterprise, and I'm seeing more of that now as I'm in the consulting space and working with even more folks who have these kind of problems. Gotcha. Let's back up for a second there for those who may not have been paying attention for the last 20 minutes of cloud development. What is serverless? Well, you know, first and foremost, it's a terrible name. So, you know, we've been arguing about this for years. It's the folks that have been doing serverless are sick of having this argument.

But frankly, we bring it on ourselves by continuing to use the name. So, yes, we get it. There's servers and serverless. Essentially, I like to look at serverless kind of the way Mike Roberts does. He has a great article on martinfowler.com about this where he kind of divides serverless into two categories. You've got your FAS, functions as a service, services like AWS Lambda. So that's probably what most people think of when they think of serverless. But he also puts into that category backends as a service. So that would be things like Firebase. It would be things like AWS AppSync and the various services that plug

into that to make it an integrated solution like DynamoDB. So what is not a serverless solution will be something like Google App Engine, something like Heroku. And the reason for that, the reason we don't call those systems serverless, is because you are responsible for telling those services, this is how much compute I want, this is how much I pay for, I'm paying for it all the time, it's provisioned whether I'm using the service or not. So there's no concept of functional billing, and you're stuck with that compute

all the time. So serverless, ideally, is everything's managed for me. I'm only paying for compute when it actually runs. And that certainly would include AWS Lambda as the primary harbinger of that. Gotcha. To that end, when you talk about serverless, Lambda is the first thing that comes to mind as far as platforms go. Do you see that that is a larger trend across the ecosystem today? Or is that just my own bias speaking at this point? No, I think the latest number I saw was Lambda makes up something over 80% of current FaaS adoption. And everybody else is fighting for scraps.

Azure, Google, IBM with their OpenWhisk platform. And part of this, too, is there's a lot of people that want to be running something like Kublai, so they want to be running OpenWhisk in their data center. So they're not really doing serverless. They like to say that they are, but in reality, they're just running a layer on top of a container orchestration system. So in terms of people that are truly doing serverless, Lambda is where it's at. The reason for that is Lambda got a huge head start, right?

They've been out since 2014. They were way ahead of the whole ecosystem on this. They saw clearly what the play was. They jumped into that. And so they've built up the tooling around it to the point where if you're using Lambda, you're not just getting a rock solid platform that has basically solved the distributed bin packing problem, as Tim Wagner likes to say, Tim Wagner being the GM over Lambda. But they've also plugged into that analytics,

and they've plugged in various kinds of databases, especially with Aurora serverless now coming out. They've plugged in everything else in that ecosystem, machine learning. And so you can feel confident that you're not just getting some functions that are going to perhaps solve the happy path or the easy use case, but they're going to hang you out to dry when it really counts. AWS has really backed up the Lambda play with the ancillary services that you need as a consumer to build the applications you want, but also that they need to make money off of it, right? Because let's be honest, serverless is kind of a loss leader from a function perspective. They get you in there so that you can use the services like Dynamo and others that actually make money for them. It's like you're looking over my shoulder at the variety of different things that I wound up building over the course of history. One of the

interesting parts about the serverless ecosystem today is that they say, you can build this however you want and you're doing it right and that's fine. So I took that at face value and then built out some things that power a variety of nonsense that I do and showed it to some of the AWS people.

And their response was, yeah, when we said you could do whatever you want, we really didn't think about you when we said that. So it turned into a bit of a eye-opener as far as the way that I think about things and the way that the rest of the industry tends to do not often align if for no other reason than I'm a dangerous fool. So while it's interesting seeing my nonsense juxtaposed with what other people are doing, what's more interesting is seeing how other people who are doing this seriously tend to fall into very different use cases, very different patterns. It almost feels like no two Lambda environments are alike. Would you agree with that?

I absolutely would agree with that. There's been an attempt over the past couple of years, especially once API Gateway came out, which was really what turned Lambda into a viable platform for applications. There's been a lot of attempts to put frameworks around the serverless concept. Serverless framework, formerly JAWS, of course, being the most famous, but there's others out there, Apex Up. AWS has their own extension of CloudFormation now called SAM, the Serverless Application Model, which I really like a lot for AWS-specific use cases. And the reason those frameworks come out is that people are struggling to make sense of all these options, right? Because you're fragmenting so many things that you used to be able to think about all in one package.

I think one of the things that we are really missing in the serverless space, and this is not even an AWS thing, this is just the industry broadly, is this is an extremely new concept, right? You see people saying it's just CGI scripts, or it's just something we've seen before. And what they're missing is we haven't really seen at this scale, all these different cloud services being knitted together to form applications that are serving major production workloads. And because of that, there's not a lot of best practices around this. So you have a lot of people diving in headfirst, and they're solving these problems as they go. The services are immature, they're getting better, but they're immature. The best practices are non-existent. The tooling around it is not there. So it's up to us as a community to acknowledge

that, to put the time in and put the work in to establish these best practices and then to really educate. The education barrier for serverless is huge. It's not just about the technologies being different. It's about your workflows being different as developers. It's about a comfort level from ops folks and from security folks all the way up to the top of the business. So the advantages are real, but we have to get out there and help people understand how they can get where they need to be without just getting lost in a morass of pain and agony, because I've seen that happen too. In fact, I've experienced that, and that sounds like you maybe have as well. Absolutely. I mean, for example, I tend to focus on using the serverless framework. You tend to

prefer using SAM. Other people would say Apex, Chalice, Architect, or a half dozen others. And the consensus for best practices that has rapidly emerged is that everyone else is doing it wrong. How do you see this starting to solidify as the industry evolves? I think that there's two distinct components to this. And this is where we get into the question of multi-cloud. So I think that the individual serverless providers are really doubling down on their ecosystem providing a lot of value. That's why you see AWS providing services like SAM, the serverless application model, because they believe that their value-add is not just in Lambda, it's also in all the

things that plug into Lambda. And I'm sure Azure would say the same thing, and the other cloud providers. So in that sense, they would argue, and in many cases, I would argue that you're not getting the full benefit of serverless if you try to take perhaps the least common denominator from a bunch of different clouds and knit them together into some sort of hybrid serverless monster. But at the same time, the fact of the matter is some of these providers are far ahead of each other. For example, I would say that Google Cloud has done some really innovative things with the AI stuff, with natural language processing, even with some of their database services that AWS has lagged a little bit behind on.

So if you are able to isolate different parts of your stack and you're able to place those on different clouds, then there's some value in having a framework that ties those together. So short answer, too long, didn't read. I think we're going to see native cloud providers consolidating, but we're also going to see individual frameworks that are taking components of a application stack, the analytics component, let's say, the compute component, the data component, and you're going to see them tying those together

so that you can build a system that meets the latency requirements that it has to, but also gets the best of all possible worlds. But I think we're a ways out from that. And just to be clear, a single cloud is hard enough to learn. Multiple clouds, frankly, I only know of a few people who are effectively utilizing multiple clouds today. The education barrier just grows by leaps and bounds. So we're nowhere close to this being real. Those people tend not to sleep a lot either. No, no, I, they tend to drink a lot of coffee, uh, or something. Last question before we change another topic, uh, what's up with this whole serverless versus containers thing? Yeah. So, uh, you know, I think this gets back to the enterprise part of the conversation. Uh, there's, there's a much trumped up trumped up discussion and perhaps animosity between folks

that are building heavily in production on containers and folks that are using a lot of serverless technologies. And obviously, I think that there's no real need for disparity there. I think we can learn to get along. But the reason I think that a lot of folks are using containers is it's a much easier transition for them. Coming from the enterprise context, you've got these large monolithic applications. You want to be in the cloud, you want to be well-architected, and it's a lot easier to say, okay, well, we can pick this up, and we can put it on Kubernetes, and it'll run. And it takes away a level of management overhead that we used to have. So we feel like we're getting some benefit here, but it's a much smaller step for us to move in that direction. Whereas serverless, yes, involves tearing apart everything that you have and learning new workflows and starting over.

And I think the benefits can be a lot more radical, but obviously the upfront costs and time invested are going to be more radical too. So it's not an easy decision necessarily, especially if you have a lot of time and people invested in older ways of doing things. So I think that's what's going on there. I don't expect that tension to go away anytime soon, but we'll see what happens. Very fair. Let's move on to another topic, specifically the Serverless Heroes interview series that you run over at A Cloud Guru. First and foremost, why haven't I been on the show yet? Well, frankly, Corey, you just haven't asked. I mean, that's really the biggest thing.

So what I'm hearing from you is you need to get on the schedule and work that out. But I'd love to have you and just let me know. Historically, I've always been someone who sits on the curb and claps as real heroes go by, but we'll see what happens. Why not? Remember, you get nothing you don't ask for. So given that you're speaking to more or less everyone who's doing everything in the nascent serverless field, you have a pretty good perspective to see the trends that are emerging in this space. What are you seeing? You know, I think there's a few things. And I try to be careful about the serverless bubble, right? There's a very small percentage of people in the industry as a whole that are using these

technologies. And so we can get into a little bit of an echo chamber. So I try to make sure I'm talking to folks who are thinking outside the box and coming from different types of backgrounds. And so that includes people in large enterprises, people that have startups like Joe Emerson. On the enterprise side, I've talked to folks like Michael Garsky at Fender, which that interview is not out as of the present, but it'll be coming out shortly. And, you know, there's kind of a common theme that has emerged from all these people, which is that they're just moving so much more quickly with serverless than they were before. It's almost kind of an awe in their voices. That doesn't mean these are people that aren't still having problems. Obviously, every one of these people has their own set of serverless war stories,

that gets back to the best practices discussions that we've been having. But overall, these people with one accord, I think are saying, I'm never looking back. And these are people, again, that are using these technologies in production today. They're using them at scale. So these are not toy projects. These are serving requests at web scale or whatever that means today. So, you know, I take their word for it that they're actively happy with what they're doing. I've also talked to some folks that are a little bit more in the consultant or thought leader kind of space, which I don't think any of those people would prefer to be known first by that name. I try to talk to people that are doers that actually have... Oh, speak for yourself. You can email me at cory.thoughtleader.guru. No, I'm not kidding. And yes, and I believe you're a doer as well.

But anyway, the folks that are actually doing stuff in this space, but I talk to people that go around and see a lot of these deployments, both successful and failed. And what I'm getting from that overall is that this is a space that is growing. It's not just about startups. I think people have a perception that, well, if I'm an enterprise, I've got a lot of legacy code that serverless is not for me. And that's absolutely not true. We're seeing that if you go in and maybe you take almost like a startup-sized project inside of an enterprise, you build out a tiger team and you go after something,

you can actually see enough value quickly enough that it drives excitement throughout the enterprise as a whole. So this is the trends that I'm seeing emerge as I talk to different people throughout the space. I do talk to folks that aren't just AWS. I've had Azure Functions product manager on the series. I've talked to Kelsey Hightower, who's a developer advocate at Google. And all of those folks have similar perspectives. So again, it's beyond just one cloud provider. This is something that's happening in the industry as a whole. make them? And when I say, how do you make them? I'm not meaning, how do you come up with jokes? Frankly, people would love to know the answer to that and then send me to whatever class teaches that because mine are terrible. But what does your production workflow look like for getting cartoons into, I guess, a digital space? Sure. So when I first started doing Phasm Furious, the original title was Cloud Blazers. I was doing them on my personal blog. This was like three

years ago. I was literally just drawing them with a Sharpie marker and scanning them in on a scanner. It was just something fun to do when I was bored at work. But after they moved over to A Cloud Guru, I got an iPad and I'm using a program called Procreate to do them now, which I love. It's easy to draw, they're easy to color, and they look a lot better. At least they look better than drawing them with a Sharpie marker. Actually, I have a bit of a serverless component to the process, and it's related to my invoicing. So I've open sourced that part of the cartoon workflow. You can find it if you search for a project called Invoiceless on GitHub. So if you have recurring invoices you send out for something and you want to use Lambda and SCS and CloudWatch to do that for you, you're welcome to use that process. That's how I invoice

the cartoons. But it's definitely something I enjoy and I keep my ear close to the ground. So if you have a great idea for a Fazz and Furious cartoon, let me know. I'll try to work it in. Absolutely. This solves the problem beautifully of my having no artistic ability whatsoever, which is fantastic. Getting a little bit back to the idea of the dominant serverless platform today being Lambda, API Gateway, and the things that are tied to that, if you had a magic wand, what would you change about them? You know, I think obviously Lambda has come a long way since it was inaugurated, and a lot of the pain points with it are things that the LAM team is well aware of. I know that they're working on.

One thing that I think just continues to be really tough is the whole packaging aspect, particularly if you're not using Node.js. If you're using something like Python, getting your serverless functions into a format where you can zip them up with NumPy and SciPy and all the other things that come along with Python. It's really tough.

Trying to work that into a CICD process is rough. We wind up seeing people doing things like committing large packages to source control, third-party libraries, which obviously is not a best practice. And yes, there are ways around this. Serverless framework has some plugins that make this a lot easier. But the fact of the matter is, as long as it's not supported in the native tooling,

it's going to be rough. And this gets into a little bit of a broader issue around kind of code organization. How do I organize my serverless functions? How much code do I include in a function? Do I have one giant mono repo and all of my functions use the same code base? Do I split it out and have different code make my packages smaller? Just not a lot of guidance around this. People flail at this a lot. And so we're kind of veering here between things that the service could be doing and just needs for better education. But I really do think that there's a place here for the Lambda team to step in,

make it easier to load certain libraries in the runtime natively without you having to ship them as part of your code package, perhaps making a shared library space available so that you can put code out there once, perhaps have an S3 or somewhere, and then have multiple functions that hook into it so you don't have to ship those libraries that you've written as part of every single function's deployment package.

So that would be a big thing around that whole area. And then, of course, you always want to see longer runtimes, bigger code package sizes, more disk space, more memory. And the Lambda team has given some of that to us already. The memory sizes are a lot bigger. I also would like to see maybe a couple more knobs on the console. Right now you have one knob for memory and CPU together. And I understand why they don't want to increase that too much, because the whole point of Lambda is you don't really know what's under the hood. It's just a single dial you turn and you get compute whenever you need it. But you wind up with people trying to reverse engineer this stuff and do weird things to keep functions warm.

So either you have to give more transparency or you have to accept some of those limitations. And I think people have made it clear that they love Lambda, they want to find new things to do with it, and they're not satisfied with where things are. Something that's emerged that I've noticed is I've had a client or two ask me about, oh, you're using a bunch of Lambda functions. Why don't we just crib from your deployment process? And they were very happy with what I did until they asked a fun question such as, okay, that's great. What if a second person needs to work on it? And my response was, oh, never do that. That would never work. Why would you ever have more than one person working in your company? And then I realized I've gone off the deep end again.

It's almost like every person that I've met who's doing extensive work in this space has been building their own workflow and their own tooling around it for a little while. There's a definite sense from my perspective that there needs to be a unified process unless you want to spend the first week of a new hire getting them up to speed on your specific unicorn deployment methodology. Right. And this gets right back to what I was saying about the need for well-defined best practices in this area. And there's things that AWS can do that don't involve making changes, obviously, to the services, getting some more quick starts out, some reference architectures. They've got some of that. I'm working on some stuff in that space right now. So keep your eyes

peeled on the quick starts for some help there. But really what's going to help this is just more people getting into the serverless space and more voices added to the discussion. The people that are doing serverless today, by and large, they're, you know, I'm going to use this term with heavy air quotes around it, but they're 10x developers. They're people that are early adopters. They're on the cutting edge. They're the kind of people that will go and play with stuff and they'll build stuff. stuff, even if all of the tooling isn't there and there's 20% missing features just because they're excited about it and they figure, well, I can paper over any gaps that are there because I love writing glue code and this is all going to be awesome. But the reality is that then you

wind up with a bunch of solutions where everyone has its own 20% of special sauce, and that's not going to be viable long term. So I think it just involves more people getting involved, more people saying, hey, I'm not going to use this until it meets a standard that's a little bit more settled down. And, you know, I think that's already happening. It's only going to continue to happen. We are we're way ahead of where we were six months ago, 12 months ago, 18 months ago. And I expect that trend to continue. It's moving in the right direction.

Absolutely. I think from my perspective, at least, it feels like serverless today is either a toy or it's being used to spackle over feature gaps in AWS offerings natively. And I suspect that today there might be a bit of truth to that. I don't believe that will be the case

a couple of years from now. I think we're going to look back at what we're dealing with today in a similar way that we do with EC2. If you take a look at EC2 10 years back, doing anything with it was like pulling teeth. You had an entire cottage industry that sprung up around

making it understandable to a human. Today, two or three clicks, and you have an EC2 instance or a thousand EC2 instances, and you're not having to go slog through very low level configuration details. It feels like Lambda is following a similar maturity curve. I have no doubt that it will. I love Simon Wardley's frequent comparisons of the reactions to Lambda and then going back and putting them side by side with the reactions to EC2.

It's sort of that first they ignore you, then they laugh at you, then they fight you, then you win kind of thing. And I think we're somewhere between fighting and winning on the serverless side in terms of it being a viable technology that's really being embraced by the industry as a whole. But as I said, we're way ahead of where we were. And I would actually take a little bit of issue with the statement that it's just a toy or it's being used to paper over gaps. I mean, I think there's people that have that perception, but especially as I've gotten more into the interview series I've been doing for A Cloud Guru and talking to people like Rob Gruhl at Nordstrom and Michael Garsky at Fender Digital. And of course, Netflix has a whole

range of serverless capabilities. It's really more about the quality of your engineers, and folks are doing really incredible things. What's really going to mark the maturity of the service, though, is not when it's just being used for toy things, but when it's being used for serious things by people that are not at the very cutting edge of adopting every new technology that comes out, but when it's just seen as something boring, basically. Once Lambda becomes a boring technology, that's when it's really going to get adoption. The grown-ups, as it were, people with serious regulated workloads where if they mess things up, people die or the ATM starts spitting

out 20s. Well, yes. But again, I don't want to imply that those type of folks are not using Lambda today. They absolutely are. And in fact, some of those folks are the ones using Lambda most heavily. You can look up what Capital One is doing as an example of a banking company that is really heavily into serverless, into DynamoDB, into tools like that. But yes, we're going to start picking up those enterprises on the back half of the adoption curve. Absolutely. And please don't think that I'm implying criticism of these folks. I want companies that do banking and healthcare to have a little bit more rigor to their engineering process than, well, I wrote this code at three in the morning. It's awesome. Probably I'm too

tired to tell to production with it. There needs to be something that gates code and enforces a level of maturity before some things make it to production. Not everything needs to be fail fast, iterate quickly like a typical startup would. I don't think that there's anything inherently wrong with a company today that is not investing in serverless. It is not a panacea that solves all problems. Well, that's exactly right., again, coming from the enterprise background where definitely the tendency is to err on the side of things taking forever, I do appreciate moving quickly. One of the great things about serverless, and several people have mentioned this, is that it allows you to try a bunch of different prototypes. There's really very low cost of failure. So you're

able to go through and, you through and say you're not sure exactly which of three ideas is going to work. You spin them all up in Lambda. It's easy to A, B, C, D, E, F, G test something when that infrastructure is only being paid for while it's being used. So it's easy to do things like blue-green and phased rollouts and canary deployments. All of that becomes very cost-effective with Lambda. And, of course, the other services that would be involved in that type of a stack. So there's really no barrier to people going out and being innovative and trying stuff with these services.

It takes you a while to catch up with your legacy applications and folks need to go out and get training. You're absolutely right. That's going to take time. There's no rush per se, no immediate rush, but I don't think there's any benefit to sticking your head in the sand because ultimately you are going to get lapped by the folks that are taking the time to level up and invest in their people and take advantage of these technologies. Absolutely. Could not agree with you more. A personal question for you. In your official biography, you talk about your master's

degree, you talk about the work that you're doing with A Cloud Guru, and of course with Track10. And then at the end, you throw in that you're an AWS certified solutions architect, professional grade. Where do you stand on the idea of pointing at a certification as proof positive that you know what you're talking about? It struck me as a little odd because you are a known person in this space. And generally, past a certain point, there's a segment of our sector that looks down on certifications. How do you feel about it? Well, yes, you say official biography like you picked my authorized biography off a shelf somewhere. I think you're referring to my blurb on the Track 10 website.

Well, you don't want to know what the unauthorized biography has to say about you, I assure you that. Well, that's why it's unauthorized, right? But yes, so I definitely agree with you about certifications being of questionable value if they're not backing up expertise in the real world. I love the Dilbert cartoon where the guy is talking about, I summon the vast power of certification. And it's faintly ridiculous that that would be expected to do any good in that scenario. But, you know, if you work for an MSP, which I do, you know, there's value in certifications because it relates to your relationship with the provider. So that's why that's on my Trek 10 bio. From a larger perspective, yes, your work speaks for itself.

And if you don't know what you're doing, no certification is going to make the difference. But I don't have any inherent problem with people getting certifications. I have more than one. I've gotten some value from them, and I'm not going to say anything bad about them. Yeah, I tend to be a little bit on the other side where I don't tend to have virtually any professional credentials. That said, a couple of months back, I sat for the Cloud Practitioner certification for AWS, which, for those who are unaware, is their entry-level certification that presupposes about six months of having worked vaguely with something in AWS.

And my reasoning behind that was not because I'm going to use that to lend legitimacy to who I am and what I do. I have none of that. Rather, at reInvent and other AWS events, there's a certification lounge that has comfy seats, snacks, coffee, and access to power. So I view it as a lounge fee with a really weird entrance questionnaire. Well, that's fair. And I guess it's just all about what sort of status you're seeking. So if you've found something

that makes the certification desirable for you, then I think you should go ahead and get it. But you shouldn't get the certification just to have it. I mean, that's the rationale for any degree too, right? I have a master's degree in computer science, which is one of the weirdest degrees you can hold because it doesn't map onto any particular job. It's not like a bachelor's degree where a lot of software engineering jobs, for better or for worse, rightly or wrongly, are looked at as an entrance requirement.

It's not like a PhD where it maps onto things like data science and very specific types of jobs. Master's degree is just very much in the middle. I did that because I love to learn and wanted to continue to working on some things that I wasn't really getting exposed to in my day job. So I don't regret that at all. I'm really proud that I got the degree, but I don't look at it as something that makes me better than people that have been working in the space for years and have a lot of experience. It's a very different thing. Exactly. I tend to reserve the I'm better than you credentials for frequent flyer status, as most right-thinking people tend to do. Absolutely.

In other news, we're going to be appearing shortly at Serverless Conf in San Francisco. I'm looking forward to that. Can you give us a sneak peek of what you're going to be talking about? Yeah. So I'll be doing a number of different things at Serverless Conf this year. So definitely come and say hi if you're out there. But one of the things I'll be doing is a talk with Jared Short. We will be actually looking at some different personas within a large organization or enterprise, large or small, that may have trouble getting on board with serverless adoption. Because I think a lot of folks that come to Serverless Conf are already excited about serverless, right? They're coming because they want to know more about it. And they're going to learn all these great ideas.

And they'll say, okay, well, how can I go back and take this to my organization, take this to my boss who's skeptical and take this to the architect who's got concerns about vendor lock-in? How can I take this to the sysadmin who's kind of a server hugger and says, well, if I can't adjust my TCP window size, then it's a no go for me. And how am I going to talk to the developer whose workflows are being disrupted? And of course, most importantly, how am I going to deal with that person on Hacker News who just reflexively hates serverless for all reasons and no reason? How am I going to get past them

in order to actually get a serverless project off the ground in my company? So we'll be talking about that. We've got some tried and true things that we've used working with clients and working in our roles. And we hope you'll enjoy it. Absolutely.

I'm looking forward to seeing it myself. Where can people find you? Where can people observe the majesty that is your work? Well, without confirming or denying anything implied in that statement, you can certainly find me on Twitter at Forest Brazil. I do work for Trek10. So you can look up my blog post there at trek10.com.

Trek10, of course, is a AWS managed service provider. We do a lot of serverless projects. We help all sorts of clients, large and small. So if you have that kind of a problem and you need some expert advice, we would be more than happy to talk to you. And then I hope you'll check out my writing at A Cloud Guru as well. Corey mentioned the serverless superhero series over there. And I also draw that

Fast and Furious cartoon series. So definitely check that out and let me know if you have any serverless war stories that you would like me to share. Perfect. Thank you so much for taking the time to speak with me today. Absolutely. It was a pleasure, Corey. And I look forward to seeing you at the AWS Summit in New York. Indeed. My name's Corey Quinn. This has been Forrest Brazil, and this is Screaming in the Cloud. This has been this week's episode

of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.