Best practices for serverless computing

Function as a Service (FaaS) is the subset of serverless computing that’s focused on event-driven triggers where code runs in response to events or requests. Reports and Data predicts that Function as a Service (FaaS) will reach around $53 billion by 2028. As the adoption of FaaS continues to increase, it’s important to consider the best approach for implementing these serverless solutions.

The basics of FaaS

A FaaS solution allows developers to write and deploy code without worrying about servers or other infrastructure management. FaaS solutions differ from Platform as a Service (PaaS) solutions because the functions are completely event-driven and stateless. Developers using functions tend to write less code because there’s less to manage on their own. Functions can easily scale horizontally to meet demand, simply duplicating the function to perform the same task for each request. When the demand drops, the functions automatically scale back down as they are no longer needed.

FaaS thrives on simple and repetitive functions without consistent workloads or continuously high volumes of requests. Adding a FaaS component to an existing architecture to handle event-driven functions can save significant resources and reduce costs. By combining long-running servers with on-demand reactive functions, developers can use the speed and agility of simply writing functions to extend existing applications with serverless functionality.

Best practices for using FaaS

Developers who choose to use FaaS can take advantage of its fast time to market due to the ease of development and testing it provides. Since they no longer need to worry about things like capacity planning or ongoing maintenance, they can focus solely on coding and development for the application. Simply put: developers can do less to get their cloud applications running. While FaaS is a great solution, it may not be the best choice in every scenario, and there are key practices that developers must follow to get the best results. To use FaaS appropriately, make sure that each event triggers only one function, that the functions are short-lived, and that they are stateless.

One event, one task

To keep FaaS solutions simple and working well, it’s important that each event only triggers one function. For instance, a function should be responsible for a singular task like getting a list of records from an external API or geolocating a request. Although it can be done, it’s best to avoid having one function call another function. Keep your code short and lightweight to optimize the performance of FaaS. By narrowing the scope of each function, it starts faster, it’s easier to test, and it has a smaller attach surface. It also allows secrets needed by functions to be scoped to just the ones that need them instead of all functions.

Keep functions short-lived

There are typically timeouts for function executions and the amount of time varies based on your provider. It’s important to keep functions short-lived, as they’re intended to execute efficiently and then power down to open up more compute capacity.

Remember functions are stateless

Stateless functions are simpler. Their components are easier to implement and provide the predictability that makes testing and deploying to production simpler. If functions do need persistent data, that information can be stored in a database so that it can be pulled again from the database in subsequent requests.

Test and configure

Test your functions to find the optimal duration/memory needs. Keep dependencies to a minimum and internalize dependencies outside of the entry point. It’s important to be able to test functions locally using your favorite IDE, test frameworks, and tools. Writing functions and testing them locally enables a fast inner loop—a short edit, test, and debug cycle.

Keep your functions secure

Keep secrets out of source. Additionally, developers may be tempted to use a single permission model for all functions, granting functions access to components of the application not necessary for it to perform its task. Consider giving each function permission to only access what is necessary for it to execute its task to avoid major catastrophe in the event of a security breach.

Future-proof your setup

Create your functions outside of an app for an easier migration or so that you can more easily refactor a monolithic application if needed. Remember, some architectures are a more natural fit for microservices than others, so if your application logic contains multiple sequential steps that all depend on one another, abstracting each of them into individual microservices may not be the best solution.