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

About Austen Collins
Austen Collins is the founder and CEO of Serverless, Inc. Austin is an entrepreneur and software engineer located in Oakland, CA. His specific focus is on building cheap, scalable Node.js applications while minimizing DevOps requirements as much as possible. An enthusiastic AWS Lambda user from day one, Austen founded the Serverless Framework (formerly JAWS), an open source project and module ecosystem to help everyone build applications exclusively on Lambda, without the hassle and costs required by servers. 

• Serverless, Inc.: https://www.serverless.com/
• Twitter: https://twitter.com/austencollins

Transcript

Jeremy: Yeah. And I mean, I think that was one of the things that I thought was amazing about how you took the approach to the community, because it was very much so a community driven project. And I think that helped to have AWS who is also very much so like what do they call it? The leisure paths or whatever it is when you basically create paths in a college campus by letting people walk and then you pave over the dirt or whatever it is. I can't remember the name of it, but anyways, that idea of letting people sort of decide where it's going to go and how it's going to develop. And I always remember there being a delay, because there had to be between the framework supporting something new that AWS just came out with.

And whether that be and again, I'll use a bad example, but like maybe it's a new event that it supports. And I remember every time that came out that there was always it seemed like there was a lot of debate, a lot of pull requests and conversations about how to abstract that piece of it and fit it into the existing framework. Right. And so you developed this entire plugins community around the framework too, which was really great because that was the other thing. And that has been one of the things that I've had challenges when I work with SAM is that you don't have the ability to build plugins. So you essentially have to write a separate Lambda function that just does a module or whatever they call it there that allows you to do something, a custom resource.

But with the framework, you just had that ability to write that, to do things that you to do, to extend it, to fill gaps that you may have had during a certain amount of time until the framework supported it. But I always appreciated that more so after the fact, sometimes I was a little frustrated that there wasn't support right away. But after the fact to say, I liked the fact that you took the time to think it through because abstractions are the hardest thing to build and when you do it wrong and then you're married to it forever you know what I mean? It's really hard to change that. So that was one of the things I always liked was that it was the framework doesn't support this yet, but build a plugin and it can, and then you can always deprecate the plugin and then accept whatever the valid way is or I guess the established way that the framework does it.

So I just thought that was a really good approach. And I think really helped with all these people contributing because then also you saw plugins that came up and you're like, we should support that in the framework.

Austen: Yeah, absolutely. I'm glad that you brought that up. That was something that I think on one end the hallmark of like a great developer tool often is how extensible it is. Right. 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. And those people who've had, like things go viral on Hacker News. I think they have 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 in 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. And then on top of that, the ambitious goal of trying to abstract almost essentially it's just so many AWS services. It was like, okay, how is this ever going to work? And that's where plugins came from largely, and you're right, 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. And 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 all goes back to just the fact that we didn't have the resources to do all that in the early days and it's great. That's where creativity comes from a lot of the time. It's just limitations.

Jeremy: Actually. It's funny you mentioned limitations because that's the other thing... This has been an ongoing theme with serverless too, is that you do have to work around some of these limitations, but sometimes that's not a bad thing, right? Sometimes when you have constraints, you can build something better because you can't just go and do something crazy, like say, well, we're going to set up a K8 cluster because we want to do some type of processing over there. If you ask yourself, how can I do it within these constraints? Not only is it usually faster, it's a lot cheaper. And oftentimes I think you'd get a better product out of it.

Austen: Yeah, absolutely. I totally agree with that. Constraints are super important. And also, I got to say the amount of stuff, 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. And it seemed pretty crazy, but it's just people love those serverless qualities. Auto-scale, only pay for 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, right.

The stuff that people are doing to get around that, the DynamoDB movement right now, the popularity and all that I think is 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 serverless options for all use cases. And that's really I saw that early on and I'm just thinking like, everybody wants this, this is going to be table stakes for the cloud. Again, this is not a fad. This is like the next... This is cloud 2.0, that's cliche to say, I hate to saying that, but this is like the evolution of where-

