The 2020 Guide to Serverless Fullstack Apps - Austen Collins

Hello everyone, I should be sharing my screen. Okay, and let me know if you don't see it in the chat. My name is Austen Collins. I created a popular open source project called the Serverless Framework back in 2015, a long time ago. I'm in my fifth year of doing serverless stuff. I'm also the founder and CEO of a company called Serverless Inc, where we make serverless development tools. Our goal is to give every developer zero friction development tools for building out serverless applications. I'm also an AWS Community Hero, and I'm super excited to participate in the first Sri Lanka AWS Community Day. I wish I was there in person, that would be a lot more fun. In fact, I'm actually recording this session from a hotel room because my girlfriend and I had to leave San Francisco because it's just filled with wildfire smoke right now. Hopefully the internet connection is pretty stable and everything goes smoothly here.

Denio did a great overview of a lot of different use cases and a lot of service use cases on top of AWS. I'd like to take this presentation's focus in the direction of just one use case, and that's serverless full stack apps. These are one of the most popular serverless use cases out there. We've been building serverless backends, serverless front ends, full stack apps for multiple years now, and I wanted to share a lot of the learnings that we've had as the makers of Serverless Framework, working with a ton of different teams building out full stack apps over the years, as well as our own learnings, how we operate internally, and how we think about building serverless full stack apps differently in the year 2020. This is going to be a presentation highlighting a handful of principles that we feel are important in our company, and also I'm going to mix it up with some demos because I want to make sure that everyone who watches this is able to get a serverless full stack application deployed in the cloud as easily as possible. So let's get started.

Our goal here is to get a serverless full stack application deployed. Here's how I describe that full stack application that we're going to deploy. It's built on AWS Lambda for the backend, and within AWS Lambda we're going to be using Express.js. Additionally, we're using Amazon's new API Gateway product, it's HTTP API, which I believe is about 50% cheaper than their original API Gateway product and a lot faster. We'll be setting up a custom domain on Route 53 as well as a free AWS ACM SSL certificate, so you have a true production ready serverless full stack application at the end of this, with a custom domain, SSL certificate, everything you need to go into production. I will be using a base DynamoDB because it is one of the optimal databases to use in the serverless architecture, and React on the front end.

Now, what's the big deal here about this type of serverless architecture for full stack applications? Well, number one is the auto scaling, of course. This is the thing that really brings people to serverless. They just want things to scale with the least amount of maintenance and effort involved. So this full stack application is going to scale automatically out of the box, massively, to serve millions and millions of users. Additionally, the other great quality of serverless is never pay for idle. Most of this entire application is not going to cost you anything until a user actually goes to it and interacts with it. When they do interact with it, specifically the backend is going to cost you probably around 0.0000 cents per request, and you could actually optimize it to make it a lot cheaper than that. We benchmarked this stack, we actually used this stack a lot for our own services over at Serverless Inc, and you'll typically get about a 90 millisecond average response time in the backend if you do one or two DynamoDB requests.

So why is serverless architecture optimal for full stack applications? Why should you care about this? Because what we're working on here, what we're going to deploy, is one of the most efficient architecture technology stacks around. If your big goal is to build more and manage less, focus on product, get to market as fast as possible with the least amount of overhead, this application architecture is hard to beat. This is probably the most efficient application architecture around. So we use this for as much as possible. There's really got to be a strong reason to not use this within our company because we know the benefits are just too great, and we care a lot about innovating and moving quickly.

To cut through the suspense and make sure this feels accessible and approachable and attainable to everybody, I'm just going to deploy the whole application right now within a few seconds. Here I've got my terminal, I've got the Serverless Framework installed. The Serverless Framework is a CLI, open source, you can install it via npm, just run npm install serverless and then throw in the global flag. I'm going to run serverless deploy in my full stack app project. Just to give you a brief overview as to how this thing is structured, there's a folder that has a single Lambda function and database HTTP API Gateway, that's the backend. There is another folder which contains the database infrastructure, and then another folder which contains the IAM role which gives the Lambda function access to the database, controls all permissions within my backend. And lastly, there's a website, there's a front end, all built on serverless infrastructure as well, using AWS CloudFront, AWS S3 to host a static website that's really efficient, really cheap, and massively scaling.

