Functions as a service (FaaS)

Function-as-a-Service (FaaS) is a key enabler of serverless computing. FaaS gets its name as it is a way to scale the execution of simple, standalone, developer-written functions, where state is not kept across function invocations. FaaS simplifies deploying applications to the cloud. With serverless computing, you install a piece of business logic, a “function,” on a cloud platform. The platform executes the function on demand. So you can run backend code without provisioning or maintaining servers.

The cloud platform makes the function available and manages resource allocation for you. If the system needs to accommodate 100 simultaneous requests, it allocates 100 (or more) copies of your service. If demand drops to two concurrent requests, it destroys the unneeded ones. You pay for the resources your functions use, and only when your functions need them.

FaaS is a relatively new concept that was first made available in 2014 by hook.io and is now implemented in services such as AWS Lambda, Google Cloud Functions, IBM OpenWhisk and Microsoft Azure Functions. It provides a means to achieve the serverless dream allowing developers to execute code in response to events without building out or maintaining a complex infrastructure. Imagine the possibilities! Instead of scaling a monolithic REST server to handle potential load, you can now split the server into a bunch of functions which can be scaled automatically and independently. If you’re familiar with microservices, this image might make you feel something

Functions in FaaS are event driven, invoked by a user’s HTTP request or another type of event created within the provider’s platform. To match the rate of function invocations, the platform automatically scales the resources available to execute more instances of the developer’s function in parallel. The majority of serverless research has targeted mapping applications to this model, or has focused on scheduling policies or mechanisms for orchestrating FaaS setups. However, we are interested to know if the computational building blocks of FaaS, namely, commodity servers used in modern cloud data centers are suitable for such workloads. FaaS applications differ from traditional cloud workloads in ways that may jeopardize common architectural wisdom.

Firstly, FaaS functions are typically short-lived and priced in multiples of a 1ms, 10ms, or 100ms time quantum. Function execution time is usually also capped. Providers must rely on the fine-grained interleaving of many short functions to achieve high throughput. This fine-grained interleaving causes temporal locality-exploiting structures like branch predictors to underperform, raising questions about present-day computer architectures’ ability to execute FaaS efficiently. For instance, we observe a 20x increase in branch mispredictions per kilo-instruction (MPKI) when comparing our shortest functions to longer functions.

Secondly, functions often run in a deeply virtualized manner: inside containers which might run within virtual machines. This causes a number of OS-level overheads. We find that flat overheads like the cold start latency of 500ms or more have an outsized impact on short functions.

Lastly, FaaS developers can write their functions in almost any language. Each platform has preferred languages, but developers may upload their own container to run a chosen application in the FaaS environment. Together, these features make for a highly dynamic system, with many, fast-changing components, which we have found bring new, unforeseen overheads and challenges for architectural optimization. We provide the first server-level characterization of a Function as-a-Service platform by carefully investigating a compute node of an open-source FaaS platform, Apache OpenWhisk (sold commercially as IBM Cloud Functions). This contrasts with previous work solely focusing on black-box reverse-engineering of commercial FaaS systems. With full control of our deployment, we precisely induce function co-location and access hardware performance counters, something impossible for an external black-box analysis. Our bottom-up approach enables us to decouple overheads in managing the cloud platform from the overheads caused in the server context. This reveals the architectural implications of FaaS computing. We identify a range of new overheads that affect FaaS execution with short functions affected most acutely.

summarizes these overheads in the context of the full stack of overheads. Our contributions are as follows:

We perform the first server-level characterization of a Function as-a-Service platform to determine architectural and microarchitectural impacts.
We develop and open-source FaaS Profiler, a new FaaS testing platform. This enables other researchers to conduct their own profiling with OpenWhisk. We also open-source benchmarks, measurement data, and scripts used in this paper.
We characterize and attribute the individual contributions to server-level overheads, including containerization (20x slowdown), cold-start (>10x duration), and interference (35% IPC reduction) overheads.
We discover that FaaS workloads can cause certain architectural components to underperform. This includes 20x more MPKI for branch predictors and 6x higher memory bandwidth under some invocation patterns.
We identify a mismatch in demands between the FaaS provider, developer, and service end user, with respect to the present pricing model. This motivates further research into pricing, Service-Level Agreements (SLAs), and architectural methods to alleviate the mismatch.

Functions as a Service offer you (and your organization) the ability to:

Create high-grade, quality functions that people can’t write themselves.
Turn that function, or set of functions, into a service for people to use.

Functions as a Service places a function onto a cloud instance, making it available for use by developers, applications, and other functions. When you write a function to a cloud instance, that function can then be served to any computer without relying on the user’s system hardware or software for their service to work.

It’s like ordering takeout from a restaurant: they don’t have to rely on the tools in your kitchen to prepare a delicious meal.

Cloud functions allow:

The function to work on the cloud’s resources—not an individual’s computer
The code to be written in any language
The service to be accessed anywhere with a network connection

These functions are becoming more common in machine learning, where ML modeling time, development resources, and talent are all very valuable and the product of their efforts results in a function that’s both hard to reproduce and useful for people. An example of an ML FaaS is Open-AI’s GPT-3 you can access it via a REST API.

Why Function As a Service (FaaS) Matters?

