Episode #66: The Story of the Serverless Framework with Austen Collins (PART 1)

Thanks for having me, Jeremy.

Sure. Quick background on us. We make the Serverless Framework, which is an application framework that makes it really easy to build applications on serverless cloud infrastructure. That is infrastructure that's auto-scaling, you never have to pay when it's idle, and scales pretty massively. The goal is to help developers deliver software that has radically low overhead and all these surplus qualities at the application level as a whole. So that's our goal. We make the Serverless Framework, that's what we kicked off with. I was excited to chat with you because I was thinking it might be interesting not to do just such a technical conversation, which I'm sure you've done a handful of already, but maybe talk about the history of the Serverless Framework a little bit. The project is now five years old. I'm in my fifth year of serverless development, which is crazy to think about because it feels like we're so early in this journey in general. I was thinking it might be interesting to talk about the history of how things got started, how we got started, and our perspective of just kicking off the serverless movement and what that looked like in the early days. I don't think anyone knew how big of a deal this was potentially going to be or that this would have become a big category for cloud or maybe even the cloud itself. When you reached out to me to do this podcast, I thought this might be a great opportunity to tell that story, at least from our perspective, my perspective. I think it's a fascinating one not just for technical people but for makers and entrepreneurs, anyone who's trying to get something off the ground. I think there are a lot of interesting lessons learned along the way.

Yeah, okay, going way back. A lot of the credit first goes out to the Lambda team, the visionaries over there who basically disrupted how they do compute over at AWS. I've heard a lot about that story. I listened recently to your podcast with Tim Wagner talking about the early days of that. But really, a lot of what we're doing here with the Serverless Framework and building out our developer tool suite is just standing on the shoulders of the effort that those people did, which I'm sure was hard figuring out what that looks like inside of an organization as big as Amazon. So our story really, I'd say they did a lot of the hard stuff and a lot of the really meaningful stuff. My story starts right at when they did that announcement at re:Invent 2014 when it was in preview. I was looking around at everybody else and there was definitely some excitement. I was just personally so enthusiastic. Something just hit a note in me that is still driving me to this day and inspiring me to build great developer tools and really capitalize on the potential I first saw when it came out and still feel today. For me, I actually never got into this to be a developer. That was not my personal goal when I was just getting started. I've always felt more like a creative type, to be frank, and more of an entrepreneur. The programming, the development, was kind of a means to an end, but also felt like potentially the greatest skill set to have at a time where the cloud, programming gives you the ability to make anything, to solve any problem almost. I think a lot of my story and all the time that's gone into the Serverless Framework, the same goes for the community members and whatnot. I think there's something similar where the people who are attracted to this are very much product focused. They really care about making things, they care a lot about the customer experience. A lot of the technology is cool, but to some extent we kind of want it to get out of the way so we can focus on the customer facing experience. That's kind of always been a strong theme for me personally. I see that in the serverless community everywhere. It was the thing I felt when Lambda first came out. I got so excited. It felt like for the first time there was really a technology where I could just put any logic out there and it would run for me, auto-scale, and never charge me unless I was running. That felt like amazing power. I was looking around, there was definitely some excitement, but it was so early in those days. I think AWS, maybe you remember this better than I do, but they were pitching it as event-driven code, kind of glue code. There was no serverless category, there was no serverless buzzword or anything like that. It was kind of just to stitch together, shuttle some data from one place to another, largely from S3, and had very limited use cases at the time. If you remember all the way in 2015, even once it became generally available, there was no API Gateway to connect, so you weren't able to do those web use cases which are probably one of the most prevalent things that serverless is doing now. Very limited. I don't think all the pieces were there. Enough of the pieces were there for people to get the overall vision, maybe how meaningful it was, or at least how meaningful I felt it was. So I went away from that re:Invent trying to chat up my network, my colleagues, my friends, and see if they were as excited about this new compute service as I was. I was thinking, what if we take this new compute service and pair it with other infrastructure that has the same auto-scaling, pay-per-use qualities? We could deliver software that as a whole has a really low operational cost, almost like these set-it-and-forget-it architectures. That again touched on the theme that I really like: the ability to build more and manage less. I was going out to my network trying to raise a lot of excitement about this and just see if people were equally excited. There were some, again early days, some people were into it, but not a lot of people cared then. I kind of took it upon myself to see what would happen if you could actually take Lambda and build entire applications on it, see what that process looked like and see if it was possible. Right at that point, in those early personal experiments, I ran into the problems of the serverless architecture that we're still dealing with today. That is that this is a distributed system. You're actually working with a lot of cloud services, perhaps more cloud services than any other architecture out there. If you really want to build an application like a web app, you're going to need Lambda, you're going to need to work with IAM, you're going to need to work with API Gateway, you might need to work with DynamoDB, CloudFront, Route 53, a lot more. There's just a lot of stuff in there. The value prop was deliver software that's super efficient, but how do you actually take all these pieces and easily put them together to form a nice application experience that developers would really enjoy? That was the initial problem that set me off on my journey. I think it's the problem that we still are trying to figure out today: how do we streamline serverless development, make it as zero friction as possible? So I started working on the framework. This was just a personal nights and weekends project. At the time, I had just moved up to the Bay Area. I was still pretty new. I'm originally from Los Angeles. I think I was working on another startup at the time and also building out a back-end inventory management system for a larger company. It was just a personal experiment. Somehow I published something to GitHub and Jeff Barr found it. Jeff Barr is amazing, as you know, as we all know. I don't know how that guy does it, but he's looking at everything at all times. Somehow when I was just publishing some stuff to GitHub, he found it. I still don't know how he does it, if he has an army of interns or something like that. He found it, he sent me an email. He said, "This looks pretty cool. Would you be interested in talking about this at an AWS event or us promoting it on the blog or something?" I was pretty honored because I've been a big AWS fan for a long time, a user for a long time. The fact that Jeff Barr was reaching out based on this thing I was working on over the weekends was so cool. I told him, "Let me work on it a little bit more and finish it before you push it out to the Jeff Barr audience," because you know how massive that is. I told him, "Give me a few weeks to really flush this thing out."