So here we are, we're up and running. To cut through this suspense, this is live right now. You can go to serverless-fullstack-dash-app.com, and you'll see there's a basic single page application on the front end that is running React, and this is interacting with our serverless backend right now. You can go ahead and register or log in, and you'll see a bare bones dashboard, protected dashboard. This kind of has some code written already to give you basic scaffolding for public API endpoints and private API endpoints, so that you could deliver this. And that was it. We deployed that in 20, 30 seconds pretty quickly. It's up in the cloud, custom domain, SSL certificate, you can see that here. That's how easy it is. But there's a lot more fantastic qualities about this and things you should know when you're building out an application like this, which I'm going to jump into now.

Another big note: great serverless apps are built by great serverless teams, and I cannot overstate the importance of this. This is something that we have to think about at our company a lot because we make tools. There is an important difference between the solo developer who's just working on their weekend project, trying to innovate quickly and get stuff off the ground as fast as possible, and a team that is working on a larger serverless application that's got a lot of functionality and they still want to innovate as fast as possible, but they've got to solve the problem of collaboration. Not only that, they have to solve the problem of collaboration on a cloud architecture that contains probably more cloud resources than any other architecture out there. The art of collaborating on something like that and scaling out the project in the team is a totally different situation.

A lot of times when you talk to people about serverless architectures, people will say you've got to do this or leverage this type of workflow and do it like this. I'd be careful. You have to qualify that and say, is that good for just a really small team or a solo developer, or can that scale to support a larger serverless architecture, a larger serverless team? As I talk through these principles and talk through how to architect these applications and the workflow behind it, I'm going to be approaching it from both sides: a solo developer, how they get up and running fast like I just showed off deploying a serverless full stack application in 20 to 30 seconds, and then how that scales so that a team can work on that. What we care a lot about in the serverless world is moving quickly, innovating with a lot of autonomy. Even if you have a big team working on a lot of cloud infrastructure, how do you preserve that autonomy so that people can go innovate, not be blocked, and deploy without also risking the application as a whole? And of course, focus and rapid productivity and development. I'm going to be talking about everything from these two sides, and those are important when you're setting up any type of serverless architecture from the beginning. There's a lot of stuff you could do early on to make sure it scales.

The thing to understand about serverless is that like any architecture, it will get complex. Over here on the right is a typical serverless architecture, and you'll see this a lot. This is probably still a fairly simple architecture, but the first thing to note is the amount of infrastructure that's involved here. Serverless again, you're going to be using a lot of cloud infrastructure, and that's stuff that only exists on the cloud. A big part of serverless philosophy is that you don't want to write as much code, you don't want to own as many parts of your technology stack, you want to try and outsource that as much as possible so that you focus on the things that really matter to differentiate your product and your business in the world. But the logical outcome of that is you end up using a lot of infrastructure. So these architectures will get complex, and again, any architecture will get complex. Any big project, application stack, as that starts scaling, it's going to get complex. There's complexity all over the place. So we're going to try and talk through how to avoid that, but this is what you'll be dealing with at the end of the day, and it's hard to avoid, so might as well be aware of it. Let's acknowledge it up front and now let's start simplifying it and making it easier.

