Introduction

[00:00:00]
>> So let's talk about serverless functions. So I am Jason Lengstorf. I am @jlengstorf on pretty much every social platform. You're gonna find me anywhere, if you wanna learn more about me I'm @jason.af. I work as a principal developer experience engineer at Netlify. Prior to that I worked at Gatsby, before that I worked at IBM.

[00:00:22]
And before that I did agency work for years and years and years. And what I wanna talk about today is Serverless, and the reason that I think serverless is exciting is that I've been doing this for a long time. I started working in PHP, and I was building backends in PHP.

[00:00:42]
And there's this kind of like when you work on any website, you've got a few layers that you're dealing with. You've got the piece that your users are actually gonna see, it's the the markup, the things that go to the browser. Then underneath that you've got another layer where the pieces that will go to the browser, they have to get data somewhere, so they have a way that they communicate some layer that they communicate to.

[00:01:09]
Then you've got your kind of business logic. And that's where you actually do things, you're gonna take a list of data and you're gonna turn that into, you're gonna reformat that as a chart, you're gonna sort things so that users are getting just what they're supposed to see and not everybody else's data.

[00:01:25]
And underneath that, you've got your data. And depending on how you organize this you end up with a lot of different architectures, one of the most common ones for a long time ago was go monolithic, and that's still common today. Where everything is in one big app, you've got your data is connected by your business logic is is put through some kind of a communication layer to the generated markup that goes to the client and that all lives in the same code base.

[00:01:56]
That can be great, it is a great way to get started. It's a great way to limit the amount of complexity in the setup and deployment of your app. But over time as your team grows, as the app grows, as the complexity of what you're building grows, that starts to become really challenging to manage.

[00:02:12]
Because you've got a lot of people trying to work in the same codebase or your codebase starts to grow tendrils, where you can't change something over here because it might break something over here. And then that's pretty challenging. So then the the next phase is you start doing a, like a vertical separation where you've got micro services.

[00:02:33]
So maybe you've got an account micro service, maybe you've got a dashboard micro service, maybe you've got a billing micro service. And each of those can be, it's a mini monolith, you've got the the front end the the communication layer, the data, the business logic all in a little container.

[00:02:49]
But now it's doing much less work. And that is great because now teams can work individually on the things that they're working on. And it prevents that cross tendril where you've got things that are kind of reaching across. If you wanna change something in the account, it'll break your dashboard or something, and that's good.

[00:03:07]
So you're creating additional separation. The challenge then becomes, you've got this vertical integration that's really tight and that can be, it just gets tricky, right? Because now you've got like a front end team that needs to do something. And maybe their back end doesn't do exactly what they need.

[00:03:25]
So they might write a proxy layer or something and then you've got these kind of weird communications where things are, they just get muddy again. It's hard to tell where the front end ends and the back end begins because in the middle, there's this muddy kind of mess.

[00:03:41]
So then you start looking at like, well, okay, how do we start separating this way? How do we separate front end from back end? And it starts to lead to an architecture that I'm very fond of called the Jam Stack. Where you look at your front end as a separate thing, your front end is a generated artifact that's separate from this the services.

[00:04:02]
So a micro service instead of generating a front end starts to generate an API. It gives you an API surface that you can speak to. And if you haven't used this professionally, you've almost certainly used it in Software as a Service. If you've ever worked with something like Stripe.

[00:04:18]
Or if you've ever worked with any sort of like any content management system that you use an API to get the data if you've used strappy or contentful, or if you've worked with GraphQL. Or if you've worked with any of these API layers where you're gonna say, all right, service, I would like this data, and then you get back an object and you do something with it and show it on screen.

[00:04:40]
That's the separation from the front end to the back end. And if you're using this Jam Stack architecture, you can pull all of that once at build time. And then you end up with these set artifacts that just sit in one place. They're pre-generated, which means they're very fast.

[00:04:56]
And you don't have to have a server to run your front end anymore, which is a really, really nice thing to do. It gets you into this world where your front ends are no longer dependent on a running server, they're pre-generated. And because they're pre-generated, they're just static files, each build of your site each version of your site is a folder.