Serverless is an event-driven or code execution where underlying infrastructure is abstracted. Applications run in stateless containers that are spawned based on the triggering of events. Function as a Service is a layer that executes specific business logic or code with the cloud vendor providing the level of abstraction. FaaS allows users to only pay for the duration of execution of functions executed. So, it is consumption vs subscription.

the three of the main advantages of FaaS:

Managing servers is no longer your problem
The platform manages horizontal scaling for you
You only pay for what you use

By managing the servers for you, FaaS abstracts the server platform away from your application too. You can write your functions in almost any language. You can access other cloud resources like databases and caches.

If you conform to the platform’s defined interfaces, your service will work. This freedom doesn’t come for free, though. FaaS places constraints on functions, and it’s not always the best option.

So why isn’t everyone migrating their applications to serverless?

FaaS isn’t always the best option, or even possible, for some applications. There are design constraints. But first, let’s look at when it works well.

The name “Function as a Service” isn’t an accident or affectation.

Your service needs to operate like a mathematical function. Each invocation must be stateless; you can’t assume that information about one call to your service will be available in a subsequent request. Any state your application needs must be externalized to a database or filesystem. This restriction makes perfect sense. FaaS provides scaling for you, but without demanding any intimate application knowledge. It can only do this by assuming that it doesn’t have to manage any application state for you.

So if your functions don’t maintain state or solely rely on external resources for it, they’re a good fit for FaaS. RESTful applications are a good example. The functions externalize resource state while clients bear responsibility for maintaining their own. An event-driven service that needs horizontal scaling can enjoy running as a function. FaaS platforms use the events to create instances of the functions and react based on the volume of requests. RESTFul and other event-driven applications are a good fit, and so is work that runs on a schedule. Instead of paying for one or more servers that sit dormant most of the time, you can write the job as a function.

How FaaS works

Functions can be accessed through one of several triggers that you define when you create the function. For use in an app, functions can occur on events that happen in the database. For example, a function can be triggered when a new item is written to a database, changed, or deleted from the database.

An “on-event” function might send an email to a user when their account is created. A function could also be written to send a notification to a user, or set of users, in a chatroom when a new message has been written to the room (equivalent to a new write on the database).

A function takes some inputs, and returns an output, so to use the function, you will have to know:

The data schema of the input so the function ran properly process the input data.
The data schema of the output so you know what to look for from the data.

Functions will vary entirely from use case to use case. Here are some examples:

A function could take an input of a picture and output a label of cat or dog.
A function could take input of a topic and output a sequence of words.
A function could take in a YouTube video URL and output a JSON of all the video’s stats.
A function could take as input a word document and output a formatted PDF.

The larger cloud providers will have software development kits (SDKs) built to interact with their functions. If you wanted to write a function and allow other companies to use it, you can expose the function through an endpoint, commonly a REST API or, simply, a URL.

Advantages of FaaS

The automatic scaling you get with serverless computing is a significant benefit. It saves you money and protects you from unexpected spikes in usage. As long as you pay your bill, your application will remain available. Without dynamic scaling, you have to size your system based on the most substantial level of utilization, not its average. This means paying for resources that spend most of their time doing nothing.

Fewer developer logistics — server infrastructure management is handled by someone else.
More time focused on writing code / app specific logic — higher developer velocity.
Inherently scalable. Rather than scaling your entire application you can scale your functions automatically and independently with usage.
Never pay for idle resources.
Built in availability and fault tolerance.
Business logic is necessarily modular and conform to minimal shippable unit sizes.

The two biggest FaaS benefits are overall scalability and the flexibility for the developer.

Scalability

A function on the cloud (especially with Kubernetes architecture) can scale to suit as many users as it needs. It also scales independently of other services.

If a search function suddenly becomes more popular than an alphabetizer function, the search function can scale separately from the alphabetizer, enabling the service to be offered to clients, while saving costs by only paying for the resources of the search function itself.

This scalability means:

You won’t pay for idle resources.
There are fewer logistics when cloud resources manage servers.

Developer’s choice

FaaS allow developers to work in whichever coding language they are familiar. Because of the container framework most devs operate in, you do not have to determine the primary operating system of your target customer and fit your dev skills to meet them.

This also opens your service to many more people because communication isn’t being translated from OS to OS.

Disadvantages of FaaS

Drawbacks of functions as a service are lack of coding transparency and the organization of the code base.

Decreased transparency. Someone else is managing your infrastructure so it can be tough to understand the entire system.
Potentially tough to debug. There are tools that allow remote debugging and some services (i.e. Azure) provide a mirrored local development environment but there is still a need for improved tooling.
Auto-scaling of function calls often means auto-scaling of cost. This can make it tough to gauge your business expenses.
You now have a ton of functions deployed and it can be tough to keep track of them. This comes down to a need for better tooling (developmental: scripts, frameworks, diagnostic: step-through debugging, local runtimes, cloud debugging, and visualization: user interfaces, analytics, monitoring).
Solutions for caching resources between stateless requests (i.e. DB connections) and recycling network requests are still pending.

Coding transparency

Testing code on the cloud still isn’t totally developed. Bugs can be harder to spot than writing code and running it locally.

In most cloud systems today, there is not a good way to test the operability of a function until it is deployed. This requires either:

More testing time
More skilled developers to spot errors before deployment