A big principle of ours in 2020 when we approached serverless full stack applications is not microservices, which was kind of what a lot of people were talking about. Serverless first got off the ground because microservice architectures were very much growing in popularity, and Lambda came in at just the right time, making microservices solving a lot of the microservice pain points just by auto scaling and never paying for idle. When you leverage a microservice architecture, you inherit a lot more complexity. You've got a lot more units of deployment, different things you have to monitor and ensure is running reliably. Now Lambda came in and made that a lot easier by reducing a lot of the overhead. At the end of the day, however, when you look at if you know that this is where you're ending up and you know that this is inevitable, you're going to head into this. What we've learned is we like to actually start grouping logic on Lambda functions instead of leveraging a microservice architecture that has one task per function, because if you go that route, you're going to end up with a lot of units of deployment to manage. Each one of those has infrastructure dependencies, and also in 2020, one thing that's definitely changed is Lambda is a little bit more configuration rich than it was previously. Another way of saying that is it's a little bit more complicated. There's just a lot more stuff to be aware of in each Lambda function, and of course you have permissions management on top of all this stuff.

Today, the thing that we advocate most is microservices maybe if you really understand what you're getting into and you want to go that route, but again, there's a lot of infrastructure complexity that will come out of that that might take up some of your focus and some of your time. However, we also don't think monolithic is still the right approach. We think it's still important to maintain separation of concerns, so we think SOA is the right balance between maintaining those separation concerns while still reducing the infrastructure dependencies to better scale your project and team. The goal is we're going to try and just take some of this infrastructure graph and start clumping stuff together in services so that there's just less stuff at the end of the day on this graph. Specifically, this means grouping a single Lambda function, a single Lambda backend around application domains. Like this one could be in charge of users, it's great if you map it to a data model, or this one is in charge of blog posts, this one's in charge of comments. Each Lambda can handle multiple API routes that handle that business domain, but just be aware of building out that monolith. We've practiced this ourselves. We've built a ton of functionality that's all running on probably 60 Lambda functions. It's pretty incredible, it's pretty efficient, highly recommended.

In addition with that, we do recommend monorepos. I know this is a very controversial topic certainly, but we put all of our services in a single repo. The typical monorepo benefits are there: one place to collaborate, one place to oversee, one place to track issues, see everything, and centralize your documentation. But something else that you may want to think about getting started is just having a great SDK with your product, with your full stack application. Great products are extensible, great products usually have SDKs. So what we like to do is in that repo with a lot of different services, we like to include an SDK right in that repo, and we mandate that all communication across all services and front end and backend communication, client and serverless side communication, everything has to be done through that SDK. We forbid hard-coding API endpoints and calling those directly. No, we say everybody works through the SDK, and through that, everybody is testing, battle testing the SDK, and we get a great SDK at the end of the day, which is fantastic when shipping a product to the market. And with the SDK and that monorepo, you could leverage it for all your tests, which makes testing a lot easier. So that's how we prefer to structure.

Standardizing on an app framework, this is a big one. We worked with a lot of teams starting in 2015 going all the way to 2020 now. One thing that you wouldn't think would be such a big deal that gets a lot of teams is, first off, Lambda is designed around functions, that functional model, the single function signature which you put all your business logic in. But of course, we need to build a backend that handles HTTP requests. What happens is most teams can't quite figure out how to fit, or they don't think it's necessary at first, to put a common standard web framework in Lambda, and they always end up building their own web frameworks as a result of this. A lot of issues that we run into are made worse as soon as we look at the backend, we realize the team has come up with their own Lambda web framework on top of Lambda, and you want to avoid that. I know it seems easy at first, and you can say I'm just going to build a simple router in my Lambda function, but be careful because it's going to be hard to scale, and all of a sudden your team is building a new web framework for the world, and it's a distraction and it makes everything more complicated. So instead, use the existing framework: Express.js, Flask for Python, Jeremy Daly who's talking at this conference has a Lambda API which is great. It's a standard, these are open source standards, and the documentation, the principles, the way you use it is well documented, so you're not trying to figure that out.