Not much. Looking around, there were still a lot of definite challenges there in the architecture. Way back then, it was so much harder. It was crazy hard. I had done a few versions of this even before API Gateway came out. There was one other project, I can't remember the name of it, it was really strange also trying to work around the complexity of using this new infrastructure that was just so raw and early. But there were a few versions that I worked on before API Gateway came out. Then when API Gateway came out, obviously that was the missing piece for one of the major use cases, which is back-end APIs, microservices, all that. I worked on it a lot. API Gateway came out, I think July 2015. Then I did a whole new version of it. I think it was that time where I really honed in on the essence of the framework. That was, okay, there's a lot of cloud infrastructure that you have to work with and developers have to know about. Unfortunately, developers don't really like working with a lot of cloud infrastructure. They like building apps and getting stuff out there as fast as possible with the least amount of distraction in their flow as they're working on something, creating something. My goal was to hide the infrastructure complexity first and foremost. By the time API Gateway came out, I think the opinion that was honed in on was that serverless applications are a simple story of functions and events. That is the essence of a serverless application. That whole idea is how the framework is going to be designed. That's what you get in a serverless YAML file. You get that functions property where you could list out all your Lambda functions and add in your business logic, your code. Then there's an events property where you could hook up anything to trigger that function. While it's a bit strange to define an API as an HTTP event triggering a function, it just brought order to a pretty chaotic, especially back in those days, type of architecture where the developer could just quickly look at it, understand that story. With a lot of abstract configuration syntax, the framework also does something a bit different than a lot of other application frameworks: it helps you structure your code but it also provisions the cloud infrastructure. It's this weird hybrid thing. The goal was don't make developers have to know a lot about the infrastructure. Come out with a nice application model that allows you to focus on logic and what triggers that logic to run.

Yeah, absolutely.

