Episode #67: The Story of the Serverless Framework with Austen Collins (PART 2)

Without the open source community, without the blessing of our investors, I don't know how big the framework would still be today. But that was what we focused on back then. It was instrumental to the growth and the scale that the framework has right now.

Absolutely, I'm glad you brought that up. That was something that I think on one end, the hallmark of a great developer tool often is how extensible it is. But a lot of this just came out of the fact that I started as one person, and I couldn't take on this massive project just being one person in the early days. Those people who've had things go viral on Hacker News, I think they've probably been through a similar experience where one day this project is just blowing up, but the next day the hangover sets in when you look at the issues on GitHub and people say this project does not support my use case, this does not support my workflow, this does not support my organization's policies. On top of that, the ambitious goal of trying to abstract essentially so many AWS services, it was like, how is this ever going to work? That's where plugins came from largely. You honed right into it. People can actually just overwrite any part of the framework, extend it, and it's up to them to figure out what the right patterns are. Once we see those emerge, then we'll just merge that into the framework. So it was a lot of outsourcing product development to some extent, but it all goes back to the fact that we didn't have the resources to do all that in the early days. It's great that's where creativity comes from a lot of the time, it's just limitations.

Yeah, absolutely. I totally agree with that. Constraints are super important. Also, I gotta say, the amount of use cases that people were trying to use serverless for, especially in the early days when it really wasn't meant for it, was just so amazing to me. People would try and duct tape together crazy serverless architectures to accommodate a use case it clearly wasn't ready for. There's so much creativity in that area. It seemed pretty crazy, but people love those serverless qualities: auto scaling, never pay for... only pay-per-use, and massive scalability. People want that so bad. The fact that so many people were doing this, and they still do it a lot today because there's still not even great serverless database options, it's just the stuff that people are doing to get around that. The DynamoDB movement right now, the popularity and all that, I think a lot of it is due to the pent-up demand that is just waiting for the cloud to become more and more serverless and offer more and more service options for all use cases. I saw that early on and I'm just thinking, everybody wants this. This is going to be table stakes for the cloud. This is not a fad. This is the next... this is cloud 2.0, or that's cliche to say, I hate saying that, but this is the evolution of where cloud... it's 3.0 now, I think we're already getting towards 3.0.

Yeah, absolutely. We had built out such a groundswell of a user base, it was time to start looking at how to do that. We had tried a few minor experiments, like, what does commercialization look like for us? We even went into infrastructure as a service at one point. We had a project called the Event Gateway, which I'm still a huge fan of. I think that the serverless era of service compute, event-driven compute, where it's never been easier to write code that reacts to events, I think there's room for a better type of event gateway or event bus that really takes a lot of API Gateway concepts and merges it into a new type of infrastructure. That's what the Event Gateway was seeking to solve. But it was hard to market an event gateway that ran on servers from a company called Circles. A lot of interesting conversations were had about all that certainly. It ultimately just kind of became a distraction from building the framework and stuff. We were just doing too much stuff at the time. Organizations' efforts thrive or fail depending on where you set the focus. So we decided to continue to focus on the framework and just build out the other later stage application lifecycle management features that you need. The challenge that kicked off the framework in the early days was this distributed system challenge, where there's just all these pieces you have to compose together. That's not just a development challenge, that's a monitoring challenge, a team workflow challenge, a secrets management challenge. It really presents a lot of new problems for every single phase of building and managing your app. So that's where we came out with Serverless Framework Pro. Our goal is just, if you're using Serverless Framework, we know you want to focus on product, we know you want to focus on the outcome. We're going to try and set up monitoring for you, we're going to try and set up secrets management for you, we're going to try and set up CI/CD for you. We're going to use the knowledge of the application that you've created with our framework to try and do all that for you without any configuration, without you having to figure that stuff out. So that when you deploy with the framework, you're ready to go into production from day one, and teams don't have to go figure this stuff out. All teams should have to do is just say use Serverless Framework, and that in itself will put all the guardrails, all the observability you need in place. So again, you don't have to think about that stuff, because that's what serverless is all about, not having to mess around with all this and then of course maintain it, which is the harder part. It's easier to build some DIY thing, but the maintenance is always the hardest part.

