Serverless

What Serverless Means

Another thing that's become popular is this idea of serverless: that you make your code where it doesn't necessarily need to run on a server. That's a bit of a misnomer, in that we still have to have some sort of physical server that's running it, but it just looks very different than a regular service, a regular container, a regular virtual machine that we get set up and running.

Let's say we create an application. We turn that application into a service that's running on top of an operating system that's running on a machine right here. This is great, because this service is running all the time and it can respond to certain users whenever they make a request. So this is a popular way that we set things up, where the service is just running all the time.

But there are times that we have just this simple little script that just needs to be run once in a while. Maybe it's some sort of maintenance task that takes about five minutes to run, or maybe even shorter than that, that we need to run once a day. The problem is, if we have this service that's always up and running, that's a security concern, because it's up and running all the time. Plus it's just utilizing all of this infrastructure when we only run it for 5 minutes every day. So it's kind of ridiculous to have all of that overhead.

Instead, what we could do is just have this service that runs scripts, that just processes things. We can submit a script to that and run it whenever we need it. So now we have this script right here that says, oh yeah, you do this and that, and then it just runs it on this machine every once in a while.

The Advantages

Now that's not really a full explanation for it, because we can do cron jobs and we can do tasks that do that exact same thing, just run every once in a while. So what are the advantages to this?

If we just have a server that that's all it's designed to do — and really these services usually reside up in the cloud, so it's a service we subscribe to — what we do is we just submit the script whenever we want it to run. So we can submit this script at the end of the day, and there are other scripts we could have running at other times. What we end up doing is we utilize these cloud services that process these scripts whenever we need to run them. And now it's a very small cost, because we're not running these scripts all the time and we don't have to pay for this whole server. We're just paying for a little bit of processing power when we need it.

So what's great about this is there is less management. We're not really managing this server; the cloud provider is managing all of that. For instance, AWS Lambda — we don't have to manage those servers. All we have to do is create this little scrilet that gets run every once in a while.

It's pay per use. When we want to use it, we use it. We pay a little bit, maybe it's pennies to run it, and then we're done. It's very scalable, and there can be very fast deployments because it's just a little tiny script to deploy.

The Trade-offs

We do have less control over the environment, because we don't control the operating system, we don't control the hardware, we don't control the application that's running on it. We don't have control over those variables. It's just this script that's running, and so we have a lot less control.

Then we also have vendor lock-in. We create these scripts to run in Lambda — well then, how portable is it to other environments? If we want to take it to Azure or Google Cloud, how portable is it?

This is great for small scale operations, or even large scale operations. This can be great if we just have these little things that we need to run now and then. So it's great for when we have just small uses that we need to run now and then. Now, if it's a service that needs to be up and running all the time, then maybe we go through some sort of AWS container services, or maybe we have our own servers that are running it.

Lambda Pricing

I'm here on the AWS site where I'm looking at the AWS Lambda pricing. The Lambda pricing gives us a glimpse into what these services do. This is going to be a serverless. This is going to be where we just create the code and the scripts and then we submit it to be processed.

So what does this look like? The pricing, rather than having a pricing for a machine, because we're not utilizing a machine — those machines are already up and running, running those services. And what do we have? We have the first 6 billion gigabit seconds. So they have some sort of measurement here for processing. For this first six billion gigabit per seconds per month here, this is what they're going to charge — just a fraction of a penny. It's just such a small amount.

So what we're going to do is, if we have a script that does millions and millions and millions of these, then that's when it'll actually add up to something, and then they will charge us for that. And then there's economy of scale here, so we can actually get charged less if we move up and do more processing power with these.

But essentially what this is, is we don't have to manage the server or anything like that. We are just submitting the code that's going to be processed to this service, to the Lambda service, and being charged by the processing power that we're using.