Jeremy: Cloud 3.0 now I think we're already getting towards 3.0. So 2016, 2017, 2018 you're working on building a community which you did an amazing job of. And I know you hired a few people. I know Alex DeBrie, for example, a ton of growth hacking, which is just brilliant by the way. So if you just take your serverless hat off for a second and go back and look at how you built this company and how you built this community, it is like a masterclass in how that worked. Now, I know I'm sure you made a lot of mistakes along the way, like you said, for every one success, there's 100 failures behind you. But again, it was the persistence. It was the approach to it. It was hiring a bunch of great people. And like you said, having some really, really great people working for you and working on the project that I think got it to the success. But now we get into 2018, maybe towards the end of 2018, 2019, you've got to turn this into a company at some point, like a real company.

Austen: Yeah, absolutely. And we had built out such a kind of groundswell of a user base. It was time to start kind of looking at how to do that. And we had tried a few kind of minor experiments on like, okay, 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 still am a huge fan of that project. I think that the serverless era, era of serverless compute, a venture in compute, were again, it's never been easier to write code that reacts to events. I think that there's room for a better type of event gateway or event bus that really takes a lot of API gateway concepts and kind of merges it into a new type of infrastructure there. And that's what the event gateway was seeking to solve. But we were still-

Jeremy: But it was hard to market an event gateway that ran on servers from a company called Serverless.

Austen: Yeah. A lot of interesting conversations were had about all of that certainly. And it ultimately just kind of became a distraction from like building the framework and stuff. We were just doing like too much stuff at the time and organizations efforts thrive or fail depending on where you set the focus.

And so we decided to continue to focus on the framework and just build out the other later stage life cycle application life cycle management features that you need. So the challenge that kicked off the framework in the early days was this distributed system challenge, right, where there's just all these pieces you have to compose together, and that's not just that only exist on the cloud too, so distributed system where you don't own most of the parts.

That's not just a development challenge, right? That's a monitoring challenge. That's a kind of a developer, a team workflow challenge. That's 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 and our goal is just, hey, if you're using Serverless Framework we know you want to focus on product. We know you want to focus on the outcome. Like 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 CICD for you. And 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.

Austen: And so that when you deploy with the framework, you're ready to go into production from day one. And that 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 guard rails, all the observability you need in place. So I think, again, you don't have to think about that stuff because that's what serverless is all about, right. Not having to mess around with all this, and then of course maintain it, which is the harder part, easier to build some stuff, some DIY thing, but then maintenance is always the hardest part.

Jeremy: Right. Well, and just stitching everything together too, and understanding how X flows to Y through Z and all this kind of stuff, it just gets really, really complicated. So yeah, the Serverless Framework Pro is great. I've been playing around with it quite a bit. Again, the CICD stuff is awesome. And if anyone has ever set up CICD for serverless and I have a sort of a running joke in my newsletter every week where every time I see someone's set up for CICD and serverless, I always make a joke, here's like the 10000th way to do CICD in serverless.

And again, model repos versus multi repos and all that kind of stuff. And the framework supports both those, as well as I like the model repo approach where it can grab just one modified serverless.yml file and deploy that section of the framework and some of those things. The monitoring is great. The alerts are great.

Jeremy: So definitely if you are using the Serverless Framework, I am a big fan of what you've done from the commercialization piece. And I think again being a little bit selfish, I want to see the framework keep going. And you can't run a company if you don't have revenue, right. You can't just always be building community. So I think it's great that people are using that and they're benefiting from that and they want those extra features. It's a great way to not only take care of the things you really need, but also to continue to support your company and the framework that I think is what really made serverless very accessible to most people.

Austen: 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, of course, focus on your product. And there's a lot of interesting stuff happening in the cloud right now. I mean, it's just such a fascinating space. I think personal predictions might be way off here, but this is where it seems to be going. And it's kind of 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.

Right. And when you log into AWS, Google Cloud, Azure, you're going to just you see all those services have more and more serverless qualities. And so it almost feels like the 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-

Jeremy: Exactly.

Austen: What the young'uns think of the cloud in the future, right. They'll be like, "What is this serverless thing?" And so that's really interesting to watch because that's important for us because we're trying to build the tools for that. And 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 is really interesting is I think how code is thinking a second seat in this architecture, they're kind of like, it's not the primary thing.

And I think it was Paul Johnson who wrote this at one of his many awesome serverless articles. And he wrote this 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. And then you've got people coming out in the serverless community saying of course code is a liability, all that stuff. And 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 like, well, you put in code where you need it. Right. 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. And that's been a very interesting space for our company to think about. And we've got a lot of innovation that we're just starting to ship out and a lot more kind of later this year on kind of those themes. And then of course, with serverless just becoming the cloud and everything kind of being serverless at some point you get a lot of complexity that comes out of that.

