Serverless, API Gateways, & Lambdas

[00:00:00]
>> Erik Reinert: So this is an example of a serverless architecture. Now, what we have discussed already, right, is monolith, you can sign to see how we started with a monolith. Then you can see how we moved to a serverless architecture. Well, now we're getting even more granular with serverless.

[00:00:18]
However, we also made some other changes to the infrastructure as well, or the architecture as well. First off, what did we change about the frontend?
>> Speaker 2: Static.
>> Erik Reinert: Static, exactly. So we decided, hey, I wanna have a serverless frontend and let that just be hosted in an S3 bucket and let Amazon scale all those requests for me, what does that mean?

[00:00:41]
I just eliminated potentially hundreds of processes running in the cloud 24/7, taking compute resources, and now it's per request. That alone, just by getting your services or your frontends out of a running daemon could save you a ton of money. This is why I like to build SPAs out of the gate.

[00:01:06]
Again, going back to Quirk, a lot of the reason why Quirk is being built the way it is, is because of cost savings and maintenance and manageability, right? Quirk, I did a lot of research on what I wanted to do to build the frontend for Quirk. Next.js has been popping, everybody's been freaking out over it.

[00:01:26]
There's a bunch of other really cool stuff out there too, right? But how do I solve and find the best solution that works for me? Well, first off, I don't wanna have to think about my frontends going down at 2 o'clock in the morning, [LAUGH] right? That's my number one.

[00:01:40]
Hands down, I don't wanna wake up and know that my users trying to access their dashboard can't because the process failed or I pushed a bad commit or something like that, right? Going the serverless approach, I can render the whole file or render the whole UI, drop it on a bucket and that's it.

[00:01:58]
Even the deployment process is easy, right? It's just an RF sync basically to a bucket, and we're done. You might have to do some cache invalidation and whatnot. But it's so much easier from a development standpoint than having to push code, wait for it to go to dev, wait for it to go to staging, wait for it to go to prod, that probably has like 10 to 15 minutes of interval in between.

[00:02:18]
Cuz you gotta wait for For the containers to restart and everything else, right? This is literally sync and go, right? So the developer experience as a single person trying to build a large architecture, frontends being serverless is really powerful. By the way, spoilers, who here knows what may be related to this workshop might also be serverless that a specific company does?

[00:02:46]
>> Erik Reinert: Frontend Masters is completely serverless. So their whole website is basically on an S3 bucket. And that is why it is incredibly fast, it is incredibly easy to maintain and they can iterate off of it very quickly, is because they decided to make it a file serverless frontend, right?

[00:03:07]
And so, this makes it so that they don't have to worry about if their website's down, they just make sure that the S3 buckets basically, publicly accessible, and they do deployments directly to S3. So even the platform you guys are on right now, if you're at least on the frontend master side, that is a serverless frontend that's being served.

[00:03:32]
The next thing you're gonna notice is, what happened to the backend service?
>> Speaker 2: It's not a service anymore, it's a gateway.
>> Erik Reinert: Exactly, yeah, it's not a service anymore, it's a gateway. So it's common within serverless architecture to couple all of your endpoints into what's called an API gateway, right?

[00:03:55]
Realistically, if you're talking about functions as a service, you can't really call them directly from a website, there's no easy way to do that. And it's mostly because functions by default are just executed or invoked within the Amazon or Google, whatever cloud provider's internal networking. However, if we wanted to, we could figure out a way of hooking them up to what's called an API Gateway that is also serverless.

[00:04:25]
Now, is it actually serverless? No, but you don't worry about that. Basically, what the API Gateway acts as, is a cloud-based feature which allows you to expose HTTP endpoint that Amazon, Google, whoever else may maintain for you. But then you can connect serverless functions to those gateways so that they only fire whenever you hit that endpoint, right?

[00:04:53]
And so, this is what makes it so now you don't need to run a service anymore. And on top of it, your functions, or the different functionality of your application, now scale literally, individually by components. This is how Quark is built. Quark V2 is built this way because we wanted to go serverless entirely, right?

[00:05:16]
That was our first goal, was to try to save as much money as we can. What that does mean as well, though, is that Quirk V2 has 50 Lambdas, right? Because there's a lot of things that we do. But each one of those endpoints are being used for specific use cases, right, and they each scale on their own.

[00:05:36]
Which means that if we had a huge influx of user signups, we don't have to worry about it. That function will take care of it, it'll scale automatically. And it's out of the box managed by itself. Same thing for other processes that happen, and as you can see here, it's the same thing for AddToCart or ProcessOrder, right?

[00:05:56]
What we do first, this is we have a function that does add to cart, that can scale indefinitely. Who here has tried adding something to their cart and then it just hung? Because I have. And it's annoying. This is one of the reasons why Amazon moved to such a distributed nature.

[00:06:11]
It's because again, when you have problems like that that you need to solve, it's not really about technically, it's also about the user experience. If users are having bad experience, you need to fix that. Serverless can really do that. Same thing with ProcessOrder, right? You might be in a scenario where processing orders takes a long time because there's tons of orders being waited to process and you're next in line, basically.