Yeah, it just seemed right at the time. There was just a lot of chaos and it needed a simple story, a simple way to think about it to bring order to that. Looking back, even at the time it was just so weird to define your API like that and stuff. But also, I think we were just so excited about Lambda in general and its event-driven qualities. It's a really amazing thing. Maybe this is kind of far out there, but it's never been easier to write code that reacts to events. You could just go put in a Lambda function, deploy, tonight I'll deploy a thousand functions. It's a thousand different things just sitting waiting for something to happen. In some ways, maybe that's how humans work, maybe that's how businesses work. They're just kind of logic sitting there waiting for events to happen, and then it runs. This felt like such a nice natural model that could really scale. It felt natural. Looking back, certainly fast forward ahead, serverless has grown a lot. The use cases, the types of infrastructure, all that. Is that still the right model? I don't know. But I will say that developers still love it. They get it so easily. The interesting thing for us was when we first surveyed our audience, we realized that 30% of our users had never even used AWS before. They just came to the framework because I think it just surfaced the few things that you really need to know about on AWS and gave you a simple model to deploy serverless architectures on Amazon. That was the theory back then. It was just me working nights and weekends on how do we bring order to this complex new architecture that has these great values, but unless we bring order to the architecture, no one's going to be able to realize that value and potential. So that was the solution that was designed. Now there's another part of this that's kind of interesting to talk about, and that's the marketing. Marketing, I don't think is something that developers think a lot about, or the cloud industry, especially maybe more so back then. Now it's increasingly important. My background actually grew up outside of Hollywood. I was always around, growing up I'm a self-taught programmer, but I was actually hanging around a lot of screenwriters and directors and people of the film industry. I had learned so much from them about designing product for emotional impact. That is, taking something and wrapping it in a story. If you can get a great technical solution and wrap it in the emotional charge of a narrative or a story or an idea, then I think you could really deliver a more profound effect on the end user, a more profound message and experience overall. That's my personal product philosophy. It's this weird hybrid of being around that culture while also being an engineer. I think a lot about that in terms of how you bring products to market. Looking back, I say that was an equally important, if not more important, piece of this whole thing. I spent probably just as much time trying to come up with this framework and this technical solution as I did designing some marketing. Hence, for those who don't know, the Serverless Framework was originally called JAWS and it had this cool shark mascot icon and the big bold all caps JAWS text. I had recycled that branding from another project. My backgrounds are in design and motion graphics. I recycled that branding from another project, but I was trying to find a way to embody how big I felt this architecture was and this framework was. I was trying to personify it in a way that felt like a blockbuster. JAWS was kind of one of the original blockbuster films way back in the day. I wanted it to feel like a big deal. So I took some of that mascot, the branding, all that stuff, and wrapped it in this cool experience. But the last piece of that, probably the most important piece, was the term "serverless." These days the word was not really around at all. It was still always "event-driven code," "glue code." But I had read, while I told Jeff Barr, "Give me a few weeks, let me try and figure this out," I had read a blog post on the Amazon Compute Blog from Tim Wagner. It was the first time I ever saw the serverless buzzword, the serverless word in general. He had written in there, right buried in the middle of the blog post, there's one sentence: "You could use AWS Lambda to build entirely serverless applications." As soon as I saw that word, I thought, "That's a great word. I love that. Not sure what it means." I don't think we know what it means now, but that's a whole other podcast debating that. The developer in me, the maker, the person who just wants to hopefully build cool things one day, I just love that word because it meant to me the technology that kind of gets out of your way, less management, all that stuff. So I loved it and I started putting it with the JAWS branding all over the project. I totally admit a lot of over-the-top propaganda. It was "JAWS: The Monstrously Scalable Serverless Application Framework" was kind of the tagline with the shark icon coming out of the water trying to take a big bite of the text. On the GitHub readme, there were some badges: "100% Server Free," "No Servers Guaranteed." Because we're kind of this badge-oriented society, looking at GitHub repos, "Okay, does this have all the badges I need?" You're at the market looking at all the badges on the product. It was just over the top. It was fun. I wasn't really thinking about anything kind of later down the road. Before I had a chance to even talk to Jeff Barr, I did the typical Hacker News post. That was on a Tuesday. I was about to go out to lunch. Before I did that, I thought, "Before I send this over to Jeff, I'll just put it on Hacker News real quick because it'd be great to get some feedback before Jeff Barr's audience and the AWS audience hear about this." I posted it and I just walked away, had a sandwich someplace, and came back. It front-paged immediately. Tons of upvotes, a ton of enthusiasm. People were pretty excited about it. I had no idea this would happen or anything like that. It wasn't orchestrated. It was just such a casual thing. Literally overnight, it just caught on and it kept picking up momentum like nothing I've ever seen before. I know you're a fellow entrepreneur and developer. I've built so many things before this, so many projects. For every successful project, there's a hundred skeletons of projects. Sometimes I think there's the notion of product-market fit. Sometimes maybe you get lucky. I think luck has a lot to do with it, timing, all that. You just hit the nail on the head and it works. All of a sudden, when you see it, it really takes off and starts to form a life of its own. It almost becomes beyond your control. It was just like that. It was a totally phenomenal experience.

