This article is meant to be a summary of what I have read and learnt when comparing between serverless and traditional architectures with PaaS.
Before we start, let’s get our definitions right:
This refers to the framework consisting of stateless, event-triggered, online-only-when-invoked compute containers which typically only serve a single purpose each, and integrating them together. It does not mean there are no servers involved, there are still servers but they are fully managed and maintained by the cloud providers of the compute containers.
FaaS is an inevitable part of the serverless framework. The compute containers characterized above, can exist as FaaS offered by major cloud providers such as AWS (eg AWS Lambda) and Azure (eg Azure Functions).
- No server management or maintenance needed
- Automatic scaling, fine grained to number of requests
- Runs only when needed (triggered by events such as requests)
PaaS is very similar to FaaS, except that that it does not triggered by event, and is typically always on. This does not suit the serverless framework.
- No server management or maintenance needed
- Automatic scaling, adjustable to number of instances running
- Typically runs 24/7
Sounds very similar to FaaS right? However there is one key operational difference between the both of them: Scalability, which affects operating cost.
This is best explained by visualizing architectural diagrams with an example.
Case Study: Imagine that we are going to build an e-commerce chatbot. It will have 2 functions available to the end-user: search and payment.
Traditional 3-tiered Architecture
Much of the logic implemented for the chatbot will be handled within the server-side code. Any incoming requests related to the chatbot, is single-handedly managed by the chatbot server running 24/7. This is where usually PaaS come in by providing and managing everything you need to host and maintain the app, and you need only deploy the app to the platform.
Let’s first explain some services that might be unfamiliar above:
- Api Gateways — A HTTP server where routes and endpoints are defined in configuration, and each route is associated with a resource (functions in this case) to handle that route.
- Authentication Service — It is what is says, a service that helps with the authentication. Typical providers are Auth0, AWS Cognito. These are usually called Backend-as-a-Service (BaaS), as they only require you to configure, and the provisioning and running of the service is already handled by the vendor. BaaS are commonly used with FaaS within the serverless framework, as both of them allow similar conveniences such as the absence of resource management.
Things to note:
- The chatbot server is now separated to 2 different functions that will only be triggered when there’s a request coming in.
- Our authentication function has been outsourced to a 3rd party service. We no longer have to write our own code.
- BaaS is different from PaaS, in which BaaS serves the user for a specific need, such as authentication, or face recognition, whereas PaaS is a platform for users with the main purpose of easing their current methodology of doing things (such as easily creating web servers with Azure Web Apps).
Functions allow a new way to modularise our code giving us the flexibility of porting the same functions for a new project without changing anything.
Assume in a month we have to take in 1 million requests, and a container instance runs for 5 cents / hr (AWS Instance).
In the 3-tiered traditional architecture = $33.6:
- total time taken for server to run = 28 days * 24 hrs = 672 hrs
- total 1mth = $33.6
Serverless architecture = $13.85:
- time taken for function to run = 1 sec
- total time taken for server to run = 1000000 request* 1 sec= 1000000s = 277 hrs
- total 1mth = $13.85
In our simple example above, the monthly price difference between the two models is under $19.75, but when scaled horizontally that $19.75 can be multiplied many times based on the demand.
- They are not friendly to processes that need to keep track of state
Use a fast database such as NoSQL, out-of-process cache (eg Redis) or object stores (eg S3 Buckets). However these are all a lot slower than in-memory or on-machine persistence. As said in Martin Fowler’s article:
“any state of a FaaS function that is required to be persistent needs to be externalized outside of the FaaS function instance.”
- They have a limited run time duration.
“At present the “timeout” for an AWS Lambda function to respond to an event is at most five minutes, before being terminated. This means that certain classes of long-lived tasks are not suited to FaaS functions without re-architecture…”
- Cold starts resulting in longer startup latency.
Startup latency (which just means the delay in which functions respond to events) has 2 kinds: 1) cold starts and 2) warm starts. Cold starts take longer and only happens when the function becomes inactive (stop receiving event triggers) after a few minutes. In this case when a new event is triggered, a new instance will have to be created for the function to run which takes longer compared to warm starts, where the the instance is actually reused from a previous event.
Equally as variable as cold-start duration is cold-start frequency. For instance, if a function is processing 10 events per second, with each event taking 50 ms to process, you’ll likely only see a cold start with Lambda every 100,000–200,000 events or so. If, on the other hand, you process an event once per hour, you’ll likely see a cold start for every event, since Amazon retires inactive Lambda instances after a few minutes.