For us, we actually have with Serverless Framework now a new concept called Components, which allow you to deploy specific use cases that combine a lot of infrastructure and also use common application frameworks, so you don't have to figure out how to do all that. To show you what this looks like, here you'll see serverless express is a component you could use. It's basically a library that will deploy Lambda, HTTP API, custom domain, and a free SSL certificate on AWS, and package an existing Express application on top of all that, so you don't have to think about it. It's going to configure it all with best practices and the best type of architecture for scale and performance, and from an economics perspective as well. That's the first thing I'm using here as part of this. You can see this is how simple it is. There's a simple serverless.yaml, which is the declarative file for a Serverless Framework project, and here you just say I want to leverage the Express component, here's the version, I'm going to instantiate this component, I'm going to call it my API, and every component has simple inputs. Components work very easily, you just add in your inputs and it returns outputs after it's deployed. The inputs are simple, you don't have to worry about all the configuration complexity, although there's a lot of options here that you would if you were actually working with the lower level pieces and trying to figure out how to put HTTP API Lambda together. You don't have to worry about this. This will actually package up your existing Express application and deploy it and give you a lot of other benefits, which I'll get into in a second.

Another big thing to be aware of: separating your infrastructure from code. This is a huge one. If I go into our support system right now today, a lot of our support requests, the urgent and critical ones, are from people who combined all their infrastructure, Lambdas, IAM roles, DynamoDB tables, DNS stuff, VPC configurations, in a single infrastructure stack, and they deploy that and it's a huge infrastructure stack, a huge CloudFormation stack typically. They deploy that and often they'll run into issues because they're deploying that all the time. Of course, when you're deploying everything all the time, the likelihood of something going wrong with the deployment is much higher. A lot of these people might have messed up some configuration, and they were just simply trying to deploy a code change, but they ended up messing up something to do with the database or getting their CloudFormation in an infamous update rollback failed state, and they can't figure out how to get their CloudFormation stack out of that state. So this is huge. The way to get around this is to separate your infrastructure resources, the stuff you deploy infrequently like a database, from the resources you deploy frequently like your AWS Lambda. Don't deploy your database 50 times a day, but you want to be in a position to deploy your code 50 times a day. But you don't want to be deploying the database with that. So be careful of this. This is a lot of our support requests. I know it's tempting just to throw everything together, it feels really convenient, but if you could master that separation of concerns, it's going to make a huge difference in the ability for your team to work on pieces without affecting the system as a whole. So again, preserving autonomy, separation concerns, all that is huge here.

Here's how we do that in this full stack application. Let's go ahead and look at the other parts of this. This is a separate project that deploys the Express backend, Lambda HTTP API, serverless express out of the box, very simple. But we also have an IAM role here which gives my Express app permissions, that Lambda function permissions to interact with other resources like DynamoDB. And there's a database here as well. Now this is a single DynamoDB table that's powering that sign up form that I showed off earlier. When I deployed everything together, the Serverless Framework, if you're in the parent folder, the Serverless Framework will deploy all your projects in subfolders, and it's going to look at references because again, components, these are all built on new Serverless Framework components, and each one takes inputs and exports outputs. You can see here that there are references built into the inputs. So my Express app is actually referencing an output from my permission stack, and it's referencing the name of that, so I'm inheriting that in here, as well as my database name and a global secondary index name as well. The Serverless Framework will look at these references and it'll set up a graph and deploy things that need to be deployed first based on the simple references. But here, I could go in and not only deploy everything together, but if I really wanted to, I could actually go into my permissions here and say, okay, I want to give my Express backend access to a new resource, so I'll just go ahead and run a deploy on this individual project. I forgot to pass in the correct stage here, so this is not going to deploy to my production stage. Let me go ahead and deploy it to prod, and that's it. Within a few seconds, I've pushed a change up to my IAM role which governs permissions for my Express backend.