Yes. One of the projects I had recycled the branding from was just the JavaScript AWS Framework. That was the goal. I'm a big JavaScript fan. At the time, it just wasn't a good application framework for AWS, something that could just help developers be productive on AWS with again not knowing a lot about the cloud infrastructure. It's a big theme of mine, especially for the JavaScript community. I had designed a JavaScript application framework, but it was really early. I think I just worked on the branding and got caught up with that before the project was even there. So yeah, it was the JavaScript Application Framework. But then when Lambda came out, I recycled the branding and I kind of ditched the acronym because it wasn't as important.

Okay, yeah. This is a great question because it starts going into going from JAWS to Serverless Framework and establishing the company. After that initial Hacker News post, things picked up a lot. I was working hard just to promote it and get it out there. People were really excited to hear about us. I was doing a lot of events in San Francisco. AWS has one of the AWS Lofts here, and I was demoing the framework almost every week. I remember the first time I met Tim Wagner in person. He was there doing a presentation on Lambda. I just approached him right before he was going on stage and said, "I built this great application framework. I'd love to just show it off. Will you give me some time on stage to just show the audience?" He was like, "Sure." I was pretty excited. He'd probably tell you about the enthusiasm. He probably had a hard time saying no to me at that point because I was just so pumped about everything with this project. So he let me on. I presented there a lot. Also at re:Invent, the Lambda team, Tim and Ajay, they told me last minute, "You want to go present at re:Invent 2015?" I was like, "Absolutely." I had even done one other cool growth hacking thing, or maybe just something that came from my unconventional background. I had put together a JAWS Serverless Framework movie trailer. I took clips from the movie JAWS and I was going to show it. If you put this on YouTube, you'll probably get in trouble with the music in the background. I just took clips from the movie JAWS and I put these titles like "Serverless Framework is coming for your infrastructure," intercut with clips of the shark from the movie underwater, you see people swimming, you never see the shark, which is the early brilliance of Spielberg when he was making that movie. You just see the innocent victim, shark POV. I had posted that before re:Invent and I was so excited. Werner, the CTO over at Amazon, had retweeted it. He wrote, "This is mesmerizing" or something like that. I've been such an AWS fan for so long, it was so cool to go through that whole experience personally. However, at the same time, when this thing was picking up some momentum, there was also equal amounts of shade and doubt being thrown at this whole burgeoning serverless movement. First time I posted the framework on Hacker News, I think the first comment was, "This is a horrible idea." That's how they say hello on Hacker News. If you don't get criticized on Hacker News... So some skepticism on the product and the project, whether it would actually work for real-world use cases, which is par for the course if you're building out something new. Also, early days, cold starts were more of an issue. It took the whole architecture to get out of that cold start fear, uncertainty, and doubt territory. Now we hear about that less and less. AWS has done such a great job, all the other infrastructure providers have done such a great job to reduce that cold start. I even remember when I was first chatting with the Lambda team, someone who will go unnamed was like, "After you deploy their application, could you just ping their Lambda real quick to warm it up behind the scenes?" I thought, "I don't know if I feel right about that. I'm sure it'll get better. Just keep doing the great work that you're doing." Then there was a lot of talk about "no ops" back then. That was a big thing when everybody was starting to get excited about Lambda. The "no ops" term came out, which I don't think is right for this architecture. I think it kind of alienated some people out there. So there was a lot of pushback on the whole idea. Meanwhile, I was having some challenges with the logo and the branding. I should have known. The trouble was not actually from Spielberg or Universal or something like that, because trademarks are usually registered respective to a specific type of service or good. There was another project out there, a screen reader application called JAWS, which is essential to a lot of people to gain access to computers and start writing code. When JAWS was picking up some momentum, I decided to put a sponsor link on there and see if someone might send a donation. The only donations I ever got were from people who kept sending me one dollar donations and they always put the hashtag "Change your name," from the visually impaired community or something. I got a bunch of these, and then I started to get more and more threatening emails, which is totally understandable. You're born into this world on someone else's property and you've got to figure out how to carve out your own space. I knew almost immediately after it took off that it was going to be a challenge. While this brand and stuff, some of the users of the project loved it, I knew we had to change immediately. Also at the same time, I was wanting to build a company around this. It very much felt to me even back in the early days, and more so today, that serverless is not a fad. It's the natural evolution of cloud. The cloud and serverless almost seem like they're on a path where they're going to merge soon, and serverless will just be the cloud. That's just what you should expect from your cloud infrastructure. I wanted to build a company around this because I felt like there was a huge opportunity to build a next-generation set of developer tools to help developers capitalize on this great, super powerful cloud infrastructure. I was going around doing some meetings with the VC community around the Valley. It turns out when we raised, a lot of our investors are actually Docker's investors. Interesting. I think they were very much looking at us in the early days almost as a hedge to some extent. In my pitch deck, I had the JAWS branding and everything. A lot of our community members in the early days were coming from the Docker community because I think a lot of those people realized they didn't want to think about containers. They just want to think about product, building apps and getting it to market as fast as possible with the least amount of maintenance. We were getting an influx of that crowd. I had put on one of my pitch decks the JAWS branding, and there was just one slide where there was the Docker whale and it was upside down in the ocean and it had a huge bite taken out of it, cross crossed over its eye. Then the slide after that was just JAWS. That was the introduction to the pitch deck. I remember I was looking at the VC's portfolio again right before the meeting and I saw they are big investors in Docker. I took out that slide immediately. But there was potentially some cool branding we were going to do around that. Anyway, it was raising capital, trying to turn this into a company, this scrappy effort into a real company selling great dev tools to people who want to take advantage of all this. I had to change the name. It wasn't quite clear still that serverless was going to be the term, the category that it is today. All I knew is that serverless is the word that generated the emotional reaction in the user base. That was the thing that developers were responding to emotionally that got them to lean forward in their seat and say, "Oh, this is something different." I had 10 names and I was running them by even some of the potential investors. The feedback I got with "serverless" was, "What does that even mean? That sounds really weird." But I set my eyes on it. I thought, "I've got to get the domain and see if that's available. Got to have a great domain because .com we trust." I started the hunt for that. It took honestly two months of cold calling because I could not find who owned the domain or anything like that. Two months of calling around trying to find this person, and then another month kind of negotiating because the person who owned it kind of sensed that there was some opportunity. So that took a long time. It was still just me working on this project, trying to build up the product, the marketing, the promotion, do the name change, do some meetings around Silicon Valley. I had somehow been fortunate enough to be able to get the domain name and then eventually close around the capital. That was right at the end of 2015. We became, JAWS transitioned over to Serverless Framework, and we became Serverless Inc., which again, we didn't know it was going to be so big. Now we're in this awkward position where we're named the same thing as the category. I hear all types of creative ways of how people explain when they introduce the company or something, how they differentiate it from the architectural pattern, the movement, and the company.

