A deep dive into Serverless or FaaS technology

In my last article An introduction to Serverless or FaaS technology, we have touched base with Serverless architecture and where to get started. In this article, we will be covering the followings

• Deep dive into Serverless or FaaS
• Use cases of Serverless or FaaS
• Benefits of Serverless or FaaS
• Future of Serverless or FaaS

Deep dive into Serverless or FaaS

Fundamentally Serverless or FaaS is about running backend code without managing your own server infrastructure. We already have covered the basic introduction and top Serverless or FaaS providers in the An introduction to Serverless or FaaS technology article.

FaaS is not a framework or library

FaaS does not require coding to a specific framework or library as Serverless or FaaS functions are regular applications which can be implemented in any supported language like JavaScript, Python, Go, Java, Clojure, Scala, C# etc.

Deployment of Serverless or FaaS

Deployment of Serverless or FaaS is different from any traditional application as we have no server or applications to run ourselves. We upload our application code as a function to the Serverless or FaaS provider and provider take care of everything from providing resources, instantiating VM, managing process and etc.

Scaling

Horizontal scaling in Serverless or FaaS is completely automatic, elastic and managed by FaaS provider. If your application needs more requests to be processed in parallel the provider will take of that without you providing any additional configuration.

The containers to compute required to execute your functions are ephemeral, creating and destroying them is purely driven by runtime need and handles by the vendor. No cluster or VM management is required by the FaaS user at all.

Event-driven

Serverless or FaaS is typically event-driven and triggered by an event defined by the provider. These events can be an HTTP request, an API gateway, a third-party resource, a timer and etc.

For example, AWS Lambda seamlessly integrates with all other AWS services and it also has events related to S3 (file/object) updates.

State in Serverless or FaaS

Serverless or FaaS have significant restrictions on the machine or instance-bound state which means storing a variable in memory or writing data on local disk available but there is no guaranty that those will be persisted in multiple invocations. So as a developer you should never assume that state created by the first invocation will be available in the next one.

Functions in Serverless or FaaS are stateless which means they are functional on their provided input and generate some output. For state oriented functions we rely on external databases, cross-application cache or in-memory storage, file/object storage to maintain state.

Execution time or timeout

In Serverless or FaaS execution time or timeout is very limited for example AWS Lambda can only run a function up to 5 minutes, which will be terminated automatically. Google Cloud Functions and Azure Functions also have similar timeout limits.

Startup/Warm Start latency

Every platform needs some time before it can execute any function similarly, Serverless or FaaS is also bond to start on every event which can have different latency in the different system depending on a large number of factors which may range between few milliseconds to several seconds.

Execution/Cold start latency

Similar to Startup latency cold start latency also depends on various factors such as the programming language used, the number of dependent libraries used, the number of lines in the code, the need to connect or load any other external system or resource and etc. But many of these are in developer’s control and can be reduced as per the demand.

Cold start depends on the FaaS provider as it works based on the cold-start frequency, for example, if you processing 20 events per seconds which each event taking 100ms to execute in AWS Lambda you’ll see a cold-start on every 100K to 200K events but if you processing 1 event per hour you’ll see cold-start at every event.

Use cases of Serverless or FaaS

Front-end driven Applications

A typical front-end driven application consists of the very basic architecture of having a client, a server and a database where the client is connected to server and server is connected to database. With features like Auth, File Storage and Database storage.

To convert the same application into Serverless or FaaS we need to expand the architecture and avail third-party services as mentioned below:

• Move the auth service on Auth0 or etc.
• Move file storage to S3 or Google Cloud storage etc.
• Move Database to Firebase or any other database server.

We can keep the front-end of the application to be served directly from function’s output but if the function is computed heavy we can move the same into a different function.

Message-driven applications

Let’s understand the same by another simple example. Support there is a backend service handling user requests to and redirecting them to a different URL after capturing some information like the URL is clicked and etc. Very similar to a Pay-Per-Click service.

The architecture of the application is very simple containing a server to receive input, a message bus to pass the captured information and message bus stores the information into database.

To convert the same into Serverless or FaaS we only need change is the message bus consumer to a Serverless or FaaS function. An asynchronous message processing is a best suitable use case for Serverless or FaaS, unlike a consumer, a FaaS function runs within the event driven context its generated.

API Gateways in Serverless or FaaS

In general API Gateways we have a route and a callback for that route, in Serverless or FaaS these callbacks are the Serverless functions which invoked as per the matchinGatewaysg route.

When a router receives a request it in invokes the configured Serverless or FaaS function with a representation of the original request. A Serverless or FaaS function can allow more concise request parameters or the entire HTTP request is passed as a JSON object, Serverless or FaaS function then executes the logic and return a result to API Gateway which will transform the result into an HTTP response. API Gateways can also perform authentication, input validation, response code mapping and etc.

The use for an API Gateway with Serverless or FaaS function is microservices in a serverless way which packed with all the scaling, management and other benefits of Serverless or FaaS.

Benefits of the Serverless or FaaS

So far almost every aspect of Serverless or FaaS is discussed in a brief, so let’s talk about the pros and cons of using Serverless or FaaS

Reduced operational and development cost

Serverless or FaaS offers less operational and development cost as it encourages to use third-party services like Auth, Database and etc.

Cheapest Autoscale

The best thing about Serverless or FaaS as it scales automatically and handled by providers itself and you only pay the computer you needed which saves you a lot in case of ocassional requests and inconsistent traffic.

Easier packaging and deployment

Serverless or FaaS have fairly simple packaging and deployment steps compare to packaging and deploying an entire server.

Fast and easy experimentation

Simplified packaging and deployment make possible for the business to experiment more as the time to market is significantly reduced.

Future of the Serverless or FaaS

Serverless seems all in good at first but there are still many things which need development in future

Migration of an existing application

Migration of an existing application to Serverless or FaaS needs more robust tooling by automating some of the manual tasks.

Migrating the state of an existing application is big challenge as in some cases it needed a complete refactor of the application.

Platform

Currently available platforms are not that robust and have several limitations such as execution duration, startup latency, and cross-function limits and etc.

More players are needed in this direction to solve these platform related issues for better and easy adaption.

Testing

There are still lots of work to be done to support integration and acceptance testing for Serverless or FaaS.

The idea is to move more towards concepts like testing in production and monitoring driven development. Once the code is done and passes a minimal unit test cases, deploy the same on a small portion of traffic to see and compare to the previous one.

Community

A good sized community already exists which helping people through articles, meetups, conferences, events and etc. will continue to grow.

Let me know your thoughts on Serverless or FaaS.