Jeremy: I was just going to jump in there and talk about complexity, because that is one of the things where, right from the beginning I remember it being so easy. And some of those Hacker News comments, by the way, very early on like, "Oh, we already have this, they're called cgi-bins." Which of course it's not a good comparison, but you know what was great about cgi-bins? You upload a little bit of code and it was available on the web and it ran and it was amazing. And that was how serverless started very easily was sort of like, you just upload a snippet of code. You don't have to worry about setting up servers, all this other stuff, it runs something for you, does something and it's done, and that's it. You don't have to think about it. You have to set up the servers, you don't have to any of that stuff.

Then we added API gateway and then we added RDS or VPC, so you could do RDS and ElastiCache. And then you started having all these issues with connection management, because the connection management or the connection model between those were broken. And so you had to start playing games and then cold starts got worse. And then they're like, "Hey, let's support Java." And you're like, "Okay, well now the cold starts are really bad." And so you had all of these things that just started adding more complexity, SQS Queues, SNS, EventBridge. You start adding all this stuff in and you get to the point where you look at... And I remember there was an article that was like your typical serverless infrastructure. And it was like 40 different services all tied together. And people were like, "This doesn't seem simple, blah, blah." It's like, "Well, it's not simple, right?" It has become very, very complex. And you've got all these patterns that have come out of this in terms of how you handle different use cases.

And so I know you agree with me on this. This complexity of serverless has taken some of the shine off of it. And we need to find better ways that we can start focusing less on the actual code and the infrastructure and more on what we're trying to achieve or the outcome of it.

Austen: Completely agree. And that's where the Serverless Framework, that's where we've always been thinking, right. Going back to that simple story of functions and events. When this thing happens run this logic, right. It should be that simple and it's certainly gotten pretty complex, and this is kind of the side effect of the cloud becoming more serverless. And it seems like there's just a lot of stuff too, that we just didn't see coming at the end of the day. Layers like, provision concurrency, like database proxy, like RDS proxy or something.

Jeremy: RDS proxy, yeah.

Austen: It's like, well, I understand servicefull, but there's a lot more services than ever anticipated here. Right. Meanwhile, the biggest companies still are having trouble securing their S3 buckets.

Right. So yeah, what does it all mean? How do we create simplicity here? And again, going back to just like, 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. And myself, our team, we believe that these are the greatest building blocks of all time. Right. Just to have all these things shelves filled with every single type of like API to do almost anything. Right. I think it could usher in a new golden era of software development. I mean, 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? So for us, it's really just continuing our story of abstraction.

Right. And again, we started out with a simple story of functions and events. Don't think about the infrastructure, just think about kind of your outcome first. Now, we've got more. Now, there are 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 for the most part, somethings just should be done serverless almost all the time. Depends on your organization. Depends on some people still need a greater degree of control over their service environment and the infrastructure, all that, but there's just very clear use cases where that 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.

So we see those and we know what the best practices are because people we've been building these for a while. And to some extent, we're kind of asking ourselves, well, just like you shouldn't be managing servers, should you really try and figure out how to build a rest API on service infrastructure from scratch or where it's just like, they're ready to go, rest API opinion that has the best practices built in, the best combination of infrastructure from a scale performance and cost perspective. So developers don't have to think about that. They just think about, I need to deploy an API. I need to deploy like an express app, for example. And so that abstraction story is what we're continuing to focus on with our new effort, which is Serverless Framework components, which is our by far fastest growing effort right now where we've basically just honed in on those most popular use cases.

And we're building out specific developer experiences for each one of those use cases. And our goal here we want to do like a 10X better developer experience. So each one of these, like we're trying to get them to deploy in three seconds or less, right? Because we think that when you're working you're on these cloud services you should be developing on those cloud services. You shouldn't have to emulate this stuff locally.

And a lot of people just deployment is too darn slow, right? No one wants to wait 30 seconds to a couple of minutes for cloud formation to do a deployment in order to see their single line of code change in the cloud, that's crazy. So most people go back to emulation and then unfortunately that's easy to start, but then a lot of teams, your team grows, the project grows, the types of services grows. And I've seen so many companies trying to maintain some crazy kind of emulated version of AWS that they do all their development on.

