Function as a Service (FaaS) offerings, such as AWS Lambda and Azure Functions, are relatively new software execution environments that have given credibility to the creation of simple microservices without the need for servers. The industry has coined the term serverless to refer to these types of execution environments.1
FaaS offerings provide event-driven compute capabilities without the need to purchase, set up, configure, or maintain servers. FaaS offerings such as AWS Lambda and Azure Functions give you virtually unlimited scalability with the ability to pay at a subsecond-metered level.
Services such as AWS Lambda can scale to almost any rational scaling size necessary, without any actions required to make that happen. This is the true power of FaaS.
Here are some typical use cases for FaaS:
· Image transformation for newly uploaded images
· Real-time metric data processing
· Streaming data validation, filtering, and transformation
It is best suited for any sort of processing where:
· Operations need to be performed as the result of an event occurring in your application or environment
· A data stream needs filtering or transformation
· Edge validation or regulation of inbound data is necessary
There currently is a lot of hype around FaaS. However, FaaS services aren’t for everything. Their real power is useful in specific types of architectures. The following are some specific types of applications that can effectively make use of FaaS. These examples make use of the AWS cloud and AWS Lambda FaaS service.
Example Application #1: Event Processing
Consider a photograph management application. Users can upload photos to the cloud, which are then stored in a storage service such as S3. The application displays thumbnail versions of those pictures and lets users update attributes associated with those pictures, such as name, location, names of people in the picture, and so on.
This simple application can utilize AWS Lambda to process images after they are uploaded to S3. When a new picture is uploaded, a Lambda function can be automatically triggered that takes the picture and creates a thumbnail version of that picture and stores the thumbnail version in S3. Additionally, a different Lambda function can take various characteristics of the picture (such as size, resolution, etc.) and store that metadata in a database. The picture management application can then provide capabilities for manipulating the metadata in the database.
This architecture is shown in Figure 18-1.
Figure 18-1. File upload Lambda usage
The picture management application does not need to be involved in the file upload process at all. It can rely on standard S3 upload capabilities and the two Lambda functions to do all processing necessary to complete the file upload process. So the picture management application has to deal only with what it is good at: manipulating metadata in the database for existing pictures.
Example Application #2: Mobile Backend
Consider a mobile game that stores user progress, trophies, and high scores in the cloud, making that data available for a shared community as well as enabling device portability for individual users.
This application involves a series of APIs on the backend that are created so that the mobile application can store data in the cloud, retrieve user information from the cloud, and then perform community interactions. The cloud backend runs on AWS.
The necessary APIs are created by using an API Gateway2 that connects with a series of Lambda functions. The Lambda scripts perform the operations necessary, in conjunction with some form of database, to handle the cloud backend for the mobile game.
This architecture is shown in Figure 18-2.
Figure 18-2. Mobile backend Lambda usage
In this model, no servers are needed on the backend, and all scaling is handled automatically.
Example Application #3: Internet of Things Data Intake
Consider an application that takes data from a huge quantity of data sensors deployed around the world. Data from these sensors arrives regularly. On the server side, this results in an enormous quantity of data being regularly presented to the application for storage in some form of data store. The data is used by some backend application, which we will ignore for this example. All we will be concerned with is the data intake process.
The data intake needs to validate the data, perhaps perform some limited processing on the data, and store the resulting data in the data store.
This is a simple application that performs only basic data validation and verification and stores the data in a backend data store for future processing. However, though the application is simple, it must run at a massive scale, potentially in the order of millions or billions of data intake events per minute. The exact scale is dependent on the number of sensors and the amount of data each sensor generates.
This architecture makes use of a data intake pipeline3 that sends data to an AWS Lambda function that performs any necessary filtering or processing of the data before it’s stored in the data store.
This architecture is shown in Figure 18-3.
Figure 18-3. Internet of Things sensor intake example
Lambda is well suited to handling the huge volume of data that must be ingested at a high speed regularly.
Advantages and Disadvantages of FaaS
FaaS offerings have one primary advantage: scale. AWS Lambda, for example, is very good at handling massive scale loads without the need to increase the amount of infrastructure allocated to your application.
It accomplishes this by optimizing its operation for code that is relatively simple in nature, allowing it to be easily spun up on multiple servers in multiple stacks quickly and effectively, on an as-needed basis.
This is the sweet spot for FaaS: a small code footprint executed at mammoth scale. That sweet spot makes AWS Lambda an effective solution for all three of the example architectures we looked at.
So where should you not use FaaS? To answer that, let’s look at the disadvantages of FaaS services:
· Implicit coding requirements (assumed simple, event-driven, fast-processing, limited operating environments)
· Typically complex configuration and setup
· Typically no native built-in staging or testing environments
· Typically no native deploy/rollback capabilities built in
· No or limited native development environment for building and testing FaaS functions
In short, FaaS is great for running small scripts at large scale, but it is poor at all of the other things necessary for a large-scale application deployment. It’s ill equipped to perform complex calculations and complex interactions and is not a good fit for complex code and execution environments. The more complex the code, the less ideal it is for use in FaaS. There are companies focused on serverless computing that are working on solving some of these issues, such as improving the development and deployment environments. But these are new and untested tools and capabilities.
Used effectively, FaaS is a technology that will significantly help in your extreme scaling needs. However, be careful to limit its use to only those tasks for which it is well suited. For compute execution needs outside of the FaaS sweet spot, use other deployment/execution options.
Serverless Hype and the Future of FaaS
There are some people who believe that AWS Lambda and other FaaS offerings are “taking over the world” and will eventually cause traditional server-based computation and container technology (such as Docker and Kubernetes) to become obsolete. I firmly disagree with this assessment. FaaS computation services such as AWS Lambda and Azure Functions give a powerful, high-scale computation option for a specific class of computing needs. However, they will not “take over the world” or replace the need for and value of traditional server-based and container-based computation.
Be careful trying to force fit serverless functions into solving all your computing needs. There are people who are trying to make their applications run “100% on Lambda.” FaaS computation is not a perfect solution for all computation needs, and it should not be force fit into that role. Container- and server-based software, in my opinion, will always represent a larger piece of the computation pie than serverless/FaaS will.
Use the right tool for the right purpose and don’t force fit FaaS into situations where it doesn’t naturally fit.
1 The term serverless also applies to cloud service offerings, such as DynamoDb, S3, and Azure Cloud Storage. This is a different interpretation of the term than what applies to Functions as a Service (FaaS).
2 The Amazon API Gateway is an API creation service that is designed to work closely with AWS Lambda.
3 Amazon Kinesis is a real-time streaming data intake pipeline that is designed to handle the intake of vast data streams and works closely with AWS Lambda.
You can support the site and the Armed Forces of Ukraine by following the link to Buy Me a Coffee.