It's good and also really confusing. The experience your daughter went through is the experience that almost everybody has to go through at some point. A lot of people have to take the time in the beginning of a lot of meetings and presentations just to try and provide some clarity. It's very interesting. That was always the word to me, and it was just based on something to do with my background, thinking about how you design products for emotional impact and always looking at what really generates excitement in end users at the end of the day. It was that word. I never forgot the first time I read it. The credit goes to Tim Wagner. That's how I felt the first time I saw it. I don't know when you saw the serverless word for the first time. Do you remember?

Yeah, yeah, yeah. It was amazing. It's been five years and all this stuff that's happened since. But that's the story behind the domain and the name and all the things that led up to transitioning from JAWS over to that. Looking back now, serverless is such a massive category. A lot of vendors in this space, every major public cloud provider has a serverless compute offering. That part of it was just a wild, surreal experience.

It's so funny that you brought that up because I still get grief for that. It's been years. That was 2016, now it's 2020. Certainly a lot of other stuff going on in the world, but I'll still hear from someone, "I can't believe you did a breaking change." Especially at re:Invent, when we go to re:Invent, people bring that up. They're like, "Finally I got to meet the people who made that breaking change and tell them about it." I started as a solo founder, which is a whole different type of experience for building a company. If you have co-founders, I don't know what the right way is, but I do know that solo founders have to do a lot. It took me a while to build out the team and do everything because it was just one person trying to still build out the software. But the best part of all of this is the community. It's the people who helped along the way and made a huge impact. Going back all the way to Tim and Ajay on the Lambda team, all the great folks there who were pioneering. I remember the early conversations we had back then. They didn't really know what they had yet, it seemed, compared to how they talk about it today. Everything seems so clear and obvious now, but back then the conversations were just all over the place. People were trying to describe it. There's a weird thing sometimes when stuff takes off before people can describe it. That's an interesting phenomenon. They did a great job early on. Back then, 2015, 2016, there's a lot of the AWS community who helped, who were helpful along the way. Like Jeremy Edberg, Peter Santos, Mitch. These were the original, at least in back of 2015, the cool AWS luminaries. The people who are in the AWS user community, there's different waves of people. Back then it was Jeremy, Peter, and Mitch. They were certainly helpful. I spent a lot of time chatting with them about this. Another friend of mine, Ryan Pendergast, who I haven't spoken with for a while, was instrumental in really helping design the first version or the first few versions of the framework after we got launched and shaping where it would go. He was great. Back then also, A Cloud Guru, credit to them for being some of the early visionaries in the space. Sam and Ryan, I was working with them. They were doing the original serverless conferences. Were you at the first one in Brooklyn? I think it was 2016.

