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?
Full Episode Transcript:
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’m going to argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as an added 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. Its click a button or making API call, and you receive a cloud resource. They also include very understandable monitoring and alerting.
Lastly, they’re not exactly what I would call small-time. Over 150,000 businesses are using them today. Go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try that. That’s do.co/screaming. Thanks again to DigitalOcean for their support to Screaming In The Cloud.
Corey: Welcome to Screaming In The Cloud. My name is Corey Quinn. I’m joined this week by Forrest Brazeal who’s a Senior Cloud Architect at Trek10. More notably, he’s also fairly famous for his work with A Cloud Guru, both with the Serverless Superheroes series and drawing the FaaS and Furious cartoons. Welcome to the show, Forrest. Thanks for joining me.
Forrest: Thanks, Corey. It’s great to be here.
Corey: A pleasure. 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. Is that a natural evolution? Is that a misunderstanding in what enterprises are? Or is that one of those, “Well, enterprise is fun. Let’s go ride bikes instead,” style of transition?
Forrest: 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—this is not original to me at all particularly in the IT department—we’ve seen for a long time that there’s this growing bimodalism. You have your people like a help desk, they’re answering the phones, they’re doing very basic almost menial tasks. Then far into the spectrum, you’ve got architects, you have people that are writing lots of YAML, they are designing services, and doing network design. There used to be in the middle of all that, you'd have your basic, mid-tier IT people that were Windows sysadmins. Some are clicking around in GUIs. Those people made up the backbone of particularly enterprise IT departments for a long time. I would put a lot of DPAs in that category, applications, sysadmins, all that kind of thing.
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. I think serverless is just the next step on that road for enterprises. If you read my interview I did recently with Joe Emison, he talks about that same bimodalism cropping up on the development side of the fence where you have your back-end development going away, that’s being replaced by many services. Instead, you have some very high-level architects on one side, then you have your front-end developers, and there’s just nothing in the middle anymore. It’s all being managed, the boilerplate beyond differentiated stuff, is moving out to the cloud provider. Enterprises are seeing that. They’re taking advantage of it.
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, I first started doing background jobs, then started working on internal applications, actually building applications that save 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 that we were able to build in about a week. 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.
There used to be terrible, terrible waterfall deployment cycles where things spent six months in development, they go over the wall to QA, that train leaves the station, and then nobody can touch it except for application people who are terrified of the code and don’t want to ever touch anything. So, being able to shake that up and go serverless absolutely has positive effects on the enterprise, and then seeing more of that now in the consulting space and working with even more folks who have these kind of problems.
Corey: Got you. Let’s back up for a second there for those who may have not been paying attention for the last 20 minutes of cloud development, what is serverless?
Forrest: First and foremost, it’s a terrible name. We’ve been arguing about this for years. 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 the way Mike Roberts does. He has a great article on martinfowler.com about this where he divides serverless into two categories. You have your FaaS—Functions as a Service—services like AWS Lambda. That’s probably what most people think of when they think of serverless. But he also put in that category Backend as a Service. 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.
What is not a serverless solution would be something like Google App Engine, something like Heroku, and the reason for that, the reason why 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 and paying for all the time, its 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.
Serverless ideally is everything is managed for me, I’m only paying for a compute when it actually runs, and that certainly would include AWS Lambda as the primary harbinger of that.
Corey: Got you. 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?
Forrest: No, I think the latest number I saw was Lambda makes up something over 80% of the current FaaS adoption and everybody else is fighting for scraps, Azure, Google, IBM, with their OpenWhisk platform. Part of this too is that there’s a lot of people that want to be running something like Kubeless or they want to be running OpenWhisk in their data center. They’re not really doing serverless. They like to say that they are but reality there they’re just running a layer on top a container orchestration system.
In terms of people that are truly doing serverless, Lambda where it’s at. The reason for that is Lambda got a huge head start. 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. So they 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 plugged in various kinds of databases especially with Aurora Serverless now coming out. Everything else in that ecosystem machine learning.
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. Let’s be honest, serverless is a lost 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.
Corey: 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, you’re doing it right, and that’s fine. So I took that at face value, then built out some things that power a variety of nonsense that I do and showed it to some of the AWS people. Their response was, “Yeah, when we said you could do whatever you want, we really didn’t really think about you when we said that.”
So it turned into a bit of an eye-opener as far as the way that I think about things and the way that the industry tends to, do not often align—if for no other reason—then I’m a dangerous fool. While it’s interesting seeing my nonsense juxtapose what other people are doing, what’s more interesting is seeing how other people who are doing this seriously, tend to fall under very different use cases, very different patterns. It almost feels like no two Lambda environments are alike. Would you agree with that?
Forrest: I absolutely would agree with that. There’s been an attempt over the past couple of years, especially once API gateway came out, which really what turned Lamba into a viable platform for applications. There’s been a lot of attempts to put frameworks around the serverless concept, serverless framework—formerly JAWS being the most famous, but there’s others out there, Apex Up, AWS has their own extension of cloud formation now called SAM, 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 because you’re fragmenting so many things that it used to be able to think about all-in-one package.
Corey: The idea that you wind up with different implementation patterns’ almost unique to a company and initially, it feels like you’re doing it wrong. And then you look into almost everyone’s doing it this way.
Forrest: Yes. I think one of the things that we are really missing in the serverless space—this is not even an AWS thing, this is just the industry broadly, this is an extremely new concept. You’ll have people come up to you and say, “Oh well, it’s just CGI scripts all over again," or, "It's just [...], something we've seen before," and 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.
Because of that, there’s not a lot of best practices around this. You have a lot of people diving in head first and there’s so many 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. It’s up to us as a community to acknowledge that, to put the time and to 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 technology is being different. It’s about your workflow is being different as developers. It’s about comfort level from ops folks and from security folks, all the way 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 into more asset pain and agony because I’ve seen that happen too. In fact, I’ve experienced that and it sounds like you may have as well.
Corey: Absolutely. For example, I tend to focus on using the serverless framework. You tend to to prefer using SAM. Other people would say APEX, Chalice, Architect or half-dozen others, and the consensus for best practices that is rapidly emerged is that everyone else is doing it wrong. How do you see this starting to solidify as the industry evolves?
Forrest: I think that there’s two distinct components to this. This is where we get into the question of multi cloud. 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, 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. I’m sure Azure would say the same thing, and the other cloud providers.
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 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’re able to isolate different parts of your stack and you’re able to place those on different clouds then there’s some value on 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 an 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 ways out from that. Just to be clear, a single cloud is hard enough to learn. Multiple clouds, frankly I only know a few people who are effectively utilizing multiple clouds today. The education barrier just grows by leaps and bounds.
Corey: The people tend not to sleep a lot either.
Forrest: No, they tend to drink a lot of coffee or something.
Corey: Last question before we change to another topic. What’s up with this whole serverless versus containers thing?
Forrest: I think this gets back to the enterprise part of the conversation. There’s this much trumped-up discussion and perhaps animosity between folks that are building heavily in production out of containers, and folks that are using a lot of serverless technologies Obviously, I think that there’s no real need for disparity there. I think we can learn to get along.
The reason I think a lot of folks are using containers is it’s a much easier transition for them, coming from the enterprise context. You 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, we can pick this up and we can put it on Kubernetes and it will run.” It takes away a level of management overhead that we used to have, so we feel we’re getting some benefit here but it’s so much smaller step for us to move in that direction.
Whereas serverless, you have some bolts, tearing apart everything that you have, learning new work flows and starting over. 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. It’s not an easy decision necessarily, especially if you have a lot of time and people invested in older ways of doing things. 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.
Corey: Very fair. Let’s go 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?
Forrest: Well, frankly Corey, you just haven’t asked. That’s really the biggest thing. What I’m hearing from you is you should need to be on a schedule and we’ll work that out. But I love to have you and just let me know.
Corey: 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. On a more serious note, given that you’re speaking to more or less everyone with some rounding errors, who’s doing anything notable in the entire nascent serverless field, what trends are you seeing start to emerge globally?
Forrest: I think the tough thing with the serverless community as a whole—because it’s very small, as you said, it’s a rounding error compared to the number of people that are doing application development today around the world—it can be easy to lose sight of that when that’s where you spend the majority of your time. It’s a vanishingly small amount of early adopters who were doing serverless today. There’s a risk of getting in an echo chamber. There’s definitely a bit of a serverless bubble and I’ve been trying to break out of that by talking to folks who come from non-traditional perspectives and have the different take on this.
But I am seeing some things emerge. One of them I’ve alluded to before which is, we’re really are seeing a lot of people that are just done with writing back-end code. They view code as a liability, they want to write code that differentiates their business and has value for them that no cloud provider is providing, but they also want to limit the number of people they have there doing that and the amount of time they’re having the spend so they’re relying on the cloud services for anything that they can. We’re seeing a lot of that.
A second trend beyond the fact that you have a lot people wanting to use back-end services, you’re seeing this container versus serverless trend that I alluded to before where you have people consolidating on either side.
Corey: Something else that you’ve been working on that’s impressive to those of us with no artistic ability whatsoever is your FaaS and Furious cartoon series. How do you make them? And when I say how do you make them, I’m not meaning how 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. What is your production workflow look like for getting cartoons into the digital space?
Forrest: When I first started doing FaaS and Furious, the original title was Cloud Blazers. I was doing them on my person blog. This was three years ago. I was literally just drawing them with a Sharpie marker scanning them in a scanner, doing just something fun to do when I was bored at work.
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 with a Sharpie marker.
I actually 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. If you have recurring invoices you send out for something and you want to use Lambda and SES 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 keep my ear close to the ground, so if you have a great idea for a FaaS and Furious cartoon, let me know. I’ll try to work it.
Corey: 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?
Forrest: 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 Lambda teams are 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 another JS. If 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 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.
This gets into a little of a broader issue around 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 codebase? Do I explode 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 we’re kind of veering here between things that the service could be doing and just need 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 in this part of your code package. Perhaps making a shared library space available so that you can put code out there once, perhaps having S3 or somewhere that 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. That would be a big thing around that whole area.
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 would also like to see maybe a couple of more knobs on the console.
Right now you have one knob for memory and CPU together. I understand why they don’t want to increase that too much because the whole point of Lambda is you don’t know what’s under the hood. It’s just a single dial your turn and you get compute whenever you need it. But you wind up with people who try to reverse engineer this stuff and do weird things to keep functions warm. Either you have to give more transparency or you have to accept some of those limitations. I think people had 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.
Corey: Something that’s emerged that I have noticed is I 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?” They were very happy with what I did until they ask a fun question such as, “Okay, that’s great. What if a second person needs to work on it?” 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.
Forrest: Right and this gets right back to what I was saying about the need for well-defined best practices in this area. 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 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—I’m going to use this term with heavy air quotes around them, 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 build 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 pay for 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 many 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 I think that it’s already happening, it’s only going to continue to happen. We are way ahead of where we were 6 months ago, 12 months ago, 18 months ago, and I expect that trying to continue. It’s moving in the right direction.
Corey: 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. 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 have 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 1000 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.
Forrest: 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. 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.
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 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 Garski at Fender Digital, and of course, Netflix has a whole range of serverless capabilities. It’s really more of 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 at the top of every new technology that comes out, but when it is just seen as something boring. Once Lambda becomes a boring technology, that’s when it’s really going to get an option.
Corey: 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.
Forrest: Well, yes, but then again, I don’t want to imply that those types of folks are not using Lambda. They absolutely are. In fact, some of those folks are the ones using Lambda most heavily. You can look up at 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.
Corey: Absolutely and please don’t think that I’m implying criticism with 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 3:00 AM. 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 is anything inherently wrong with a company today that is not investing in serverless. It’s not a panacea that solves all problems.
Forrest: 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—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 say you’re not sure exactly which of three ideas is going to work. You spend them all up in Lambda. You know it’s easy to ABCDEFG test something when that infrastructure is only being paid for while it’s being used. It’s easy to do things like Blue-Green, 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.
There’s really no barrier to people going out and being innovative and trying stuff with these services. It takes you awhile to catch up with your legacy applications and folks may 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 we are going to get lapped by the folks are taking the time to level up, invest in their people, and take advantage of these technologies.
Corey: 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 Trek10, 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 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?
Forrest: Yes, you say official biography like you pick my authorized biography off a shelf somewhere. I think you’re referring to my blurb on the Trek10 website…
Corey: Well, you don’t want to know what the unauthorized biography has to say about you. I assure you that.
Forrest: That’s why it’s unauthorized, but yes, 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 some of the best power of certification and it’s frankly ridiculous that that would be expected to do any good in that scenario. But if you work for and MSP, which I do, there’s value in certifications because it relates to relationship with the provider so that’s why that’s on my Trek10 bio. From a larger perspective, yes, your work speaks for itself and if you don’t know what you’re doing, no certifications is going to make the difference. But I don’t have any inherent problem with people getting certifications. I have more than one. I gotten some value from them and I’m not going to say anything bad about them.
Corey: I tend to be a little bit on the other side where I don’t tend to have 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 on AWS. 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 re:Invent and other AWS events, there is 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.
Forrest: That’s fair and I guess it’s just all about what sort of status you seeking. If you found something that makes the certification desirable for you, then I think you should go and get it. But you shouldn’t get the certification just to have it. That’s the rationale for any degree, too.
I have a Master’s degree in Computer Science, which is one of the weirdest degrees you can hold because it doesn’t map on to 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 that as an entrance requirement. It’s not like a Ph.D. where it maps on to things like data science and very specific types of jobs. Master’s degree is very much in the middle. I did that because I love to learn and wanted to continue working on some things that I wasn’t really getting exposed to in my day job.
I don’t regret that at all and 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 this space for years and have a lot of experience. It’s a very different thing.
Corey: 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?
Forrest: I think there’s a few things. I try to be careful about the serverless bubble. There’s a very small percentage of people in the industry as a whole that are using these technologies, and we can get them into a little bit of an echo chamber. I try to make sure I’m talking to folks who are thinking outside the box and coming from different types of backgrounds.
That includes people in large enterprises, people that have startups like Joe Emison. On the enterprise side, I’ve talked to folks like Michael Garski at Fender, which that going to be is not out as if the present that all be coming out shortly. 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 and that it’s back to the best practices discussions that we’ve been having. Overall, these people, with one accord, I think are saying, “I’m never looking back.” 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 that’s are web scale or whatever that means today. 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 actually tried to talk to people that are doers, that actually have—
Corey: Oh, speak for yourself. You can email me at email@example.com. No, I’m not kidding.
Forrest: And yes, I believe that you are a doer as well. Anyway, 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 and I’ve got a lot of legacy code that serverless is not for me,” and it’s absolutely not true. We’re seeing that if you go in and maybe you take almost a startup-sized project inside of enterprise, you build up a tiger team, and you go after something, you can actually see enough value quick enough that it drives excitement through the enterprise as a whole.
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 talked to Kelsey Hightower who’s a developer advocate at Google. All of these folks have similar perspective. So again, it’s beyond just one cloud provider. This is something that’s happening in the industry as a whole.
Corey: I tend to reserve the ‘I’m better than you’ credential for a frequent flyer status, as most bright-thinking people tend to do. In other news, we’re going to be appearing shortly at Serverlessconf in San Francisco. I’m looking forward to that. Can you give us a sneak peak at what you’re going to be talking about?
Forrest: Yeah. I’ll be doing a number of different things at Serverlessconf this year, so definitely say hi if you’re out there. 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, or large or small. They may have trouble getting onboard with serverless adoption because I think a lot of folks that come to Serverlessconf are already excited about serverless. They’re coming because they want to know more about it. 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? 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 windows size, then it’s a no-go for me,’ and how am I going to talk to the developer who’s workflow is being disrupted, and 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.
Corey: Absolutely. I’m looking forward to seeing it myself. Where can people find you? Where can people observe the majesty that is your work?
Forrest: Without confirming or denying anything implied in that statement, you can certainly find me on Twitter @forrestbrazeal. I do work for Trek10 so you can look up my blog post there at trek10.com. Trek10 of course is an 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 will be more than happy to talk to you.
Then I hope you’ll check out my writing at A Cloud Guru as well. Corey mentioned the serverless superhero series over there. I also draw that Faas 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.
Corey: Perfect. Thank you so much for taking the time to speak with me today.
Forrest: Absolutely. It’s a pleasure, Corey, and I look forward to seeing you at the AWS Summit in New York.
Corey: Indeed. My name is Corey Quinn. This has been Forrest Brazeal, and this is Screaming In The Cloud.