If you notice here, something we've been working on a lot at Serverless is super fast deployments. We've got a goal that we want to get deployments to around three seconds. So a lot of stuff I'm going to be showing off here is built on our own provisioning technology, and our goal is push to the cloud as fast as you'd hit the save button one day, and that's what we're racing towards. I'll show you why that really matters in just a bit. But here, you can go ahead and you have that separation concerns, deploy your IAM role, deploy your database when you make changes to those specific things. Don't deploy changes to everything else that you didn't change. So that's how you maintain separation concerns, that's how you'd scale that out.

Here's a big game-changing idea for 2020. It's very different from how we started doing serverless development in 2015, 2016, 2017. This idea is to develop on the cloud. Specifically, this means when you're developing, you deploy every change to the live cloud infrastructure, the same infrastructure that's running your production environment. The reason for this is local emulation is great, it's what we're used to, we love spinning up applications on our computer, and it's what we've done for many, many years. It's harder with serverless because these services only exist on the cloud. When you're just getting started, the temptation is to just emulate the stuff locally and do some emulation. Serverless Framework does this as well, you could emulate Lambda functions, you could emulate API Gateway, you could emulate a lot of stuff. We've invested years in making that experience great, and it's always easy at first. But as your project and team scales, I cannot tell you the complex local emulations I've seen that companies have started to maintain as their team and project scales. What happens, of course, is again that infrastructure graph, that architecture diagram that I showed off early on, that's where you're heading whether you like it or not. It's fine, you can manage it, but if you're going to go the local emulation route, all of a sudden I've seen teams, so many companies end up in a situation where they're basically trying to recreate Amazon Web Services locally on their computer. The time that they put in to maintaining that emulation, all the different ways to kind of boot it up, all the knowledge sharing they have to do across the new engineers joining the team, is like the time that they're saving by not having to scale out their infrastructure at the end of the day. So the time savings that they got by leveraging serverless technology is now getting sunk into maintaining this complex local emulation. We don't want to do that. Be wary of that path. Also, the big challenge here is that emulation never matches your cloud environment. It works locally, and then you push it onto the cloud and you're going to run into issues. So find a way to develop on the cloud and deploy every change to the cloud.

Now that sounds easier than it has been, because the reason why a lot of people also emulate locally is that deployments are just too darn slow. A lot of the infrastructure provisioning technologies, your Terraform, your CloudFormation, they deploy pretty slowly. If you're a developer, of course any developer is not going to want to wait a minute to a couple of minutes to deploy a single line code change to the cloud. This is the experience they run into when they first start doing serverless development. They're like, I'm not going to wait for this to roll out to the cloud, I'm going to try and emulate things locally. So again, this is what prompted our principle of we want to get deployments down to three seconds and less over at Serverless. So fast deployments are something that we're really striving for here, so that again, every code change you could just push it to the live serverless infrastructure without having to worry, without having to slow down, without having to compromise your developer productivity, your flow, your focus, and then maintain a complex local emulation.

Here's what this looks like actually. I showed off how easy it was to deploy an Express application pretty quickly. I'll go ahead and deploy that once more. I'm going to deploy this Express app, and here you'll see there's no Lambda in here, there's really no trace of Lambda, there's no function signature. This is all about making an existing Express app automatically be packaged onto AWS Lambda without having to think about Lambda as much. That's the beauty of this Serverless Framework component. Again, nine seconds, doing lots of video sharing on a hotel Wi-Fi connection, deploying my Express app here is pretty darn good. But this gets better. To improve development on the cloud, we wanted to kind of recreate all the experiences that developers have when they're doing a local emulation. What developers get when they're emulating, when they're working locally, is they get fast changes of course, but they also get logs streaming right into their console. I deployed to my dev stage, so I'm going to switch over to my production stage real quick. But what you get when you're working locally, you get streaming logs, you get streaming errors, you get fast feedback, fast changes and fast feedback, table stakes for any fast developer experience. You lose that stuff when you move to working natively on the cloud. So we just showed off fast deployments, and now this is Serverless Dev Mode. This is going to try and recreate that local experience that developers are used to.