Yeah, and that's been very successful for us. It's been great. We're shipping features every single day to make that easier. We've got a lot of next generation tools that have been in the works for a while that we've been releasing lately, a lot of cool stuff that just extends on that theme of don't focus on the infrastructure, focus on your product. There's a lot of interesting stuff happening in the cloud right now. It's such a fascinating space. Personal predictions, might be way off here, but this is where it seems to be going and it's been my personal conviction since 2015, since Lambda came out. It does seem like serverless qualities are just going to be expected for all cloud infrastructure. When you log into AWS, Google Cloud, Azure, you're going to see all those services have more and more serverless qualities. It almost feels like serverless is just merging with the cloud and that'll just be cloud. I don't even know if there will be a serverless term anymore, it'll just be what we think of exactly what the youngins think of the cloud in the future. They'll be like, what is the serverless thing? That's really interesting to watch because that's important for us because we're trying to build the tools for that. If all of cloud is going to have these qualities and everything's going to become serverless, it's an interesting opportunity. The other stuff that I see that's really interesting is how code is taking a second seat in this architecture, like it's not the primary thing. It was Paul Johnson who wrote this at one of his many awesome serverless articles, and I totally agree. I see this all the time where the people working on these serverless architectures are doing more configuration these days than just code. Then you've got people coming out in the serverless community saying, of course code is a liability, all that stuff. That's really interesting because so much of our development tools are designed around code first and code is the most important thing. Meanwhile, here's this new architecture saying, well you put in code where you need it, but then you want to try and lean on stuff that you don't have to maintain over time and rework. So I think this fundamentally disrupts the workflow and the tools at the end of the day. That's been a very interesting space for our company to think about. We've got a lot of innovation that we're just starting to ship out and a lot more later this year on those themes. Then of course, with serverless just becoming the cloud and everything kind of being serverless at some point, you get a lot of complexity.

Completely agree. That's really where the Serverless Framework, that's where we've always been thinking. Going back to that simple story of functions and events, when this thing happens, run this logic. It should be that simple, and it's certainly gotten pretty complex. This is kind of the side effect of the cloud becoming more serverless. It seems like there's just a lot of stuff too that we just didn't see coming at the end of the day, like Layers, like Provisioned Concurrency, like the RDS Proxy or something. Ideas, products, it's like, well yeah, I understand serverless, but wow, there's a lot more services than you ever anticipated here. Meanwhile, the biggest companies still are having trouble securing their S3 buckets. So what does it all mean? How do we create simplicity here? Again, go back to just how do we bring order to this and make it accessible? Because on the other hand, this is highly efficient, very powerful next generation cloud infrastructure. Our team believes that these are the greatest building blocks of all time. Shelves filled with every single type of API to do almost anything. I think it could usher in a new golden era of software development. It feels like we've already been in one for a while, but this stuff is just so darn powerful. But again, how do we make that simple for people? For us, it's really just continuing our story of abstraction. We started out with the simple story of functions and events, don't think about the infrastructure, just think about your outcome first. Now we've got more serverless infrastructure possibilities, configuration options, all that stuff. But it's very clear that specific use cases are more popular than others, and specific use cases should for the most part be done serverless almost all the time. It depends on your organization, some people still need a greater degree of control over the serverless environment, the infrastructure, all that. But there's just very clear use cases where this is a great fit, and you have to have a pretty good argument for not just spinning up a serverless API right now, because it's just so darn efficient. We see those and we know what the best practices are because we've been building these for a while. To some extent, we're kind of asking ourselves, just like you shouldn't be managing servers, should you really try and figure out how to build a REST API on serverless infrastructure from scratch, or where is the ready-to-go REST API opinion that has the best practices built in, the best combination of infrastructure from a scale and performance perspective?

From a cost perspective, so developers don't have to think about that. They just think, 'I need to deploy an API, I need to deploy an Express app, for example.' That abstraction story is what we continue to focus on with our new effort, which is Service Framework Components. It's our fastest growing effort right now. We basically honed in on the most popular use cases and we're building out specific developer experiences for each one. Our goal is to do a 10x better developer experience, so we're trying to get them to deploy in three seconds or less. When you're working on these cloud services, you should be developing on those cloud services. You shouldn't have to emulate this stuff locally. A lot of people find deployment too slow. No one wants to wait 30 seconds or a couple of minutes for CloudFormation to deploy just to see a single line of code change in the cloud. That's crazy. So most people go back to emulation, which is easy to start, but then as your team grows and the project grows, I've seen so many companies trying to maintain some crazy emulated version of AWS that they do all their development on, which is impossible. I'm still trying to keep score: are we being more productive with this architecture or not? What are the issues? If people are trying to maintain a local version of AWS, then it feels like we're losing a lot of the creativity and productivity that was supposed to be freed up by outsourcing the infrastructure to the cloud provider in the first place. So we've looked at these popular use cases and we're trying to create one Service Framework Component for each use case, with developer experience features like fast deployments. Serverless Express is a good example. If you're a developer, you just want to deploy Express in a way that's auto-scaling, can scale massively out of the box, and charges you three cents per request. You just want to take your Express app and run it like that. The Express component is perfect for you. It packages your Express app on serverless infrastructure with three-second deployments. There are other cool features: it streams your logs and errors directly into your console, and there's a dev mode where it watches your code and every time you hit save, it does a fast deployment and streams log statements and errors. A lot of what we're doing with the new development experience is trying to recreate the experience that developers had before serverless cloud infrastructure. We're trying to make it as if you're running this Express app on your machine again. You can still do that, but we want to make working on the cloud just as fast as working locally. We think for developers to use all these new infrastructure features, they need to be able to develop on them, not do some fake thing that they then push into production and encounter all these limits and issues because they weren't working in the reality of the infrastructure. Components is a huge effort. We have one for websites if you want to deploy a serverless website, highly efficient Express, scheduled Lambdas, one for Next.js, React applications, event-driven ones, different webhook handlers, and components for running on other vendors as well.

