 How many people in here are actually full stack developers? Just curious. Raise your hand if you're a full stack developer. Awesome. Awesome. Pretty much everybody, almost. I'm Austin Collins. I'm a full stack developer. I love full stack development. That's why I got into this project. I'm also a DevOps engineer, AWS Community Hero, and the creator of the serverless framework. There's clearly a lot of hype around serverless right now. There's a lot of people talking about it, around serverless architectures. And this thing, this hype, feels very much like a movement. At least it has all the qualities of a movement. There's an open source ecosystem around serverless architectures for deploying serverless architectures, managing them. There's thought leaders in the space. There's huge technology companies all looking to participate somehow, and controversy even. And I'd like to take some time just to chat about what is it, what is this serverless movement all about, why it's a big deal, and where it could be going, as well as how to get started. And before I get into that stuff, though, I'd like to take some time to tell the story from the beginning, at least the beginning from my perspective, because that's the only story I know best. And this is a tale of open source technological giants and unexpected disruption. It was a dark and foggy night when I moved to San Francisco two years ago to build startups. I didn't have a lot of money then, but that was OK because money doesn't mean happiness for me. Building stuff means happiness for me. And if you're that type of person, you go to San Francisco, because it doesn't matter how much money you make at the end of the day, you're still not going to be able to afford anything. But at least you're surrounded by other people who like to build stuff. And that's what it's all about. Now by 2015, the hype was in containers and DevOps. But those weren't my personal interests at the time. I think containers, I think portability is a fantastic theme. There's so much great energy and innovation in that space. It's really exciting. DevOps, same thing. Super interesting. And I was moonlighting as an AWS consultant, so I was focused on that a lot. But I was there to build startups. And I had a different focus. I was focused on efficiency. Efficiency in pricing and cost, efficiency in time. See, after you spend a little bit of time in San Francisco, you quickly realize that it's an arms race over there. And that city is filled to the brim with startups that are moving at record pace. They're super competitive, as well as technology giants who are also moving at record pace because they've adopted all the startup methodologies like continuous delivery and microservices. And they're moving faster than ever. And they have all the resources and capital in the world. After living in San Francisco for some time and seeing the software engineering landscape evolve, I'm not sure if I agree with this notion that a startup can outpace a big technology company anymore. I think that these technology companies, they can ship features just as fast as startups, but also they have tons of competitive advantages like really good data about what features to ship. So I was new to San Francisco. I was absorbing all this, observing all this, recognizing for what it is. It's an arms race. And I was looking for something, some type of competitive advantage, some type of edge. Something that would empower somebody like me with little resources to compete in this crazy hyper-competitive world. In late 2014, Amazon Web Services, the cloud computing juggernaut, introduced this new compute service called AWS Lambda. Now, in those early days, it was pretty raw. And it only had a few use cases. You can only do a couple things with it. But I saw that, and I said, you know what? This speaks to me. This speaks to my values. Because to me, what it represented was a convergence of all the best themes in software engineering of our time, altogether in this new type of compute service. And that is microservices. So when you deploy code in Lambda functions, you'll write code to perform a single job. And you'll upload that into a Lambda function, like, for example, save a user to the database. You put that in a Lambda function, you deploy it. It's an independent unit. Then you write some more code to do another job. You deploy that in a Lambda function, like update the user. And you deploy that as another independent unit. And you compose your application with all these several little functions. They're all independent units, all autonomous. And that is inherently microservice based. And microservice is fantastic for when you're in production. It's fantastic for so many reasons. But when you're in production, and you need to be agile, it's a really wonderful thing to have your application as all these separate independent units. Because when you need to go change something, modify something, or add to it, you only touch that specific component without affecting your system as a whole. And that's a great thing. microservices also for teams to work autonomously on parts of an application without getting blocked by other teams, helps teams move a lot faster. So Lambda, because you deploy code in these independent units and these functions, is inherently microservices. Next up, zero administration. You deploy a Lambda function, and AWS will scale that out automatically for you. You don't have to do anything to make that happen. This is where the serverless term kicks in. Though servers exist, the developer doesn't have to think about it. And that's a beautiful thing. Next up, it's event-driven. You can set Lambda functions to listen to not only just HTTP requests, except traditional web requests, but also lower level infrastructure events on your AWS account. Like if you upload something to an S3 bucket, you could set a Lambda to listen to that, listen for a put object event, and that Lambda will automatically process that object that was processed. You could set it to listen to DynamoDB tables, all types of stuff. And the developer doesn't have to manage, just like they don't have to manage the scaling and operations. They don't have to manage the setting, the event-driven infrastructure, as well. AWS handles all that stuff for you. So already some awesome qualities. Also easy access to AWS services. Lambda is a lot like a pass, a platform as a service. I mean, it has a lot of qualities of a platform as a service. But unlike some of the other platforms as a service, with Lambda, it's really easy to access all these other services that AWS offers. I mean, there are some pass platforms as a service that are built on AWS, but they don't want you to know that. And they don't want to make it easy for you to access all the great AWS services. And the other stuff that AWS is providing, aside from just compute, is incredibly valuable. And I'd say that's half the value of Lambda. And there's no easier way to use all of AWS's great stuff like S3 and DynamoDB than just to spin up a Lambda function and start working with that stuff. And lastly, pay for execution. This is the super interesting one for me. I mean, they're all pretty interesting. They're much more interesting combined. But this really caught my attention. So Lambda functions, you only pay whenever that code is called. You don't have to pay any flat monthly fee or anything like that. You just put your code up there, and it's not going to cost you nothing until that code runs. And when it runs, it's built at 100 millisecond increments. Now for a pricing model, this is super disruptive, especially kind of from AWS. I think that this pricing model alone is going to have vast sort of disruptive effects on cloud computing in general. But you take all these things together. And again, it represents this fantastic convergence of all these wonderful things. And I think the end result is this. I think if you have sort of a zero administration compute service that does all this stuff automatically and it's pay for execution, you've flattened the last few barriers between the developer and being able to provision infinite logic. Because if I don't have to pay for anything until it's run, and I don't have to really operate it, I could just sort of deploy these things, set it, and forget it, I could provision code all day long. I could provision 100 lambda functions a day. Why not? Any sole individual or small team can provision tons of code replicated across regions. So it's not going to cost you anything until that code runs. And that's an amazing thing to me, especially as a full stack developer, because it's like liberating your productivity, like never before. So I saw this, I saw lambda, and I was like, amazing, I want to build everything on this right now. And it was still very early back then. I think July 2015, API Gateway came out, you could officially hook up lambda functions to HTTP endpoints. And I decided on that very day, I said, I'm going to refactor my entire startup to run exclusively on lambda. And nobody was really doing that at the time. Nobody was trying to build entire applications on lambda that just kind of seemed crazy. But I gave it a shot, because again, that compute service, the total economics of that compute service, were so compelling. So I started to do this, and I deployed my first few lambda functions, and it was a little hard to the AWS dashboard. The AWS dashboard is complex, it's a whole bunch of disjointed resources, you have to go over here to look at something, over here to look at something. But I deployed a few lambda functions, and the end result was amazing. I felt super empowered, I felt like a god. And then I had to deploy a few more lambda functions, and it got a little bit more painful. And then I realized I took a step back, I looked at my project and said, man, I'm going to need like 50 lambda functions, at least for this entire project. And 50 lambda functions, that's a lot of little autonomous independent units. The way you write lambda code usually is you make a separate folder for each function, each folder has its own dependencies, code dependencies in there. And dealing with all that stuff 50 times over is painful, to be honest. Now, if you're a bigger company that has like a bigger microservices architecture, like Netflix, for example, Netflix I think they have a thousand microservices, over a thousand microservices that power lambda. Now lambda code is even more granular than I'd say a traditional microservices code is, because lambda is really focused on a single job. At least that's how most people are writing lambda functions today. And I think that if Netflix was expressed as lambda functions, Netflix would have several thousand lambda functions. So that is a ton of little tiny units, really granular units of code. So this is the problem I ran into immediately with my smaller project. All of a sudden I had to figure out like, wow, there's just too many functions here. Now how do I share config across all these little units? How do I share code across all those things? How do I share resources, infrastructure resources that my lambda functions depend upon? For example, these lambda functions need access to this S3 bucket, these lambda functions need access to this DynamoDB table, these lambda functions have this IM policy. That's crazy, it's clearly a situation where entanglement happens quickly. Furthermore, then you want to replicate these lambda functions across stages, a.k.a. environments. How do you do that easily? And then, of course, manage all this stuff across growing teams, what teams, how do teams work on these projects and a growing project? So I'll be the first to admit the world doesn't need another framework. But there was clearly no better solution for this problem than a framework. So it was framework time. And there's another framework out there, but we've come a long way, and it's awesome. And also I think what's cliche is often true, and that's kind of why things become cliche. So anyway, I started to work on this framework. And this was like two days after API Gateway came out. There's Ultimate Grounds Coffee Shop in Oakland. They serve really cheap coffee there. I'd sit on the couch in the back there, and I'd work on this every other day. It was just like a little hobby thing. But then I just became obsessive about it, and I kept working on it more and more. And after a few weeks, I wanted to brand it. I have a design background, and I love giving software a voice and identity. And I wanted to give it a big brand, because to me this felt like a big deal. If you could actually pull off applications, entire applications on Lambda, you could do so much. So I came up with this JAWS brand, because the project felt like a blockbuster, and I wanted to carry that message through it. So I made this cool shark logo. Next up, at that time, I had only read one blog article. It was written by Tim Wagner, the general manager of AWS Lambda. And it was the first time where I had seen someone describe Lambda as serverless. The line was something like, you could use AWS Lambda to build truly serverless backends. And I saw that, and I was like, I like the way that sounds. I mean, that really resonates with me. Those servers exist. The developer doesn't have to think about them. And developer experience is just the most important thing, especially when you want to build really efficient solutions, tools that get out of your way like that. So I saw that article, and I was like, that's a cool word to describe what's happening here. And then I looked in the comments. And the comments were mostly positive, except for one or two people in the comments who just could not stand that the word serverless was being used, when there were clearly servers running in the background somewhere. And these people were furious about it. I thought, wow, look at these people. I can't believe they take this so seriously. This is hilariously controversial. So I saw that stuff. And I said, you know what? I'm going to take full advantage of this. So I made a badge. I love badges. We're a badge-oriented society. You can't go to the grocery store without buying stuff that has the right badges. You can't use code if it doesn't have the right badges. And I started to make these badges, and I decorated the whole project with them. And I sort of took it to the limit. So I wrote 100% server free. That was one badge. Another badge on the project said no server is guaranteed. I redid the tagline to say the serverless application framework. And I said, fine, let's do it. I hadn't posted it anywhere at that time. I said, you know what? I'm going to post this on Hacker News. It's going to get ripped to shreds because it's Hacker News, and it's full of puritanical lynchmob. Anyway, so why not? I mean, life's short. Be bold. I was riding high on cheap coffee as an open source project. So anyway, I put it on Hacker News. I didn't have any expectations. Most 99.99% of all stuff on there doesn't get seen at the end of the day. And I posted it, and I walked away. And I just distracted myself by building a sandwich of epic proportions or something. And I came back, and a few hours later, it was on the front page. Like number two position, hundreds of upvotes and comments, and the comments were all positive. And people were loving this. There was clearly a strong desire to use Lambda and to use it as much as possible to build entire applications on Lambda, but people didn't know how to do it because there wasn't a clear way forward. And this is what this project showed those people. So at that moment, the Hacker News posts, my life turned around. All of a sudden, tons of stars were coming into the GitHub repo, tons of issues. I was like, blog posts were being written about it. I was totally overwhelmed trying to solve all the issues and merge in the PRs. It was absolutely crazy every single day. Like 30, 40, 50, 60 stars were coming in. Meanwhile, Amazon loved this because they said, wow, this is making it really easy for people to use Lambda to do all types of stuff. So Amazon got behind the project. They started promoting it. They invited me to all these talks. They invited me to reinvent. They wrote tons of blog posts around it. And then maybe a month later, I ran into this next problem. And that was, it turns out JAWS is the name of a popular screen reader application. It helps the visually impaired have access to computers via audio and Braille. And all of a sudden, as the JAWS framework became more popular, it made it harder for the visually impaired community to find resources that they were looking for around their beloved screen reader application. And that was very frustrating to them. So I started to get these emails from this community saying, hey, please change your name. You're making it hard to find my screen reader application that I so desperately depend upon. And then I got tweets about it. And then they got into the GitHub issues. And they were writing stuff about it in there. And then they were in the Gitter chat room. And it became like a serious issue. So anyway, I was dealing with that. At the same time, some of the best venture capitalists in the valley saw what was happening. They saw the response from developers. And they said, Austin, what do you want to do with this thing? We'd like to fund it. And I said, oh my god, this project, this open source project, it's wrote it on this couch in this cheap coffee shop. And now I have a chance to work on this full time and build a team around it and build all these great serverless projects. I was telling them about this name thing. And it turns out that the screen reader application also trademarked the name JAWS. We didn't run into issues with the movie or anything like that. It was mostly just this other piece of software. And they had a shark logo and stuff. And the investors were like, what are you going to do about this? It's like, we want to fund this thing. But I don't know. You've got to do something about the name. So I was thinking about it. I was like, I had to make a quick decision. And I thought, what is the best way to tell this story? I had the framework. By that time, I had 40 other serverless related projects that I wanted to do. I mean, I'm such a fanboy in this space. And I went with serverless. It was blatant. It was obvious. And we rebranded JAWS to the serverless framework. And a few months later, we established serverless Inc. At the same time, meanwhile, on a parallel timeline, Amazon Web Services and the marketing machine they have there in the developer community, was starting to invest heavily in the serverless buzzword. And that was clearly promoting it to everybody. Oh, I had a donation link on my GitHub repo because I had a lot of traction. And I was hopefully hoping someone would sponsor the project and help support me before I raised funding and everything. And the visually impaired community actually would donate and kindly ask me to change the name even there. So anyway, it's just one thing after another in life. Anyway, so users and use cases. So immediately I saw tons of interesting activity on the repository. I saw hobbyists come start using Lambda for different things that they're working on, the weekend warriors. And I thought, OK, they're expected. And then startups came. And I said, of course, this is exactly what startups need right now. And then I saw big enterprise companies come and start hanging around the repository, start hanging around the Lambda community. And I thought, and these are Fortune 100 companies. And I thought, wow, this is weird. I can't believe that they're here for something that's so raw. But at the end of the day, Lambda is nothing but EC2. It's just been rebranded, it's been repriced, remarketed. It's basically the tried and true infrastructure that the enterprise has already adopted. So they've been quick to switch stuff over to Lambda at a faster rate than I've ever seen enterprise move before. Next up came consultants. Consulting firms love serverless architectures because it's a very easy thing to hand off to a client because a lot of the operations is eliminated from the picture. A lot of people from the container community would come over. Also other application frameworks, Express, Meteor. A lot of those people hang around the repository now around the project. And at the end of the day, there's so much diversity, it's so early still, but there's so much diversity and interesting people in this space. I think it's just because it's so darn efficient, that same efficiency I was looking for and that I found initially in Lambda has brought everybody to the table. I don't think this is a fad. This isn't a fad. This is just like the logical evolution of cloud computing. And it's like a 10x step forward. So that's why all these people are here. Meanwhile, the use cases started to vary like crazy, too. So at first, people were using it for data processing stuff, processing DynamoDB streams, something like that. That's kind of what Lambda was originally built for. And then they started using it for REST APIs, building entire REST APIs on Lambda. And then IoT apps, of course, very easy to provision a Lambda function or two to manage an IoT back end. Chatbots, of course, for the same reason. DevOps, automation, and tooling. I've seen amazing stuff that people are building to automate sort of their DevOps and their internal processes. People are building their own CI, CD systems. People are training lambdas to autoscale other types of resources. They're building their own pager duty stuff, all types of things. Compression systems. Most people will make an orchestrator Lambda function that will spin up tens of thousands of other Lambda functions to all compress like a frame and a video or something like that. And just amazing stuff is there's no end to all the types of things that people are trying to put in Lambda functions. And again, the reason is the same. It's efficient. It's convenient. It's like the most convenient cloud computing service around. So as a result, people want to use it for everything. Success stories. Soon after these crowds showed up and these use cases started to emerge, then success stories started to pour in. Now the big ones usually are around apps with spiky loads. A lot of people will have applications. They'll be paying hundreds, thousands of dollars a month to keep these things afloat on traditional infrastructure. And of course, maybe they'll get a spiky load and all of a sudden that stuff will crash. They weren't ready for it for whatever reason. So a lot of people are converting that stuff over to Lambda. And Lambda is reducing costs like crazy for these people. Again, you only pay for what you use. So regularly we'll see people who are spending hundreds or thousands of dollars on something reduce those costs to a few dollars or even cents. The best example, this is the newest example that I've seen, the best success story. This just happened like a few weeks ago, is this thing called the census fail. The government of Australia decided to do the census online this time. And they wanted to encourage everybody to go home to their computers, go on their website, and fill out the census there. They spent $9 million creating a survey site. That's all it was really. It was pretty simple. They contracted a big technology company to help them build it. They low tested it for tens of millions of people. And of course, when they launched it, everybody came home from work. They logged on, and the website crashed. It was gone, $9 million. The last I've read, they've received so little input that they can't even really do anything with the census data because it's not a big enough amount of data in terms of the entire population. So that whole thing pretty much crashed and burned. Meanwhile, a couple of young guys at a hackathon at Australian University a week later said, look, let's just recreate the census website and let's build it on lambda and see what happens. So they just scraped, they copied all the HTML, they recreated the census website perfectly. They built a simple lambda function in about 24 hours to handle collecting the survey data. And then they low tested it against tens of millions of requests. And all of a sudden, their story went viral. Because a whole bunch of big newspapers picked it up. And it turns out they were able to do all of that for 250 bucks. Not only that, I called those guys immediately because I said, I love this type of story. I'm all about the underdog and everything. And I was talking to them about it. And they said, yeah, that press number, we put it out there, it was really conservative. The real cost was $30. Anyway, people are using Lambda today, big enterprise companies. And they're using the serverless framework to handle to do billions of lambda function invocations a month. This is happening right now. And the teams I see that are managing all this are usually one engineer, one or two sometimes handling all this traffic. It's phenomenal. So fast forward to today. More serverless compute services are around. A lot of the big technology companies saw what was happening with Lambda. And they said, whoa, we've got to get in on this. So now we have Google Cloud Functions. Looks like an amazing service. Azure has Azure functions. Also, another cool looking service, IBM OpenWISC Actions. Tons of other smaller providers are jumping into the space. It's awesome because there's going to be more diversity here. Meanwhile, Lambda is improving every single day. AWS keeps making it more mature, more stable, adding fantastic features. Another trend we're seeing now is that enterprise companies are making serverless teams. They'll start out with one person who's a champion of Lambda or the serverless framework or something. And the other people in the company will start handing them workloads. Like, hey, can you put this in a Lambda function? And that person's like, yeah, I'll put it in a Lambda function. I'm done. And it's 10 times cheaper than what you had. And I have more time to do other stuff now. So these serverless teams are growing. People keep handing them workloads. And this is an awesome trend. I will say, though, as far as Costco, Lambda is definitely more expensive than what you can squeeze out of EC2 at a really high volume. Now, that is if you're running EC2 at 100% utilization, which is pretty rare. And the truth is a lot of people are running their infrastructure at very low utilization rates. And the great thing about Lambda is that there's no such thing as underutilization, because you're not going to get charged unless that code actually runs. Meanwhile, serverless Inc. 12 people. We've got 12 people now. It's been incredible. We've got some great VC firms backing us. We're working on the framework every single day. It's been a year now, just focused on Lambda and serverless architectures. Serverless Framework version one is coming out of beta this month. It's super powerful. We put in a lot of effort into it. And version one of the framework has only been, I'd say, feature complete for about a month. But already, people are deploying about 30,000 functions with the framework a week right now. All right. How to get started? Let's chat a bit about the framework. It's hands down the easiest way to do this. Again, we've been working on it for so long. It handles everything for you. Scaffolding, automation, optimizations, best practices, it's all baked in. So it's a CLI tool. It's written in Node.js. You can install it with NPM. And it treats Lambda as the focal point of AWS. So there's a lot of tools out there that help you do AWS stuff. What the serverless framework does, though, is it has a theory. And that theory is that Lambda will be the focal point of AWS Cloud. It'll be the foundation on which you will build most stuff on in AWS in the future. And it interprets AWS from the perspective of Lambda. And that's kind of our mission statement there. So also, with the framework, it manages your code, but it also manages your infrastructure. So managing deploying, zipping up Lambda functions, that's only half the battle. Coordinating those Lambda functions and making sure they're tightly coupled with other infrastructure resources that you're using, that's the other half of the battle. So this is a bit unusual of a framework in that it manages the code as well as your infrastructure. But the great thing is you can provision your functions, your events, all the wiring you need to trigger these functions, as well as your infrastructure in one command. It's really a beautiful thing. And also, we do this because we're just an abstraction on top of CloudFormation. We didn't used to be embrace CloudFormation fully, but it's really come a long way. It now has support for all of these serverless features on AWS. And so version one is built on CloudFormation and therefore much, much more stable. So did a lot of learnings in version zero. That was inevitable. We were trailblazing. It's a whole new world. And we noticed a few things. Number one, project thinking is kind of too big for this. It tends to lead into monolithic thinking, whereas we're very much focused on solving microservice problems in the framework. So for example, we used to have a project where you put all your Lambda functions in there. And that project would share one CloudFormation template, which would define all the infrastructure resources that those Lambda functions would require. And it would also have one REST API, one API gateway REST API, which all those Lambda functions would share. And that was cool for smaller projects, but then all of a sudden those projects grew. And multiple teams would be working on these things. And all of a sudden, you have this person over here who manages the CloudFormation stuff, this person over here who manages the API gateway stuff, and then your Lambda teams are saying, like, hey, can you provision that infrastructure so we could push this stuff to production? Or can you provision this endpoint so that we could test out our functions? And so that quickly led to blocking issues. So this whole project thinking is just not right for this. In our world, everything is a service. I don't even think that there's any real project-level thinking anymore, application-level thinking. There's only ever-expanding networks of logic connected by events. Meanwhile, functions are too small. If you just have a whole bunch of different functions, again, if you're doing NPM install, if you want to install a new library or something, and you have 20 functions, that's NPM install, NPM install, NPM install, and that gets old really, really fast. Fortunately, what we noticed was that functions travel in herds, in groups. These are usually groups of four or five functions. And the reason this happens is because these functions all usually share a data model. So in the example above, you can see the user's CRUD example. Here's a group of functions at the top, four functions handling. Each handles one of the CRUD operations. And these things all share these infrastructure resources. So they kind of travel together. So we came out with this serverless service concept. We have very few concepts in the framework. We're trying to keep it that way. There are functions. There are events, anything that could trigger your function to execute. And then there are serverless services. And a serverless service is the middle unit of organization. It's a little bit smaller than a project. It's a little bit bigger than a function. You could have one function in a serverless service or multiple functions if you want. But code infrastructure coupled nicely together. It's an independent CloudFormation stack. So again, we're just an abstraction on top of AWS CloudFormation. You get to define all this stuff really easily in a serverless.yml file. So you have a folder. You have serverless.yml. In that file, you'll describe the name of the service, the functions, the events that trigger them, as well as the resources, the infrastructure that those functions depend upon. And this is just a really neat unit of organization. It's solved a lot of our problems. And whenever these things are deployed, whenever you deploy a serverless service in one region or another region or another stage, you're just creating a separate CloudFormation stack. So there's just perfect, simply comprehensible separation of concerns. All right. Let's see if this demo works. I was trying the internet connection out earlier. It was a little iffy. But let's dig in and see what this stuff actually looks like. So serverless, it's a NPM package. It's a little bigger. You can install it with NPM install serverless. I'm not going to do that right now because it might be too complicated. So instead, I have it installed on my machine. I can run SLS. I can see the commands. It does. First thing I'm going to do is make a directory, lcd into that directory. And I will run. You could type in serverless, or if you are lazy, like most of our users actually. So you could do serverless create. You could just use SLS. So I'm going to create a new serverless service right now running serverless create. I'm going to throw in a template. And these templates specify the provider as well as the runtime. Now serverless framework version one, we're expanding it to support multiple providers because there's all these new players in the game. And they all have really interesting technologies and developers deserve options at the end of the day. I mean, there's just nothing better than having sort of freedom in what you choose to use. So the first part of the template is the provider. The second part of the template is the runtime. I'm going to make something on AWS in Node.js. Cool little serverless graphic. And now we have some scaffolding. Very simple event.json. Not really important for this talk, but handler.js contains our code. serverless.yaml defines our serverless service. Let's open it up. Let's see what it looks like. I'm sorry, that's a little bit small for you. OK, handler.js. Here's our code. Here's our function. In here, we're going to display a simple message and the event object, which is going to get. We're going to make a simple REST API endpoint. The event object contains all the information about that incoming request. I'll put it in here. And here's serverless.yaml. We put tons of comments in here to help you get started right away. I'm going to rename the service real quick. Users, full stack, FES2. Here's some provider information. Here are your functions. There's one function called hello. It points to the handler, which is pointing to this file and this function in that file. So serverless framework is going to deploy this whole folder, this whole user's folder. It's going to send that up in every single lambda function. So let's put some events here. We need to trigger this function. We need to make it work somehow. We're going to create an HTTP request. We're going to put in a path. Let's do users. Let's say this is our users create function. We'll do method. We'll do the get method. And there you go. Everything that triggers a function to run can be tucked in under this events property here. And we're just going to set this up. Looks like everything is good. And I'm going to run serverless deploy. Run the speakers thing. OK. So serverless is going to take the functions. It's going to take all the infrastructure, the API gateway endpoint that we just specified, put this together in a CloudFormation template, and deploy that as a new CloudFormation stack. Now, the initial deployment takes a few minutes. And it's something that constantly bugs us. But at the end of the day, it's creating IM resources on AWS. And those IM resources have to be globally replicated before they're ready to go. So the first deployment is always the slowest. And while that's going on, I'm just going to chat a bit about code patterns, how people are partitioning in Lambda functions. So first off, I talked a bit about the one job per function approach. This is by far the most common. We call this the microservice approach. You take some code, it does one job. Like this function resizes an image. You put that in a Lambda function, you deploy it. Or this function saves the user to the database. You deploy that. You put up one endpoint on that too if it's a back end service. The next pattern is the services pattern, which is a few related jobs. People will put in a few jobs in a single Lambda function and then use something like just the API gateway dashboard of the serverless framework to hook up multiple HTTP end points to that single function. So this would be great for a user's crud Lambda function. I just have all the crud operations in the single Lambda function. And the reason why people are doing this is because Lambda has a bit of a startup cost, a bit of a cold start cost. And if you put more logic in a Lambda function, then the likelihood that it'll be called more often to keep it warm is greater. So this is why people are doing that. They're also, they kind of just want to get rid of multiple Lambda functions at the end of the day, and it's a good way to consolidate them. So we see the services pattern. It's really easy to hook up multiple end points to a function. Like I just hooked up one endpoint. You can actually inspect the incoming request and put it like a little, like four lines of code, a router that says, oh, this incoming request is for the user create function. And let me route it inside my Lambda. Monolithic, people are actually putting entire applications in Lambda functions. It seems crazy to me. It seems kind of like going backwards, but people are doing it. And you know what, the power to them. Why not the serverless framework lets you do all that stuff? Go for it. The graph, the graph pattern, I love this one because I'm just like crazy about efficiency and pragmatism and the GraphQL to me seems awesome already. You take GraphQL, you put it in a compute service that's pay-per-execution, zero administration, and that is beautiful. So what this is, GraphQL, it's a library. You put it in your Lambda function. It sits in front of multiple data sources. And so you take a single Lambda function, you put GraphQL in there, and you hook up that Lambda function to one endpoint. You only need one endpoint. You don't need a REST API with a ton of endpoints anymore. You have one endpoint. And in there, you send a custom data request with a custom shape. And it could be requesting, it could be in that request, you could be querying multiple data sources and polling in attributes from the resulting records, all combined in this one request. So that incoming request comes in, it hits GraphQL, GraphQL queries all the appropriate sources concurrently. It pulls in the data records, reshapes them to match the shape of your incoming request and spits that right back out. And it's awesome efficiency. I know there's another GraphQL talk, so I won't go into it in too much detail, but definitely check it out. We have a secret project that we're working on that has a GraphQL Lambda function with that single endpoint approach. So we're using this pattern ourselves. That Lambda function actually sits ahead in front of another tier of Lambda functions, which each contain a query that GraphQL does. We first started to put all our query logic in a single Lambda function. That became like a monolithic Lambda, but by spreading these out in two tiers of Lambdas, it's working really nicely for us. Oh no, we have an error. Affirmation service may not be available in US East One. This is a speaker's worst nightmare. I haven't done anything strange in here. We have our events, we have our functions. Oh, this is so frustrating. The magic moment is coming up and I can't get to it. All right, let's just look at this. While this is going on in the background, I'll try running it one more time. Oh, it worked, perfect. Awesome. I don't know what was up with that before. I ran the same command again and it's working. So we deployed a Lambda function, deployed an endpoint, and here you go. Serverless framework, it just goes and collects all this information for you. It returns it in the terminal. And here's our endpoint, here's the ARN for our function as well. I will take this new endpoint. And if my look will continue, what we have here is a REST API endpoint. Hey, per execution, REST API endpoint, zero administration, you know, if I wasn't talking so much and blabbering, I could have done this in like a few seconds. Well, a few minutes with that initial deploy. But there you go. What's happening here is that all the incoming request information is being passed right into the Lambda function and we're actually returning all that, so this is all the great data we have to work with. If you try and do this manually on API Gateway, you have to like specify all these different things to like go into your Lambda function, otherwise that HTTP request information will not be passing your Lambda function. And now, to quickly iterate on this, I'm gonna take away this event stuff. I'm gonna say your function was updated. Just modify my function slightly and all I have to do here is use our new deploy function command, which happens a lot faster. There we go. I've just updated my function. I'll refresh. Done. Right? That is a beautiful thing. You can hook up your Lambda functions to all types of events. You specify it in the YAML. We're reducing like a crazy cloud formation template, which normally would have like hundreds or, you know, multiples of hundreds of lines to like 30 lines in serverless.yaml. Super easy to use. And there you go. I mean, just build anything that you wanna build. I'm running out of time, so I'm just going to cut the demo a little bit short. We're not gonna do logging or anything like that. We do have so many other cool things happening in the framework though. It has a whole plugin architecture, so if you wanna extend the framework to do whatever it is you wanna do, workflows are so subjective at the end of the day, you could just write a plugin to overwrite the existing functionality in the framework or extend that functionality. So for example, we're working on this plugin. It just watches your code every time you hit save. It'll just go deploy it in the background for you. And just so you have sort of continuous deployments. Where is this all going? Like what's the end game of this stuff? I really have no idea. I have a few theories. What started Lambda was a venture of an architectures. And the whole serverless movement is really kind of defining a venture of an architectures where the compute services are zoo administration and paper execution, microservice based. But AWS has been on this tear for the last few years of building infrastructure services so that anybody can construct their own venture of an architectures easily. And serverless, the movement I think has kind of been a distraction from the cool stuff that's happening overall in your ability to build a venture of an architectures. So again, I don't think that there's any application boundaries in the future. I think that there's just like the developer and their ability to infinitely compose logic and create these ever expanding networks of logic all connected by events. I think other people will create networks of logic. These networks of logic can be combined and then you respond to other people's events. I also see huge opportunities for dry here. I mean, just imagine being able to run other people's Lambda functions on a paper execution basis, right? There's so much common application code that we write and rewrite for every single application. That stuff doesn't need to be written over and over again. Your custom code needs to be written. You're like the stuff where you actually solve business problems, that needs to be written. But like sending out a transactional email doing stuff like that, that should be written once and you should be able to run that other person's code on a paper execution basis. I think that would be awesome. And that's it. Thank you, Fullstack Fest, Codegram. I mean, this has been a great, great conference. Thank you. Thank you.