When I run serverless dev mode, it's going to start watching my code. Let's just go ahead and hit this API itself. This is my Express app, it's just returning some basic responses. I've got a test route here, you can see test route was responded successfully as the response. I'm going to go ahead and update this. Dev mode is great because it watches for changes, and on every change, every time you hit save, it's going to use our fast deployment technology to go ahead and redeploy your Express application to the cloud within seconds. And that's it. There it is on the real serverless infrastructure that you'd be using in production. There's not going to be any change when you push this into production into different stages, you won't get any nasty surprises because this is the real deal. It gets better. You can see here when I am interacting in dev mode with this endpoint, you'll see a couple things being streamed into the console in real time. You'll see a transaction record here that says the HTTP method and the path, as well as I've got a console log statement here that just says test route log, and that's streaming into my console in real time. To continue to make it real, I'll go ahead and just update this console log statement and hit save, and then I'll go back to hit the endpoint one more time. There we go, the log streamed in real time into the console. This is fantastic. We just haven't had this in the serverless world starting with 2015 and beyond. It's been so hard to recreate all this stuff, but now the tools, the technology is getting so much better that we're able to recreate this experience.

Furthermore, let's just add in an undefined variable here. You can see errors are actually going to get streamed into the console in real time as well. I just broke my endpoint, I'm going to get a standard error response, and here we go, there's the error message, there's the stack trace, everything you need. Developing on the cloud has been really hard. Serverless kind of prompts this, it really makes it like, there's no these managed services are not offered locally, they only live on the cloud, and it's almost beckoning us to move our development process to the cloud, but it's just been too hard. This changes that, this makes that totally possible. So this is a complete game changer for serverless development, making it a lot easier to develop on the cloud, which is going to rapidly improve your productivity, your focus, all that.

Furthermore, test on the cloud. This is huge. The way we operate is we always write integration, validation tests, testing the live applications, not mocked logic. That's what we're testing against. It's very easy with serverless infrastructure to spin up different stages. You've seen me work pretty quickly across a dev stage and a production stage and use those to run tests against. That's how we always start. Our company, we're very focused on what is the customer facing experience first and how do you work your way backwards to the technology from there. So you want to test that customer facing experience and test that live serverless architecture first. Then we always think of unit tests actually as a secondary. Because we've got a serverless oriented architecture, we make sure that each service comes with its own tests. You want to be careful trying to build kind of monolithic tests that test everything at once. Again, you're trying to maintain separation concerns, separation concerns create autonomy for your teammates and really help you scale that serverless application. This is how we think. We're trying to do as much on the cloud as possible. We've really been burned, a lot of Serverless Framework users have been burned by local emulation, doing mock tests that aren't real. So continuing, you can see this theme of working on the cloud, testing on the cloud is going to be increasingly important we think, and we're continuing to push in that direction and make that a lot easier.

Feature stages are huge. Again, with serverless infrastructure, you could spin up as many stages, copies of your infrastructure stack, as you want. It's not going to cost you anything. I mean, it depends on the infrastructure you're deploying, but it's never been cheaper to do that. So creating ephemeral feature stages for each teammate is really, really easy. What we do as a teammate, if they want to work on a new service, they'll go ahead and create a branch and deploy that service into a feature stage. One thing we do differently that I'd say is not something we've heard traditionally with AWS. Traditionally we've heard, give developers their own cloud accounts, let them have a lot of autonomy, don't let them, let them experiment on their own cloud accounts. We do that certainly, but when you're working on these very serverless cloud architectures, it's just hard for developers to spin up everything on their own AWS account, it just becomes more tedious. So what we do is we have a shared development environment on one AWS account, and we actually make the feature stages also work on that same database account that the dev environment is on. The reason for this is because it's really easy now to spin up a part, a piece of our architecture that references the rest of the architecture in a dev stage. So you could spin up a piece of what I've shown off here in a feature stage and reference a database for example in the dev stage. This is because everything that I've shown off here, service oriented architecture, maintaining separation of concerns, separating your infrastructure that you don't deploy frequently from your infrastructure, your code that you deploy frequently, is creating this great experience where developers can just deploy a part of that into a feature stage and reference everything else.

