What is Serverless?

Introduction

I came across this term, “Serverless”, about a year ago when I was still in university. This term threw me off. When people talked about serverless architectures, I became even more puzzled — how do you host an application without a server?

Serverless became possible with the advancement in cloud technologies. It gained popularity after Amazon Web Services (AWS) introduced AWS Lambda.

The word “Serverless” itself can be misleading. With serverless architectures, developers still host applications on a server, albeit with different requirements and considerations. Let’s walk through some of them.

Differences

Server Setup

One difference between a serverless and a traditional model is the level of control developers have when setting up and configuring the server settings.

In a traditional architecture, the developer hosts the application within an Amazon EC2 instance. Here, the developer will be responsible for configuring the virtual machine to:

• Set up the appropriate python environment
• Determine appropriate resources (E.g., Instance type, storage, etc.)
• Determine metrics to monitor (E.g., CPU, Memory, Number of requests)
• Scale up and down according to thresholds(E.g., 60%/70%/80%)
• Set up other supporting services (E.g., Logging to Amazon CloudWatch)

Developers do not have to handle these operational tasks in a serverless architecture. With serverless, there is no virtual machine for the developer to configure.

Using AWS Lambda, developers choose the language they want to use and configure basic metrics such as memory and timeout. Next, they upload their application code and can start executing it. Considerations such as setting up the environment, scaling and logging are abstracted away from the developers.

Cost

One major difference between a serverless and traditional architecture is how AWS prices them.

In a traditional architecture, your services will run 24x7, regardless of whether anyone is using the service or not. This pricing model works well if the developer is confident of the service usage pattern, and developers can further lower the cost using AWS savings plans such as spot instances.

On the other hand, a serverless architecture only charges for the actual utilisation of the service. For example, if there were 1,000 invocations, averaging an average runtime of 3 seconds, the developer is only charged for 3,000 seconds instead of paying for 2,592,000 seconds (60 x 60 x 24 x 30). The caveat here is that the price per second for serverless is usually higher than a traditional model. Still, there is a breakeven point where choosing between options makes the most financial sense.

Another important factor to consider is the operational cost associated with each architecture. In a traditional architecture, developers will need to spend time configuring the servers and maintaining and patching them. Serverless minimises these operational tasks, leading to increased savings and shorter time-to-market.

Conclusion

While the examples above focus on compute services (Amazon EC2 and AWS Lambda), the concepts discussed — server setup and cost considerations — can be applied to other services such as databases (Amazon RDS vs Amazon DynamoDB).