Serverless Inc. CEO and founder Austen Collins was recently featured on the The New Stack Makers podcast hosted by Kiran Oliver. In this episode titled “How the Serverless Framework is Reshaping AWS Lambda” Austen talks about the Serverless Framework and the important role our open source community plays in shaping it. Listen to the conversation on SoundCloud or check out the transcript below.
How the Serverless Framework is Reshaping AWS Lambda [Transcript]
KO: Hey everybody, this is Kiran Oliver, and welcome to this week’s episode of The New Stack Makers. I’m here with Austen Collins of Serverless, and today we’re going to be talking about the new release of Serverless. So Austen, given the buzz was amazing leading up to this launch of Serverless, how was what went into 1.0 affected by feedback from the community in terms of what was given first priority, and what sort of features went into it?
AC: Yeah, I’ll jump right into it. Serverless Framework V1.0 is definitely a reflection of feedback. Actually we get lots and lots of feedback — it’s really phenomenal how much is generated in an open source project, especially this one. What we’re making is a framework for building serverless applications, meaning apps built on the new event driven computer services like AWS Lambda, but deploying code on Lambda is only half of what developers do when they make a serverless application. The other half is people need to manage the infrastructure their Lambdas use, like S3 buckets, DynamoDB tables, manage permissions, environments, regions, meaning we basically have to build an application framework for using the entire cloud provider. Sometimes I say we’re building the AWS application framework, but then of course we interpret the provider from the perspective of a serverless architecture, as if AWS Lambda is the foundation of AWS Cloud. Then in V1.0 we’re bringing on support for multiple cloud providers, so basically all this is a super ambitious scope of work and there are a lot of opinions on how to do all that, naturally resulting in a lot of feedback. On top of that you add in the surreal momentum that the serverless movement has received, and the strong attraction our project has had, all inspiring feedback coming in through multiple channels of communication: Gitter, GitHub, email, stack overflow, Twitter, Facebook. We have a Serverless Forum now. The result is a lot of feedback coming in at a rate of probably at least one comment every few minutes. It’s a lot, especially for an open source venture that has no income at the moment. So yeah, feedback was a huge factor in V1.0. We can’t escape it. We’re honored to have as much feedback that’s coming in the door right now. We have a few full time people on the framework. I’d say the majority of their day is used to read feedback, it’s pretty phenomenal. So the next challenge is of course prioritizing all that, determining the features, determining the good feedback and not getting distracted. That’s a big challenge for us. The way I handle this personally is I’m very theme based. I try to identify themes everywhere in life, and judge things based on how well they express the theme. You probably think about this all the time because you’re a writer, right?
KO: Definitely. That’s always something on your mind, how can you tie something together to make sure that it’s all cohesive?
AC: Exactly right. The theme I started with when I first began the framework over a year ago now was I simply wanted to build more and manage less. I wanted to be more productive and minimize overhead — pretty universal themes. What feedback we decided to take on, and the overall direction the framework goes in is, and always will be, determined by how well it fits that theme. So that’s the first criteria. Then getting into actual features, I’d say the next biggest piece of feedback that we had was to stop making breaking challenges. The underlying technology that the framework depends on has changed so much since I started the framework by myself. AWS Lambda has changed. API Gateway has changed. They have evolved significantly, and the result is we’ve been chasing this moving target resulting in a lot of changes, which is one of the reasons we completely depend on AWS CloudFormation in V1.0. Serverless Framework V1.0 is basically an abstraction of CloudFormation, and by embracing it, we build on top of something that AWS has signaled to be very stable, and many of the things have improved as a result. Lastly, there’s no framework locking because you can always generate a full CloudFormation template of your application and be on your way. Stop making breaking changes. I think this decision was the best way to accomplish that goal and the next step. Since the framework was begun there’s been a whole bunch of other Functions as a Service (FaaS) products that have launched and we received a lot of feedback that people want to use these products. Some examples are Azure Functions, Google Cloud Functions, IBM OpenWhisk. So we started building in support for other providers in the framework. And we’re fortunate enough to have some of the major providers actually writing the integrations themselves into the framework. Like the Azure Functions team is working on the Azure Functions integration. The IBM OpenWhisk team is also working on the OpenWhisk integration. So stuff is coming on that front and it’s going to be built by the experts themselves. It’s super exciting. Lastly, we learned a lot about Lambda and FaaS work flows in general in version zero. Version zero was the trailblazer. Now we’re incorporating all those learnings and building something that is just hands down going to be the best tool to help you build more and manage less. It’s absolutely the tool for anyone who wants to move fast, scale massively, be cost efficient, agile and super competitive.
KO: I know there’s a plugin system getting introduced. How is that working? Are things easy to swap out, piece together? Is there any particular language you’re seeing people develop in in terms of those plugins?
AC: Yes, we did have a plugin system in version zero and it was pretty successful. It was something actually introduced super early on in the framework, but we’ve made it much more stable, much simpler in V1.0. I opted towards a plugin architecture in the immediate beginning of the framework because I put it on the internet, it went super viral, everybody loved it, and that was like day one. It was a fantastic day. I got a lot of attention, a lot of positive feedback. Then the next day in the repo all the issues started to pour in. I realized wow, we have an ambitious scope of work, there’s a lot of issues, there’s a lot of feedback out there and everybody has different workflows. Startup requirements differ. Enterprise requirements differ. I think there are as many development styles as there are developers out there. So to meet all these people’s requirements it was clear that we had to have a plugin architecture on day one, and make it robust and easy to plugin to. Further, as a developer, I like to hack stuff. I think many other developers feel the same. If I can’t hack it or modify it, extend it, then I dislike it to a great degree usually. That was another motivator behind it. So yeah, we started that in version zero and it’s been pretty successful. I probably have 70 plugins just for version zero alone, and in V1.0 very similar, but simpler, more stable. As far as languages go, I’d still say we see a lot of interest in Node.js. This may be because our whole framework is written in Node.js we’re attracting that crowd, but the framework also works for Lambda functions written in Python and Java. I say next up on the list where we see the most interest is definitely Python.
KO: Awesome. I noticed that the Serverless service experience is a really big part of the V1.0 picture as a whole. In terms of how resources and infrastructure are operated, what are you seeing the community usually setup and accomplish with that?
AC: We have a concept called the Serverless service. It’s something new that we’re introducing in V1.0. I’ll explain the backstory, or the problem it seeks to solve, before going into how it solves it. I’d say the first thing that you notice when you start building a serverless architecture is that you’re making lots of independent functions, or application components. Our theory, at least on our team, is that event driven, serverless apps are the future. The logical evolution of this is that people will end up building significant amounts of functions. And this is kind of a lot of what serverless applications, serverless architecture is. It’s mostly a microservice architecture. So for example, larger companies already have a lot of microservices. I think Netflix operates over 1,000 microservices. Given that Lambda functions, I’d say, are written to be even more granular than microservices a lot of the time, I think that if you took Netflix and expressed it as lambda functions they’d have probably a few thousand of them, instead of just 1,000 microservices. So we think this is where everything is heading, but the result is you’re going to end up building a lot of functions. The only reason why we think people aren’t immediately making these vast amounts of functions is because the tooling to help you develop, deploy, and operate all these functions isn’t there yet. In development, in operation when you have all these separate units of deployment, all these separate, totally independent components of your application, it’s awesome because when you’re handling lots of volume, a lot of traffic, and you need to go update something, or you want to add to your application, all you have to do is modify one single piece. And you’re not going to risk changing the whole application, the whole project, and that’s really great. That leaves you an incredibly agile, less risky position in production. So in operation, having all these little independent units is absolutely fantastic. However, in development, if you have several thousand Lambda functions — we don’t see that yet, but we do see people with a few hundred of them sometimes — this is super annoying, because you have to share code across all these separate files basically. You have to share infrastructure resources, like an S3 table or something, commonly across all these functions, and then add in multiple environments and regions, etc., across a growing project. So it gets complicated in the development and deployment phase. The way I put it sometimes is the function as the unit of deployment is super powerful, but the function as the unit of development is painful. So you’re stuck with a situation where you’re writing all these separate, independent units of code, and the framework seeks to make that process easier. That’s one of the big goals of the framework. In version zero we noticed something. And that is that people are writing these Lambda functions in groups a lot of the time. They do this because a lot of Lambda functions are related. They’re sharing code, or within just a smaller larger group, or they’re sharing resource requirements. So for example, a backend service like a user service will probably share some code across five different Lambda functions, or four Lambda functions that handle CRUD operations on that service. Or like a data processing through some data pipeline or something will probably be a group of Lambda functions that are sharing code and resources. Functions, we learned, are easier to develop in groups, and people naturally like to group them, so we created this concept called the Serverless service. It’s basically a group of functions — it could be one function or several functions. And in that Serverless service you’re defining not only your functions, but also one set of infrastructure — like a DynamoDB table or an Amazon S3 bucket — that all those functions depend on. All this is defined in one file written in YML, so it’s pretty clean to look at. It’s just the serverless.yml file. The great thing about this is that you’re sort of, you’re developing functions in a group, which makes sharing code and everything a lot easier. But when you go to deploy it the framework will actually split it up into separate units or deploy it all together if you want, so you have flexibility in how you deploy. That’s the premise behind the Serverless service. So far it’s been super successful. It’s just a much easier development workflow. The only thing that’s next that is really interesting is how we can make these Serverless services shareable, and how people can write these once and share them with the open source community so that you don’t have to go rewrite the image resizer or some webhook handler for handling strike by votes or something. All that stuff should only be written once. People should be able to install it, and run it right away, so that’s the next frontier for that.
KO: Awesome. That sounds great. Another thing, too, is when working with things like Google Cloud Functions, Azure and OpenWhisk, what can developers and DevOps teams expect when setting those up, especially across a multi platform environment?
AC: Good question. We’re seeing increasing interest for this, some of the other FaaS products aside from Lambda. Lambda is the most mature out there. The other FaaS products, I don’t think any of them are actually released yet, at least from the big providers. I know webtask.io is out there. Hook.io is out there. Those are really interesting products. First off, being open and accessible is a big goal of ours. Also, personally I think developers should be free to use any type of compute service they want to so they can take advantage of lower costs or features that any one platform is offering. The great thing about the FaaS product is that it’s the easiest way to get started on an Infrastructure as a Service (IaaS) provider, and I think that all these providers have caught onto this. That’s why they’re making these FaaS products. These providers are offering so many great proprietary services outside of just compute. And if you want to take advantage of those services, like DynamoDB for example, you don’t need to go provision and maintain in EC2 Instance just to play a Lambda function. You’re ready to rock. You can start working with Dynamo DB right away. We think that deploying the multi-cloud future is coming more so than ever because it’s easier to do that type of architecture with FaaS. You could easily have a few functions on AWS, a few functions on Google, some on Azure, and IBM as well. So the framework is preparing for this multi-cloud future. Actually we sort of hope to enable it to some degree. However, how we get there is tricky, because unfortunately all the FaaS providers are pretty different once you get under the hood. I think in general we’re still on V1.0 of event driven computing. It’s going to evolve a lot. So we’ve backed away from making a single abstraction for now — just one way to write functions across all the clouds — mostly because as everything is changing so rapidly, we felt we would get in a position where we end up blocking users and eliminating usability across those services. We’re not making this single abstraction; however, we are making a uniform experience in concepts, and in workflow and in some syntax. Again, not so much that it gets in the developer’s way and puts us in a position where we can’t rapidly adopt new IaaS features. So multi-cloud stuff is coming. It’s easier than ever to do, especially with Faas. And we hope to make it even easier with the framework.
KO: In that vein actually, in terms of working with Serverless, I was wondering how that’s been working out in terms of getting people to actually embrace serverless frameworks and start using them?
AC: For the first question, we solve pretty much everything with our community. We’re doing it in public, right? We can’t not have these outside people’s opinions in there. So everything all day long in our GitHub issues, debates, discussions, proposals are being written on how to accomplish things best. We wouldn’t be here today without these fantastic people. I mean there’s been so many incidents where someone, a total stranger, has come by and given us a great idea. It’s really remarkable to have that. Sometimes we’ll never see that stranger again, but they came by, and they had a really significant contribution just for that short time window. We work with our community all day long. We’re in Gitter, we have the Serverless forum, GitHub issues, tons of channels in which we hash stuff out and discuss stuff. Again, our scope is super ambitious, but it’s worthwhile, because if we could offer this great tooling, people are going to be building stuff faster than ever. They’re going to be building more than ever. Regarding the education of serverless architectures and how we help people transition to them, I think the framework is the best at doing that. And that’s why I started the framework to some degree. The framework is absolutely hands down the best tooling for getting started with a serverless architecture and Lambda. Just Lambda in general does tons of automation for you — optimization, best practices are all baked in, and it shows you how you scale those across a bigger team and a bigger project. So the framework is the biggest educational piece. We’re going to be producing a lot more educational material here in the near future, but so far I don’t think that people have had a hard time adopting a serverless architecture. I think that they’re usually getting stopped by just developer experience problems with AWS. That’s stuff that we’re trying to solve as much as we can, but some things like getting your credentials and dealing with permissions and stuff, there’s only so much we can do there. But once they get it, they’re up and running. We also see a lot of big enterprise companies adopting the serverless architecture super rapidly, partially because it’s already the tried and true AWS infrastructure that they’re running. And Lambda is basically easy to write, so they already have buy in to some degree, and now they’re just looking at this more efficient version of AWS cloud computing. So they’ve been quick to jump on the serverless architecture movement. We see lots of big companies making serverless teams with a new organization. They’ll start off with just one person who is a believer and we see that these teams are growing. Everyone else in the organization is starting to hand them more and more logic, more and more workloads to rearchitect in a serverless fashion. So I think people get it. I wish that AWS would do a few things to make the developer experience a bit better, especially around onboarding. We have some educational stuff coming out, so that should help out a lot.
KO: That’s awesome. In terms of the problems facing developers when working with AWS, ones you see, minus the credentials issue, is there anything else that people are like “please help us solve this”?
AC: Yeah, there’s a lot. That’s why I started the project, just because the developer experience for building serverless architecture on AWS was not great in a lot of areas. As I think onboarding, you know the credential issues, that’s something we see all the time. We get a lot of people who are completely new to AWS using the framework, so they’ve never used AWS before. Some of them are coming over from Hiroku or something. I mean it’s pretty phenomenal. A lot of what happens in our community is really kind of a lot of AWS questions. So aside from the credentials, and just the general onboarding experience there’s API Gateway. It’s a wonderful service, super powerful, lots of functionality in there, but with all that complexity, with all those options, the basic user experience just sort of suffers as a consequence of that. There are lots of things there we think could be done better, but then again, that’s what the framework is for. And the framework is solving that problem in particular. For example, when you want to pass in information or data from an HTTP request into a Lambda function, you just can’t do that immediately with API Gateway. So if you hook up an end point, a Lambda function, nothing is really passed through unless you explicitly define it in API Gateway. That stops a lot of people immediately because they’re used to just HTTP bodies sort of going right into their functions or their logic, but again, that’s something the framework solves right now. In V1.0 we’ve created all the settings so that everything that’s attached to an HTTP request is passed through by default and then you can go ahead and start stripping away stuff you don’t want to be passed through. I say all those AWS problems are usually a consequence of all the functionality, sort of options, and great options that they provide. We like that that stuff exists and I think it’s kind of just the perfect fit for a framework now to go in and surface what really matters, and abstract a lot of that stuff away so that you can get to work faster. It’s great that all that functionality exists. There’s a lot of complexity there, but it’s great that you can use it when you need it. And then of course rely on a framework or some tool just to help you move faster and not get distracted by it.
KO: Absolutely. I just wanted to thank you for taking the time to talk with me today, and to let people know a little bit about Serverless, and what they can expect moving forward. When do you think that the next round of beta is going to be out for people to have a look at?
AC: We release every two weeks. We’re on an aggressive release schedule.
KO: Sounds it.
AC: Yeah, and we’re trying to move faster and faster. We wouldn’t be able to do it without our community, too. The pull requests are coming in every day. There’s multiple pull requests coming in and it’s fantastic. A lot of our job is, as I said, it’s reading through all that feedback, and now it’s just doing code reviews, which is great. I can’t name them all, but like Benny Bauer, Paton Crispy, John McKim, Kenuu, Wedgybo, Erik Erikson, Rob Gruhl, I mean there’s so many great people in the community. Just had to give a shout out to them, too. Because again, we wouldn’t be here without them, and we’re releasing so quickly, and we’re going to try and release it even more quickly just because of that.
KO: All right. Well again, thank you so much for taking the time out to talk with us today. Definitely want to have you back once Serverless goes live, and we can really hash it out.
AC: Awesome! Thanks for having me.
Also published on Medium.