Jeremy: Which is impossible.

Austen: Yeah. And I'm still personally trying to keep score. I'm like, are we being more productive with this architecture or not? What are the issues here? If people are trying to maintain a local version of AWS, then it feels like we're losing a lot of that creativity and productivity that was supposed to be freed up by outsourcing the infrastructure to this cloud provider in the first place.

So anyway, we've looked at these popular use cases and we're trying to create one Serverless Framework component for each use case with other developer experience features like Fast Deployment. So Serverless Express is a good example. If you're a developer, you just want to deploy Express in a way that's auto-scaling, in a way that can scale massively out of the box and charges you 0.00003 cents per request.

You just want to take your Express and run it like that. Then the Express component's perfect for you, just put in your Express app and package it on serverless infrastructure for you. Three-second deployments and there's other cool features. It streams your logs and errors directly into your console. You've got like a dev mode where it just watches your code every time you hit save. It does a pass deployment, streams, log statements, errors, and a lot of what we're doing to be frank with all this new development experience stuff is trying to recreate the experience that developers had before serverless cloud infrastructure. Right? So we're just trying to make it as if you're running this Express app on your machine again, which you could still do, but we want to make working on the cloud just as fast as if you're working locally, because we think developers for serverless to use all these new infrastructure features you got just work on those.

Be able to develop on those, not do some fake thing that you then push into production and encounter all these limits and issues because you weren't working in kind of the reality of the infrastructure at the end of the day. So components is a huge effort here. We've got one for websites who want to deploy a serverless website, highly efficient, Express, scheduled Lambdas. We've got one in the works for Next.js. Also if you want to deploy React applications, we've got event-driven ones in the works, different web hook handlers, and then components for running on other vendors as well.

Jeremy: Right. Yeah. And I tell you, what I love about the idea of components is again, it's almost as simple as saying like, "Okay, I just need this to happen when something else happens." And there may be multiple connecting pieces, but here's my piece of business logic that I need to write. And there are a lot of companies now that are doing these sort of low code workflow systems, right. And I think Paragon, Pipedream, like there's a whole bunch of them. And they're very cool because they say, look, you want to send something to Twitter or you want to read something from a Google Sheet or you want to query a database or do something. Those are all pre-written and done for you, but then it's like, well, but I need to randomize it and add some prefix to it or something like that.

Well, that's a little piece of code that I have to write. And I like that level of abstraction, but I don't necessarily like how it's owned in someone else's infrastructure in the sense where I don't quite have full control over it.

So what I like about the components is that it gives you the ability to do that and own it, but still have a lot of that extra instrumentation sort of have done for you. And the thing that I think is overlooked maybe from this idea of components and any of these sorts of things is it's about repeatability, not just for something small, like, "Oh, I need to just publish a new website, or I need to publish a new API." It's something like we are an enterprise and we have all of these security requirements.

We have all of these bootstrap stuff that needs to be done. All of this instrumentation that has to be written in order to do observability and monitoring and making sure we're following PCI and all these other things, right. You've got this whole long list of things that has to be done every single time. You give somebody a blank template and just do serverless init, right? I mean, that's not going to give you enough in order for you... I mean, do you have to go through quite a few iterations before you get something that is going to pass muster with the lawyers and compliance and all that kind of stuff. So being able to encapsulate that, right, which is why I've rethought the CDK a little bit, because I like that idea of writing these reusable components that you can just plug in together and use these constructs.

And the serverless components feels very much the same way to me. And I like that because I think when you start talking about new organizations needing to build out complex applications that are compliant, that have all the security that they need in there, that have passed all the security checks and all of the sign off from everybody involved. That this is the way, this is the level of abstraction that will allow you to do that, be really productive. And again, go serverless, which I can't imagine anybody now sitting down thinking about building a new application and saying we shouldn't at least look at the serverless piece first.

Austen: Yeah, yeah. Absolutely. And then there's more because what we're doing with components is we've been in the land of infrastructure as code, infrastructure provisioning for a long time. And every single problem that you raised absolutely is a real problem that needs to be addressed, that can be addressed by really powerful templates that you can run on your own infrastructure that your team can use as opinionated pattern. So they don't have to go figure out how to put all this stuff together because everybody's going to do that wrong the first time. I don't think I've seen a team that's put together-

