The Complete Beginners Guide to Serverless

What is Serverless?

Serverless computing is a cloud computing execution model, where your provider e.g. Amazon (AWS), Google Cloud, Microsoft (Azure) runs the server and you focus on the implementation.

It simplifies the process of deploying and managing code in production and abstracts away scaling, capacity planning and maintenance from the developer.

This article will take you through everything you need to know about the Serverless model, including comparisons against the current options and explain in detail when to use the model and when not to.

Current way vs Serverless?

There are many alternative models to the Serverless one, the most popular models are managing the infrastructure yourself, where you buy, maintain and upgrade your servers or deploying your application to a managed server also known as IaaS (infrastructure as a service)

So why Serverless?

Why then has this new serverless model taken hold and becoming popular within the community.

All the current models put the large overhead of owning and managing a server on the developer/company. This increases the costs for the company and creates a limitation to scalability and flexibility for the developer.

In comes Serverless which is a managed, stateless and ephemeral service, that allows you the developer to focus on the most important part (the business logic) and leave the rest to your cloud provider.

We will delve into the pros and cons of this model and discuss examples of when to use and not to use the serverless execution model.

Serverless pros

There are many different perspectives we can view the serverless execution model from. The main three we will be viewing from is the developer, the business and the user.

Pricing

For the serverless model, the charge is execution based, meaning you are charged by the number of executions of a particular bit of code. This reduces the running costs as you will pay zero if that bit of code is never run. Further, the business will not need to hire a team to buy, maintain and upgrade the infrastructure which will reduce overhead.

Environments

As developers, we don't want to code and test in production so we create replica environments to do this e.g. QA, Staging, Development environments. Setting many environments up is a resource-intensive task, by using the serverless model it makes setting up many versions of your code as simple as an extra configuration line.

Scale

Serverless allows for automatic scaling based on certain parameters e.g. CPU usage, memory usage etc. This allows you to scale up and down to meet your performance requirements for your user base without having to acquire, set up and deploy your code to new servers.

Invocation

Serverless computing allows for different kinds of events to invoke your code e.g. a client hits one of your endpoints, uploads and image, tweets or makes a call. This allows for a lot of flexibility while keeping costs down as you don't need the task running 24/7, you only need it when a particular event happens e.g. when a user uploads an image, call your image resize code that resizes the image and uploads to your storage area.

Deployability

When developing there is a question around when to deploy my code to production. This is a spectrum but at either side, there are the fast deployable iterations which mean as soon as you have finished your development work and it has passed the tests and been reviewed it goes straight out to production. At the other end, there is the monthly or even bi-yearly releases where a massive bundle of changes are pushed into production, then the month following is spent debugging and fixing the issues.

The preferred state is to be able to deploy once the code has been tested and reviewed, as this allows for smaller deployable commits resulting in less risk and faster delivery of value to your users. This is exactly what the serverless model can do.

Monitoring

No need to add custom code to your backend for monitoring purposes, cloud providers provide this right out of the box, for example, AWS pipe your lambda logs into AWS CloudWatch

Programming Languages

When you create your new function within the serverless model you can select what language you want that function to run in. There are many languages available to run your code on so you can choose any modern language e.g. Javascript, Python, Golang.

Further, each function can be a different language so you can choose the language that best fits the requirements.

Serverless cons

So there are quite a few positives to using the Serverless model yet, there are also a few drawbacks which we will discuss below.

Networking

Now you have completed and deployed your code how do you access it? Once deployed you cannot access directly and will need to set up a wrapper, for example, an API Gateway to access them which on AWS is pretty straightforward

3rd Party Dependencies

Have to bundle dependencies into one executable and can make the lambda heavy, which can hit your providers limits and leads to slower startup times so the current thinking is when you have a small number of dependencies use the serverless model, for larger projects with more dependencies use the current architecture. However, they are looking to add a new technique called layers which will reduce the drawback of this.

Execution time

Serverless computing is meant for short-running tasks, which means most of the providers have an upper timeout limit around 300 seconds for processing an incoming request. Therefore if you have long-running tasks, you could not use the serverless model for them and would not want to as it would be expensive.

Startup Time

Takes time to get function within the serverless model started, approx 100ms from a cold start, but, there are tactics to reduce this and increase performance for your application for example by periodically invoking your function to keep it 'warm'

Vendor lock-in

Can end up being locked into a particular cloud provider but by using a framework e.g. the serverless framework and architecting your system for multi-cloud providers you will be able to reduce this and deploy on many clouds at once. Increasing reliability.

AWS Serverless Architecture Example

Let's go through a quick example of how you could architecture a serverless application on AWS.

• Client-side javascript application, allows us to use a simple, static web server.

• For the web server, we will use Amazon S3 buckets, which provide a simple and reliable web server to server HTML, CSS, JS and Images.

• For our backend business logic, we will use AWS Lambda Functions (FaaS)

• To expose our backend functions we will wrap them with AWS API Gateway

• To store our data we will use AWS DynamoDB which provides a managed NoSQL database

• Finally, to authenticate our users, we will use AWS Cognito which is an identity service integrated with API Gateway and AWS Lambda, which can allow users to signup and log into your web and mobile applications.

Wrap up

As you can see the serverless model is one of many and can be useful in certain situations. It is not a one size fits all solution and is not for every use case.

If you want to try deploying your first Serverless application, you can follow along with this article approx 10 minute completion time.

If you have any other ideas for further pros and cons of the serverless model and what you are currently using them for, feel free to add a comment below.

Thanks for reading as always if you are interested in learning more about technical topics in Software engineering and technical interview best practices check out my website