Serverless Systems Explained For Recruiters

Last week I wrote a post talking about what a good portfolio project should look like for a new grad going for a programming job and I shared a project I had built for fun.

This project was built using the serverless framework on AWS using AWS Lambda functions and AWS API Gateway.

Anyway, I realized I should do a deeper dive into just what exactly a "serverless" system is, and how it is different from running regular servers.

Serverless - Wait, No Servers?

When developers talk about servers they just mean a computer running in a datacenter somewhere that is always waiting for input.

I've written before in detail about the parts of a web application and I think you should check that if you are fuzzy on what a "server" or a "database" actually is.

But typically, when you are building some kind of cloud based software application you have servers. These servers are running in a remote datacenter waiting for input.

These servers are always running, using electricity and basically they might be doing nothing at all depending on the way a given application works.

For example, is the application only used 9-5 monday through Friday? Does it just need to run on a schedule once a day?

Serverless is great for some kinds of workloads because you don't have permanently running servers, thus saving resources.

"Serverless" Systems Background Info

Serverless systems generally are products provided by public cloud providers like AWS, Google Cloud, or Azure. These would be:

• AWS Lambda
• Google Cloud Functions
• Azure Functions
• Alibaba Cloud Function Compute
• Tencent Cloud Functions

These work slightly differently for every cloud provider, but AWS was the pioneer here so we will talk about Lambda functions the most.

How Do They Work?

With AWS Lambda it works like this: instead of deploying your code to an always on server you create a "bundle" of files that contain your application code. Again, this might be as small as 100 lines of code for a single function.

AWS Lambda just stores your code as a file and then when it is invoked it will create a temporary server, load your code, and direct the event to your code running on the temporary server and let it run as normal.

After just a few minutes the temporary server is destroyed, thus saving electricity costs and you are only charges for the seconds your code was running (explained below).

What if your application goes from zero users to 1000 in one hour? Well, you might have heard of "autoscaling" before (automatically creating more servers to handle traffic) - serverless platforms provide this feature as well, more temporary servers with your code are created to handle traffic as needed.

Serverless Systems Can Be Cheaper

So normally when you buy servers from E.g. AWS, you pay a fee to rent server compute power and you generally think of it in terms of per hour used, or per month.

For example, let's say you need a server that to run your application that costs $50 / a month. This would be the cost for the server. You might also pay some cost for the disk space the server uses.

Comparatively AWS Lamba function cost is calculated per use. As I write this their pricing is:

 Requests ----- $0.20 per 1 Million requests
 Duration ----- $0.000016667 for every GB-second

Sounds complex, but basically it means if you use a given function 1 million times you will pay 20 cents. It's hard to calculate what duration will cost but most functions should complete within milliseconds, so the expense will be minimal.

For something that is used infrequently like a scheduled job that runs once a day or a low-traffic application you might pay literally just pennies per year, compared to a fixed cost per month. The lambda function is also not going to be using disk space permanently for things like operating system files.

What does the infrastructure look like?

Well the difference is often that you think of pieces of work in terms of single functions Vs an entire application. Each function might only be 100 lines of code and you might have dozens of functions to make up an application. Here is a diagram I put together to show what this might look like:

Serverless just replaces part of the backend

So you can see from the diagram, the application infrastructure still looks similar to what you might expect in a typical web app. You still have a database, you still are exposing an API for the client to consume data.

Serverless systems are just a different way of writing and deploying backend code. They probably don't have much of an effect on how a client-size developer is going to write their code.

For backend developers writing serverless code is a shift, but being somebody who writes backend code I found it easy to adapt to. There is also a framework called serverless framework that makes writing and deploying this kind of code much much easier. I've used it and I like it.

Hey, You Didn't Mention Programming Languages!

No, I didn't mention programming languages but you can use several with AWS Lambda. I've been using Node.js lambda functions and they work great. Here is a screenshot of the different languages AWS Lambda supports by default.

You can see Node.js, Python, Java, .NET Core, Ruby, and Go are all supported (and you can do custom runtimes too).

Summary

For backend developers, serverless systems represent a shift in how code is written and applications are built. I believe serverless based applications are only going to become more popular in the future, and you should be seeing these terms pop up more and more on job descriptions and resumes.