Serverless: When to Use?

Serverless architecture, the next level of infrastructure abstraction is becoming more and more popular with AWS Lambda and Azure Functions being the most popular FaaS (Function as a Service) Providers.

Maybe because of how easy and quick set up a function to run in those services can be, the idea that the Serverless Architecture improves your team's productivity or even the application's performance started to gain traction with more and more projects being created '100% Serverless' Solutions.

For the application I am currently developing, "Legion of Heroes" (GitHub) I decided to try and develop the entire NodeJS API Backend in AWS Lambda, using the Serverless.com framework to make testing and deploys easier and faster. The experience I gained through this process was quite valuable and I will sum up my findings below.

But before we go any further, I think there are 3 basic myths that we need to settle right now:

1. Even though this architecture type is called "Serverless", the servers are still there and are as important as ever, we simply don't need to manage. The cloud providers take care of that for us.
2. Your application won't necessarily gain performance nor your infra costs will be lower. Every application needs to be assessed individually.
3. Running entire HTTP servers or Applications with multiple responsibilities is definitely not the right use case for Serverless.

What is Serverless?

The serverless architecture represents a hosting model for functions that do not require server configuration, that is, all dependencies for your application needs to run are deployed with your code.

These functions can be triggered in two ways: HTTP routes that work just as we are used to common REST services or events triggered by other existing services, such as File uploads to AWS S3.

Generally, serverless architecture is used to process asynchronous code that doesn't need to be executed immediately and that can cause unnecessary processing in the main application. It is important to note that every function that uses this model has a runtime limit and it can be quite tricky to debug or test, so it's important that the service is simple and has a well-defined objective with few side effects. In addition, these services are stateless and, therefore, they must not keep any state between each execution, since each new execution can reconstruct the server (Docker container) from scratch without traces of a previous execution.

Use Cases

Microservices

When creating applications using the microservices architecture we can move some of the services that periodically scale to be serverless functions.

Access Peaks

Imagine that your application receives peak access during specific periods, moving the service that processes these operations to the serverless model avoids unnecessary server scaling and can also bring cost reduction.

Low traffic services

Another viable use case for serverless is to move services that do not have constant traffic to this architecture since, while not running, services are not charged.

Get your application to the market faster

In case you want to accelerate the speed of publishing a project in its initial phase, the serverless architecture helps by providing a simple deployment structure at low cost.

Serverless Advantages

• We developers don't need to configure the webserver (Node, NGINX, Apache, etc...)
• It's considerably inexpensive architecture for low traffic services
• It can scale in massive proportions automatically/effortlessly.
• The deploy process is quick and easy, especially when using CI/CD practices.

Serverless Disadvantages

• Our functions run on a Docker container that the Cloud Provider spins up every time the function is triggered. As you can imagine, if our function is not triggered frequently (usually < 5 mins), a cold-start will be necessary, causing the operation to be slower.
• The function run time is limited. For example, AWS Lambda allows run time up to 900 seconds at the moment. This may be increased in the future.
• Debugging and testing can be very painful and slow the development process significantly. Some frameworks help with this, but overall it's far from perfect.
• If used in inappropriate applications, the infrastructure costs can be significantly higher than on traditional architecture.

A few tips if you want to try Serverless

• Different cloud providers use different syntaxes and services to manage your serverless resources. Using a framework such as Serverless.com can help you streamline multi-cloud serverless deployments.
• Be careful with extra libraries you use in your code. Those libraries will also be deployed with your code as dependencies and they can get considerably large in size.
• Using binary dependencies can be tricky. Because the deploy is done using a .zip, those dependencies might not run correctly in Linux. A good workaround that is to install the Linux binary before deploying:

npm install --arch=x64 --platform=linux --target=8.10.0 LibraryName

• You can test your functions locally before deploying to your Cloud Provider. Serverless.com helps with that, AWS and Azure also have their own solution for this scenario.
• You can use AWS DynamoDB to store persistent data used by AWS Lambda for example.
• If you want to migrate an entire NodeJs/Express application, Serverless.com can help with that.

If you liked this post don't forget to leave a comment, remember that the newest technologies usually. This architecture is very cool and makes sense in many applications, but using it regardless of its software model can be a waste of work and money.

Thanks for reading.