Mastering the Serverless Mindset: Design Principles You Need to Know

Everyone talks about the benefits of Serverless applications, but few understand the importance of designing them well.

Serverless is a paradigm shift that requires an entirely different way of thinking. Approaching serverless architecture with a traditional persistent-server mindset can lead to costly errors and sub-optimal performance.

Here are 8 Design Principles you need to know when building #serverless applications:

Single-Responsibility Principle

The smallest unit of a Serverless application is a function. Serverless functions should follow the single responsibility principle, meaning they should be short-lived and serve a specific purpose.

If a Lambda #function needs to perform multiple tasks, it's wise to break them up into separate functions.

It's essential to keep the execution time as short as possible. Functions should not continue running beyond the request lifecycle.

If more processing is needed, it's recommended to take advantage of asynchronous workflows. This could look like using a SQS queue for downstream processing while pausing the original #lambda's execution.

Horizontal Scaling over Vertical

Focus on scaling your serverless applications horizontally rather than vertically. When designing a serverless application, it's imperative to rely on its ability to horizontally scale during peak times.

By following the first design principle and keeping functions short and responsive (a few hundred milliseconds), your application will be able to handle high volumes of requests with ease.

During peak times, your application will automatically scale out to handle the increased load, resulting in quick response times for your end users. So, don't worry too much about the number of requests you're making (to a point), as #aws has the ability to scale automatically.

If possible, it's recommended to break down long running tasks into smaller pieces. When you break down large tasks into smaller ones, you can create a more efficient and cost-effective application.

Embrace Statelessness

A function's runtime environment and it's underlying infrastructure are short-lived, this means that local resources like temporary storage may not be persist across invocations.

For highly durable requirements, use persistent storage like S3 rather than relying on temporary resources.

Always assume that the function is stateless and use a database if you need to perform any action with entity state.

While it's recommended to instantiate reusable clients globally, keep in mind that serverless functions can spin up and down frequently thus avoid relying on globally-scoped variables that may not persist across multiple function executions.

Therefore, it's important to start each function execution with a "clean slate" and load only the necessary resources for that specific execution.

Be Hardware-Agnostic

When working with serverless applications, avoid thinking about server-side hardware. Hardware abstraction is one of the main benefits of serverless.

Write code and use dependencies that are hardware-agnostic. Hardware-specific features such as CPU flags may not always be available, so instead focus on using environment variables for configuration.

Once your functions are implemented, you can then fine-tune their performance using various optimization techniques.

Orchestration over Choreography

Don’t invoke functions from within other functions. Use orchestration over choreography.

Chaining function executions within your application's code for coordination leads to an application that is tightly coupled and monolithic. It's also slower, more expensive and considered an anti-pattern by AWS.

A better approach is to use Step Functions to orchestrate your functions and communication flows. Step Functions provide an easy-to-understand state machine diagram of your workflow and excellent traceability.

Embrace Asynchronous Operations

Embrace asynchronous operations and event-driven architecture in your system design. This will prevent customers from having to wait for every action to complete.

Serverless applications by nature are distributed systems. Using events such as an S3 object write or an update to a DynamoDB stream as async triggers can enable transaction execution in response to business functionalities.

This promotes just-in-time processing and helps you achieve a lean service design.

Consider the Dependency Lifecycle

Lambda functions have dependencies, and any dependencies not already available in the execution environment must be included as part of the deployment package.

When new dependencies are required, they need to be added to the deployment package. Conversely, if dependencies are no longer used, they should be removed.

This means that the function and its dependencies are coupled as a unit of deployment.

Don't create generalized deployment packages with commonly required dependencies deployed with all your functions. Create targeted and minimal deployment packages for each function, containing only the dependencies they need.

If you need to share dependencies or libraries across functions, use Lambda layers.

Expect Failures

Recognize that random failures can occur at any time. Design your serverless applications to handle failures gracefully.

This involves designing idempotency and retry into almost every function in your application, so that identical requests can be handled and produce the same outcome in the system.

Step Functions make it easy to retry Lambda functions when there's a problem

You cannot trust whether requests are always going to come in the expected order or frequency, so design your systems with that in mind.

Conclusion

To ensure that our systems are fast, reliable, and cost-effective, it's important to follow serverless #designprinciples.

This includes keeping functions focused and small, designing for concurrent executions, and not worrying about the number of calls made (within reason). Orchestration with managed services and designing with idempotency in mind are also key.

While the idea of serverless architecture can seem intimidating at first, it simply takes practice. The goal of a solutions architect is to take a complex problem and create a simple and effective solution.

To achieve this, it's important to use the tools the way they were intended to be used.

With the right approach and a commitment to best practices, serverless can be an incredibly powerful and efficient way to build modern applications.

If you want to learn more, check out the Serverless Applications Lens from the AWS Well-Architected model