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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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
Serverless or FaaS offers less operational and development cost as it encourages to use third-party services like Auth, Database and etc.
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.
Serverless or FaaS have fairly simple packaging and deployment steps compare to packaging and deploying an entire server.
Simplified packaging and deployment make possible for the business to experiment more as the time to market is significantly reduced.
Serverless seems all in good at first but there are still many things which need development in future
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.
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.
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.
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.
Google Develover Expert — WebTechnologies and Angular | Principal Architect at Naukri.com | Entrepreneur | TechEnthusiast | Speaker