To make that real, I'll go ahead and show you kind of how easy that is and how we're thinking about making that easier than ever. Again, with the Serverless Framework Components, which is our more progressive serverless development experience, there's a simple inputs and outputs concept, and you could reference the outputs from other components. Here you'll see I'm referencing, I've got my Express app that I deployed on Lambda HTTP API, and I'm referencing my permissions stack which contains an IAM role, and I'm pulling in the name of that to give my Lambda function, my Lambda backend permissions, and I'm referencing the database name for my database stack and the GSI name as well. So I'm referencing these other pieces of infrastructure, and by default it's going to reference these infrastructure stacks within the same stage unless I do this. I'm going to go ahead and just put in, I want to reference from the dev stage, and I'm going to reference from the same app. This is slightly more involved, but I'm going to try and pull the demo off here. I'm going to try and deploy only my Express app into a feature stage. I'm going to reference everything else. I'm going to reference the permissions IAM role from the dev stage, and I reference the database from the dev stage. I'm going to try and deploy this into a separate feature stage again. So here I'm going to deploy just the API, and I'll call this feature stage five. Let's see, fingers crossed, there's gotta be a typo in here somewhere or something I'm not thinking about. This will deploy a whole new Express backend. Now why we say you do this in the same AWS account as your dev stage is because to do this and make it work easily across accounts involves cross-account permissions, and that complicates a lot of stuff. It really complicates this workflow, and we don't want to do that. So we practice this these days, and we've had a lot of success with it. You'll see here I've deployed a whole new Express API, and there it is, up and running, seven seconds. The beauty of this is I'm referencing the IAM role from the dev stage, I'm referencing the database from the dev stage which has all that data in it. I don't have to deploy all the other infrastructure and seed the database, it's already there. Now I could just work on the Express backend autonomously, really quickly, and then of course merge that back in when it's ready, remove these references.

I think I'm out of time here, so unfortunately that's it. I want to say thank you to everyone in Sri Lanka. It's been a pleasure. I hope this is real practical actionable advice that sets you up for success building serverless full stack apps in 2020. Everything I showed off is open source on GitHub, and get started with it right there. If you have any questions, happy to hang around if I have time to answer them.

It looks like there are a few questions here. Let's see. Can I share the GitHub URL? Yep, yeah, it's in here. I'll just go ahead and type the link in real quick. There's a lot more involved in this full stack app, hopefully it's a great learning resource. Next, is it possible to run a complex Node.js Express app with third-party dependencies as a Lambda project? Yep, absolutely. I just showed that off. That was a typical Express app, you didn't have to modify your Express app at all to make it work in Lambda. It could have many node module dependencies. At some point, you're going to want to think about putting those in a Lambda layer, which you could put in that Express component or some other option, so you're not deploying all those dependencies and having fat functions. But absolutely, I showed that off and it's never been easier to do that. Is this session being recorded? I hope so. Hopefully you could see it on YouTube. I'd like to turn this into a better YouTube tutorial in the future, just haven't had time yet. I think that's it for questions.

Oh, there's one more question that came in recently. People are doing research to build serverless fast platforms with GPU support. This is because currently there aren't any stable fast serverless platforms that support GPU, and about inability to access GPU resources within the functioning location for intensive workforce is a big disadvantage for some. That's correct. Absolutely, we hope this will change. I'm sure AWS is focusing on this. I don't see a question in there, but we'll have to look out. The future Serverless Framework does deploy on other fast platforms, particularly some of the self-hosted Kubernetes ones, but that's a whole other subject. I think that's it for questions. All right, thanks everyone. I think that's a wrap, but I'll hang on for a bit.