Jeremy: And the second time and the third time and the fourth time, and then eventually they might figure that right.

Austen: And then you get it right and then re:Invent comes around and says, now there's a new way to do this. Now, you've got to do this. Right. In my opinion you don't want your team doing a lot of that stuff. Right. Doing all the low level stuff.

With abstraction, as we all know, it's this battle between convenience and control, right. And not every abstraction is going to work for every company. There's a lot of different types of users out there and use cases, it takes all kinds to make a world. But components were coming out with a ton of different flavors at different levels of abstraction. And we want to go after those darn serverless architecture diagrams, right. That we see going around on Twitter which they're just showing all of that stuff.

And all we're trying to do is say, yeah, we're going to take all 20 of those things and we're just going to put them into one piece. Right. And then you'll have 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. And then there's nothing wrong with it. Right.

But for me I personally have a ton of APIs I deploy. Right. There's a ton of them. And I don't want to think about low level API gateway stuff anymore. I mean, I've got hundreds of end points now for doing all types of things. And it's just crazy to want to think about that low level stuff.

But again, going back to kind of, there's more here. We've been thinking a lot about infrastructure as code for a while. And in our opinion, there's so much room to innovate here. And it dawned on me when I heard, I think it was Adam from Chef. He was giving, I think it was a presentation on Habitat. And he had this quote here where he said, you should try and figure out how to package more automation with your application. More use case and automation should just kind of come out of the box. And it's really inspired me personally to start thinking about like, okay, how do we package more automation with these components? Right. Because infrastructure provisioning, as we think about it, it's just kind of deploy, remove, roll back, very simple.

But there should be more automation capabilities kind of built in. And the one thing that's interesting about components is that we try and focus on the outcome of the use case first, which is so enlightening when you're building a developer tool. Because you know the goal of the user and we know what the goal of the user is, you could automate way more for them. So an example of this is when you deploy a component, it's going to have metrics instrumented for it in our dashboard now. Like if you deploy Serverless Express and those metrics are going to be the metrics that matter most for that use case. It's not just going to be low level, here's in AWS Lambda function in vocation, right. It's going to be first, we're showing you your API requests, because if you're building an Express app, you want to see your API performance overall, because that's what the customer is facing. Right?

So each one of these are starting to shift with their own custom metrics that are focused on their use cases, ranging from infrastructure and then soon product, right? Like what are the product metrics that really matter for this? These things are starting, there's a few components that have built in testing functionality. Why should you have to rethink how... You learn how to test an API at the end of the day. Components should be able to generate documentation for you, all this stuff. How do we really think less about infrastructure provisioning and more about application automation and pack and use this knowledge of the use case, the end goal to really automate so much more of that for the developer.

So they don't have to think about that stuff. They just have simple action. Each component has simple actions, deploy, remove, test, monitor all that stuff. So we've just started that journey. Like components is still new. We went GA in April, but you'll see us announce a lot more on this front later this year. But this is all going back to the theme of build more, manage less, right. Where we think serverless needs to go ultimately.

Jeremy: Well, I think that idea of the use case or the outcome is really cool. And I love the idea of having the metrics built in. Indulge me in this story for a second. I thought it was hilarious because I was at a company and we had just set up dashboards or the monitors in our office so that we could have these big dashboards up. And it was because the CEO said, hey, we want to numbers up on those. Right. So especially like when investors come in, they can see whatever. And I said, "All right, well, what do you want to put up there?" He was like, "Well, I want to put up our KPIs." Of course, key performance indicators. And I said, "All right, what are those?" He's like, "I have no idea."

So I think there are a lot of people who are going to be in that boat like all right now I'm building a serverless application. And if you abstracted away enough where I'm just entering a little bit of code, just doing my little business logic here, then the question becomes, what do I even care about? Right. Because I don't need to monitor CPU on my Lambda function anymore. Like that is just done by AWS for me. But what do I really want to know? Do I want to know the latency of my routes? Do I want to know the frequency of my routes? Do I want to know my error rates? Some of these other things that would show me something that's actually actionable, but how am I supposed to know those things unless you have a lot experience. And any of that experience that you can just bring and sort of fold in there automatically, if anything it just gives you something to build off of.

