Serverless Architectures

[00:00:00]
>> Eric Reinert: All right, Serverless, I love that gift, because I feel like this describes Serverless perfectly, shut up and take my money, right? We talked about monoliths being deep thought, this huge, massive beast that, either does this one little thing, or like tons of other things. We talked about distributed having these satellites all over the place and having them work together and now we're talking about Serverless, basically being like, hey, I don't wanna worry about any of this stuff, right?

[00:00:29]
I just wanna run my code and you cloud provider, you take care of the rest and so, this gift really does do a good job of, in my mind kind of describing what you end up using Serverless for. So, let's talk about Serverless because Serverless doesn't necessarily mean one thing.

[00:00:47]
It can mean one thing, but I wanna remind anyone out there watching that Serverless doesn't just mean functions as a service. So, if we read the definition, Serverless architecture refers to applications that significantly depend on third party services, backend-as-a-service or BaaS, or on custom code that's run in ephemeral containers, FaaS, functions as a service, which I forgot to put hyphens between.

[00:01:17]
But who can help me differentiate what a BaaS is versus a FaaS, and I'm not talking about fish. So, can anyone, name a backend as a service platform?
>> Speaker 1: Firebase.
>> Eric Reinert: Firebase, yep, what else?
>> Speaker 1: Supabase.
>> Eric Reinert: Supabase, yep, exactly, yeah, really any kind of platform that makes it so that all you have to work with is an API is a back end as a service, or a BaaS.

[00:01:48]
When we talk about Serverless Quirke doesn't just use Serverless functions we actually use Supabase as well, why? Why do you use Supabase? Well, because Supabase gives us the functionality out of the box as having a PostgreSQL instance, but I don't need to do it in RDS. I don't have to manage that service myself, I don't have to manage that instance myself.

[00:02:14]
And on top of that for now, since we're such a small company and we're just getting started, I don't wanna have to pay for the 24-hour consumption of ARDS instance, right? I'd rather just pay for the requests and the data usages that I have. This is what makes backend as a service or Baas so valuable, right?

[00:02:34]
Is you can lean on what they've already built and just have a simple interface to work with. Functions as a service, however, are almost a step lower than microservices, where functions as a service means that there's one particular function that you wanna do, that's it. Just this one thing, ring the doorbell, cool, ring the doorbell, ring the doorbell, ring the doorbell, that's all it does.

[00:02:58]
And I talked about before with microservices, you should normally expect the same response, you should always expect the same response as a function. You should never have a function do two different things, if you're doing that, that means you have two functions and you need to separate them out, and you're probably not using functions [LAUGH] as a service properly.

[00:03:18]
Functions as a service is really meant to say I have one specific process that I want to run, and I want to run it to the ends of power, right? And I wanna scale that to the ends of power, Serverless overall whether if it's backend as a service or functions as a service, is the idea that, again, you're either utilizing a provider that you're paying to give you the services without the cost of management.

[00:03:48]
Again, shut up and take my money, or you're doing it so that you have an isolated specific use case that you want to scale to the end, and on top of that, you don't have to worry about the management of the infrastructure. Serverless isn't so much about a design in the sense of decoupling, though it can be.

[00:04:08]
It's more also about cost savings and finding ways to save money, and we'll talk a little bit more about how that is sometimes good and how that is sometimes bad. So, Serverless architectures, the app logic is still running on servers but all the management is done by the cloud provider, Amazon, Azure, GCP, etc.

[00:04:31]
You just need to run your code and the cloud provider takes care of the rest. Now, this can either be code in your own service that's reaching out to the cloud provider and getting data like a BaaS, or it means that you're literally taking one specific function. You're putting that up in Amazon, and then you're letting it run thousands and thousands of times a day, but the goal here is to make it so that you're just running your code and the cloud provider takes care of the rest.

[00:04:58]
You don't have to worry about uptime, you don't have to worry about scalability, you don't have to worry about pretty much most of the stuff we've already talked about today.