[00:05:19]
And you can drop that folder on an FTP server, you can drop that folder onto a CDN, which is usually going to be your best bet. And then you can shut down the servers, you can shut down all the services and things just work. However, as you might already be thinking, that leaves this gap where in any website, there are a lot of things, a huge amount of things that can just be generated once.

[00:05:44]
The skeletons for most of your app pages are gonna look the same no matter who's looking at them. Your marketing pages, the announcements, the blog, the pricing pages, all of these parts of your app Don't really change, they change infrequently, and they look the same for almost everybody.

[00:06:03]
So then you've got this small amount of data that's gonna change for each user. When they log in, they're gonna see different things. Or when somebody clicks a button, they need to see something happen. If somebody submits a form, it needs to go somewhere. When you get into the Jam Stack, it can be easy to say, well, you can't do that, that doesn't work, and so we need servers.

[00:06:23]
Fortunately, that's not the case, we are actually able to do so much using serverless functions that you would traditionally have to go back and get a server for it. And so that is a really, really exciting opportunity for us because it means that as front end developers, if we wanna build really dynamic experiences, or if we wanna empower our teams to build really robust apps, without requiring them to scale out with a big DevOps team, a big back end team.

[00:06:52]
We just want them to be able to build an amazing app experience and then make it dynamic Serverless functions give us that key because we're able to just write some logic. And that logic is what executes and it works very similar to an API. We're gonna look at real examples here in a minute.

[00:07:14]
But that logic allows you to say when someone clicks a form, I wanna take the form input, I want to do some validation on it, and then I wanna send it somewhere. And I don't have to say, my server is here, I have this route set up, I need this proxy configured, I need this gateway configured.

[00:07:37]
We just get to say, here's a function. And so that makes life really easy, it makes it much nicer to get things up and running. And these are really robust, you can use these at any scale, right? Serverless functions, they're available in every major cloud provider, you can use them in AWS, you can use them in Google, in Azure, IBM Cloud, whatever you're into, you can use serverless functions with it.

[00:08:06]
And there's gonna be an offering to support that. But what I like about it is that it doesn't have the same barrier to entry that similar approaches or similar ways to solve similar problems. If you wanted to do this with a monolithic application, you might find yourself trying to deal with the database, trying to deal with caching layer in front of that database, something like Red is.

[00:08:27]
You would have to set up your proxy, you'd have to set up all these these extra things you're getting into the Apache or the NginX configuration. You're getting into so many things that just get muddy, and it's not the thing that you wanna be dealing with because what you're trying to do is solve a problem.

[00:08:43]
You're not trying to architect a robust solution, you want the solution to be robust so you can just solve the thing that you care about. So how do server list functions work? The way that a server list function works is that it doesn't mean that you're getting rid of servers.

[00:09:01]
What it means is that the logic that you're deploying, where you used to have to deal with the whole thing. Now, you get to leave almost all of the configuration part this huge chunk of setup and boilerplate and configuration, that's now handled by a third party. You are saying, hey, AWS, I'm gonna use lambda.

[00:09:23]
I just wanna send you some business logic. You deal with all the scaling and and configuration and routing, and they'll just do that for you. Depending on which solution you use, there's gonna be more or less setup there, usually YAML configuration or something. But in general, what you're saying is I need a server, but I don't wanna deal with a server.

[00:09:48]
And serverless function are a way to do that. I want to just write server-style logic and not deal with any of the deployment or configuration or management of a server. So serverless doesn't mean no servers, it means somebody else deals with the servers. And I think that's probably the most important point to take away from this, like serverless isn't magic, it's still a server.

[00:10:09]
And that's actually the exciting part, because it's still a server, just a server that you don't have to manage. We get all of the benefits of running a server without the headaches and overhead of managing servers. And I think that is the most exciting thing. That's the part that gives us the most flexibility, it's what lets us move extremely fast.