Austen: Yeah, absolutely. And it kind of goes back to the question that serverless raises that is, when you don't think about the infrastructure, what do you think about? What matters most? Well, of course the outcome, the product, the customer experience, the business problem you're trying to solve. That is the stuff you need to think about. So it's still early for us here, but we want to answer that to a greater extent built into our tools and this is all just kind of changing how we think of developer tools and what that really means.

And then ultimately like who is a developer at the end of the day too? Because you can see and I've listened to so many of your interviews already with a lot of stuff with people just in different parts of this space, you've got like low code, you've got front ends and then you've got serverless infrastructure.

There's a convergence here kind of happening. There's an interesting kind of movement here happening where it's going to end up, I don't know. My personal theory though, is that the cloud, everything is going to have to focus more on outcomes, not on infrastructure. And that's what you'll get when you go to AWS, just serverless services, API as a service focused on outcomes where we've got business solutions, instant business solutions that auto-scale and never charge you until you call their APIs. And how that's going to change the tools, how that's going to change how we define a developer. I'm not sure what that looks like yet, but we've got 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.

Jeremy: That's awesome. I mean, I remember sitting down at breakfast at re:Invent with Ajay Nair and he asked, how do you describe serverless? Or like something to that effect. And I said, serverless is just the way, that's just where we're going. Right. Like it's just going to be cloud 2.0 or 3.0 or whatever revision we're on. But I totally agree. I mean, this is one of those things where it does take a lot of convincing sometimes when people look at containers and they're like, "Oh, I have all kinds of control over it."

And it really goes down to this level of abstraction and we get I think distracted by things like cold starts and vendor lock-in and all these other things. And yeah, maybe not all of those things are perfect.

But if you think about something as simple of a use case as catching a form from a website to serving up an entire API, to processing millions and millions of records coming in via Kinesis or something like that. Or converting files, performing OCR on medical records. I mean, all of these use cases now are there and they're supported and they're not all perfect, but it's getting to a point where I just can't imagine my life right now without serverless. And again, I don't know, like you, I just get really excited about it because I think about the possibilities and I think about where this is going and if we get it right, if we continue to build those right levels of abstraction, and continue to convince people that again, it's the way, I think the future of this is pretty amazing.

Austen: Totally agree. It's the potential that's democratized for everybody, whether you're a large organization, or you're just a solo hacker, like in the basement or something, trying to get something off the ground like this power has democratized everybody. And that going back to our mission, like, yeah, we want to help every single person build more, manage less, leverage higher levels of abstraction, help them focus on outcomes more than ever. We're going to try and rethink developer tools and what that means in order to deliver that experience. And then the last part for us is just we firmly believe serverless is bigger than any one vendor at the end of the day. And 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, because yes, we've talked a lot about AWS and the majority of our users are using AWS.

And the majority of the infrastructure is AWS, but not all of it actually. They are still bringing out, our users, our audience are very product focused. And if you want to build the best products, you got to be free to use the best of breed services that are out there. And so we see a lot of people still bringing in Stripe, still bringing in Algolia, still bringing in MongoDB Atlas, Twilio, right? There's so many great things out there. And helping people, developers have this, again, this open framework where it treats all these things as neutral. This level playing field where they could compose serverless infrastructure across any vendor into applications really, really easy. It feels like the destiny of the Serverless Framework to us.

Jeremy: Yeah. Well, that's pretty awesome. And what else was awesome is you being here and sharing all this information. Again, I love that history. I think that's just amazing. I think again, like I said if you're building a service now or you're trying to build a company just how you've done it, how you've gone about it, and how that has grown. And also just the advice of listen, you're going to fail hundreds of times before you succeed. It's just the way that it goes. So again, thank you for being here and sharing all this information. And if people want to find out more about components and the Serverless Framework and where all that stuff's going, or just contact you how do they do that?

Austen: Serverless.com. Pretty easy to remember, right? The infamous domain, but that's where you could find us. I'm on Twitter, just Austen Collins, A-U-S-T-E-N though. And you can include that in the show notes or something like that but-

Jeremy: I will put it all in there. You have a great blog too: serverless.com/blog. Lots of great information in there. So thanks again, Austen. Really appreciate it.

Austen: All right. Thank you Jeremy. Take care.

Episode source