It was such a funky conference. It was amazing. It was this cool little, almost divey conference venue in Brooklyn. It was the middle of the summer in New York, everybody's sweating, there's no air conditioning. I don't know how many people were there, I don't even know if we hit a hundred. But A Cloud Guru got in front of this and really helped promote the movement. They should get a lot of credit for that. Ryan, Scott Brown, Jared Short, as you know, these were big contributors early on. Jared especially loved the JAWS stuff. I remember he loved sporting the JAWS hoodie. Enrique from Red Badger, Marcia who's at AWS now, Alex, Cas, Boney. There's just been so many great people. Rob over at Nordstrom, Eric who's at Nordstrom. It was one thing to be a solo founder, but it's another thing to be a solo founder with all these great people helping out via open source, working on this project, trying to define, we all knew there's a great new architecture here that could really enable more people than ever, but we've got to make it easier, we've got to make it accessible, otherwise people won't be able to realize all this. We only scaled to a few people in 2016. For the first couple years, we just focused on community development. That was it. We didn't do much of anything else. A lot of that credit goes to Dan Scholnick, who was one of the original investors in the company. He was over at Trinity Ventures, now he's at another firm. He was first money in Docker, or at least one of the initial investors. He's got great instincts. I remember we had a conversation where he said, "Just focus on building the community right now. Just make that community as big as it can be and just take time to focus on that." That was really instrumental for the company, to hear that especially coming from an investor saying, "Don't worry about anything else, just build out the community." So 2016, 2017, all the way into 2018, it was just a lot of working on the framework, which as I'm sure you know is no small feat because that thing has grown so much as an architecture in terms of the surface area it has to cover. It's in the tough position of trying to abstract and create a simpler experience over a growing amount of AWS infrastructure and configuration options and composition options. It takes a lot of calories to keep that project going. 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 just instrumental to the growth and the scale that the framework has right now.