[00:06:35]
That used to be a pattern that existed like ten years ago, where you'd have to wait for other orders to process before yours could. Now, because it's separated into its own function, it can easily scale, and the idea here is that your ProcessOrder does not share the resources of anybody else's ProcessOrder, right?

[00:06:54]
So there's no need for a service, there's no need for scaling that, It's literally, if you had 5,000 ProcessOrder functions that day, you ran ProcessOrder 5,000 times. It's literally one to one. One other thing I wanted to note here was the database part as well. What happened to the database?

[00:07:14]
>> Speaker 2: It's shared now.
>> Erik Reinert: It's shared, but there's something else about it.
>> Speaker 2: That it's serverless.
>> Erik Reinert: It's also serverless. Yeah, so there are technologies out there, and again, if you're watching Milk's course, the go build Go services on AWS, he talks about DynamoDB, right? These serverless-based solutions for even databases.

[00:07:36]
So what you're looking at here is a completely resource-based cost allocation for your architecture, meaning you're only spending what you need on this architecture. You're only spending what you need for your front-end requests and the data that's saved on S3, you're only spending what you need for the request making to the API Gateway and those Lambdas.

[00:08:00]
And you're only spending money on the database and the request being made to it as well as the data stored in it. You're not paying for uptime of 24 hours a day. You're not paying for CPU at a certain scale or anything like that, because DynamoDB and these other kinda serverless databases can scale on their own and know how to, right?

[00:08:22]
There's advantages and disadvantages to this type of architecture. However, again, one of the biggest ones is scalability and cost effectiveness. Any questions about serverless and these changes?
>> Speaker 2: I guess the way that you see it as, anything that is provided as a service fits into the serverless category.

[00:08:43]
>> Erik Reinert: Absolutely, yeah, it really is. And again, that's what's kind of made it a little confusing, is because when you think of serverless, you think of functions. But you really should broaden your horizon and just think of anything that you aren't managing yourself is serverless, really. Again, it can be Firebase, it can be Superbase, it can be anything.

[00:09:02]
As long as you're not dealing with the deployment lifecycle or the management lifecycle of that thing, it's really just about pushing your code and running it. Yeah.
>> Speaker 2: For the platform you're developing, what's the local development story look like compared to deploying on AWS? Like AddToCart, how do you iterate on that function?

[00:09:30]
>> Erik Reinert: Right, so we're gonna talk about this in a second, but it's not the same, [LAUGH] basically. There is one massive caveat to this, which we'll talk about in a second with cons, and that is that you have to be on the internet to do all of this, right?

[00:09:50]
You can't be in an airport on a laptop, running a service locally and being like, okay, I'm gonna run functions. You can, but it's so much harder. So it does require you to be on the internet, basically. And the easiest way to approach this is really to create dev environments that are also serverless, right?

[00:10:11]
That you can synchronize to push your code to and test in. And that's what we do. We have a dev environment. Again, it's only two developers right now, so we don't have to worry about it, but we basically have a dev environment and then one of us is like, hey, I'm taking over the dev environment.

[00:10:25]
Okay, cool, do your thing. And then they're working with systems and things like that. Now, what's nice about this with serverless and functions specifically, is my cohort, Hayden, can work on the AddToCart functionality while I'm working on the ProcessOrder functionality. So there's still a separation there, even though it's in the cloud, where we can work separately, and then not really worry about stepping on each other's toes, right?

[00:10:53]
However, if you wanted that logical separation across the entire environment, then you'd probably have an m per developer, right? Or something like that. So that you'd have all the functions, the API Gateway, and everything else. But the benefit of this, which is really nice, is that it's serverless, so you don't have to worry about having five dev environments that are also running processes all the time.

[00:11:16]
And paying for those computers costs and everything, it's really just the same thing of consumption. And so that's what we'll end up doing, once we get to a point where we're like, okay, we wanna have a dev environment per developer or something like that, we will just create the infrastructure for that.

[00:11:33]
And then, he can have his dev environment and I can have mine. But yeah, the biggest caveat to this is, again, we'll talk about it in a second, is you need to be on the internet for it. Yeah, it's all cloud-based. Yep.
>> Speaker 2: Kind of maybe a bit specific, but comparing to the diagram we first started with in the service,

[00:11:51]
>> Erik Reinert: Yeah.
>> Speaker 2: What's the potential cost difference?
>> Erik Reinert: Massive, yeah.
>> Speaker 2: Because I just had 500 for the first.
>> Erik Reinert: So, if we're talking about the monolith, at least, not my original Cork V1 design, so if we're talking about Cork V1 versus V2, V1 costs around 350 to $500 a month for us to run.

[00:12:17]
V1 costs around 50 to $75. Yeah, so massive cost, to the point where I opened up the Cost Explorer on Amazon on stream one day and I was like, tell me where you think we did serverless, and everybody could see the difference. It was huge. So yeah, it was a massive drop, right?

[00:12:35]
But what did we have to take on? Cold starts, other challenges with the system, right? Distribution and things like that, right? But at the end of the day, those were trade-offs that we decided would be more valuable.