Yeah, absolutely. And there's more. What we're doing with components is we've been working in the land of infrastructure as code and infrastructure provisioning for a long time. Every single problem you raise is a real problem that needs to be addressed. It can be addressed by really powerful templates that you can run on your own infrastructure, that your team can use as opinionated patterns so they don't have to figure out how to put all this stuff together. Everybody's going to do that wrong the first time. I don't think I've seen a team that gets it right the first, second, third, or fourth time. Eventually they might get it right, and then re:Invent comes around and says, 'No, there's a new way to do this now.' You don't want your team doing a lot of that low-level stuff. With abstraction, it's a battle between convenience and control. Not every abstraction is going to work for every company. There are a lot of different types of users and use cases. Components are coming out with a ton of different flavors at different levels of abstraction. We want to go after those serverless architecture diagrams we see on Twitter, showing all that stuff. We're trying to take all 20 of those things and put them into one piece. Then the other 20% will still be some low-level pieces, but for the most part, you don't need to go and use every single low-level thing and configure it yourself anymore, unless you just love doing it. For me, I personally have a ton of APIs I deploy. I don't want to think about low-level API Gateway stuff anymore. I have hundreds of endpoints now for doing all types of things. It's crazy to want to think about that low-level stuff. Going back to the theme, we've been thinking a lot about infrastructure as code for a while. In our opinion, there's so much room to innovate here. It dawned on me when I heard Adam from Chef giving a presentation on Habitat. He had this quote: you should try to figure out how to package more automation with your application. More use case automation should come out of the box. It inspired me to start thinking about how we package more automation with these components. Infrastructure provisioning as we think about it is just deploy, remove, roll back. Very simple. But there should be more automation capabilities built in. The interesting thing about components is that we try to focus on the outcome of the use case first, which is enlightening when you're building a developer tool. When you know the goal of the user, you can automate way more for them. For example, when you deploy a component, it's going to have metrics instrumented for it in our dashboard. If you deploy Serverless Express, those metrics are going to be the ones that matter most for that use case. It's not just low-level Lambda function invocations. It's showing you your API requests, because if you're building an Express app, you want to see your API performance overall. That's what the customer is facing. Each one of these components is starting to ship with its own custom metrics focused on their use cases, ranging from infrastructure to soon product metrics. These things are starting with a few components that have built-in testing functionality. Why should you have to rethink how to test an API? Components should be able to generate documentation for you. How do we help you think less about infrastructure provisioning and more about application automation? We use the knowledge of the use case and the end goal to automate so much more for the developer, so they don't have to think about that stuff. They just have simple actions: deploy, remove, test, monitor. We've just started that journey. Components went GA in April, and you'll see us announce a lot more on this front later this year. This all goes back to the theme of 'Build More, Manage Less.' The service needs to go ultimately in that direction.

Absolutely. It goes back to the question that serverless raises: when you don't think about the infrastructure, what do you think about? What matters most? Of course, the outcome, the product, the customer experience, the business problem you're trying to solve. That's the stuff you need to think about. It's still early for us here, but we want to answer that to a greater extent built into our tools. This is changing how we think of developer tools and what that really means, and ultimately who is a developer at the end of the day. I've listened to so many of your interviews with people at different parts of the space. You've got low code, front ends, serverless infrastructure. There's a convergence happening, an interesting movement. Where it's going to end up, I don't know. My personal theory is that the cloud has to focus more on outcomes, not on infrastructure. That's what you get when you go to AWS's serverless services: APIs as a service focused on outcomes, with business solutions that auto-scale and never charge you until you call their APIs. How that's going to change the tools, how we define a developer, I'm not sure what that looks like yet. But we have a lot of interesting ideas on what it means, and we'll continue to try building out some cool products to put some solutions out there.

I totally agree. It's the potential that's democratized for everybody, whether you're a large organization or a solo hacker in a basement trying to get something off the ground. This power is democratized to everyone. Going back to our mission, we want to help every single person build more, manage less, leverage higher levels of abstraction, and help them focus on outcomes more than ever. We're going to try to rethink developer tools and what that means in order to deliver that experience. The last part for us is we firmly believe serverless is bigger than any one vendor. We feel very strongly that there needs to be an application framework that provides an open, level playing field for serverless cloud infrastructure across any vendors. We've talked a lot about AWS, and the majority of our users are using AWS, but not all of it. Our users are very product focused. If you want to build the best products, you have to be free to use the best-of-breed services out there. We see a lot of people bringing in Stripe, Algolia, MongoDB Atlas, Twilio. There are so many great things out there. Helping developers have this open framework that treats all these things as neutral, a level playing field where they can compose service infrastructure across any vendor into applications really easily, feels like the destiny of the Serverless Framework to us.

Serverless.com. Pretty easy to remember, right? The infamous domain. That's where you can find us. I'm on Twitter @austencollins, A-U-S-T-E-N C-O-L-L-I-N-S. You can include that in the show notes.

Alright, thank you, Jeremy. Take care.