Advanced Serverless Architectures with Microsoft Azure: Design complex serverless systems quickly with the scalability and benefits of Azure

In the previous chapter, you created all of the core individual components of a complete serverless architecture. The important thing to note is the total separation of frontend and backend development—this will free both disciplines of development to progress rapidly.

In this chapter, you will learn how to connect them up to deliver the first feature of your serverless application. Here, we will be covering asynchronous processing and caching as a way to increase the scalability of serverless architecture.

Individual serverless components have the capability to scale infinitely (up to the capacity of your cloud provider, which is infinite when infinity is considered relative to an average company's compute power). This sounds, and indeed is, amazing and very useful, but these components tend to expose issues with application architectures that you previously couldn't see. This issue is called serverless backpressure. The following backend components can be impacted by this backpressure:

One of the most useful components in scaling a serverless architecture is the queue. Queues are a key asynchronous processing concept. In a queue, data points are added to the back of the queue and taken from the front. An example of this is a first-in-first-out data structure. In a cloud architecture, a queue will generally store events or messages from an upstream process until subscribers downstream have the time to process them.

An important thing to understand before deciding to use a queue is the compromise you are making in using one. In a synchronous operation (that is, inserting a record into a database all in one operation), if something goes wrong, you have instant feedback to your user. In an asynchronous operation (that is, dropping an event onto a queue that a worker later picks up to insert into the same database), if the later operations go wrong, then the user has usually left the application and cannot fix their mistake or call support.

A good way to try...

The practice of storing previously requested data in a small, high-speed data layer and returning it, instead of requesting the data again, is called caching. Caching is a vast and complex topic, so this book will focus on the cheapest wins for your application rather than attempting to cover everything.

Caching both reduces replicated demand for compute and speeds up applications. It is also very useful for reducing serverless backpressure in two ways: first, by reducing the number of requests that hit the backend and second, by reducing the number of requests that hit "weak" resources.

Client-side caching is the easiest way to have an immediate impact on the number of requests you see per second, and also the easiest to understand in terms of requirements. It also immediately improves the performance of your application for your end users, as they receive data much faster. However, client-side caching is frequently done badly or not at all. Serverless has a great way of highlighting...

A lot of applications are synchronous. That is to say, when you perform an action, the program processes it and returns the answer, holding up the program and the user from doing anything else until it has returned the answer. This is the way most developers design their applications, particularly those used to REST. However, this can become a serious barrier to scalability. If your application needs to process complex requests, the time taken becomes intolerable to the end user. This is the point where most developers will decide to adjust the behavior for this request so that the synchronous part simply includes validation, and processing is done asynchronously. Asynchronous behavior is where the user performs an action and the application processes it when it has time, rather than keeping the user sitting there.

With a serverless architecture, it is a very good idea to shift your mindset. When designing applications, you should endeavor to be asynchronous by default...

In this chapter, you have learned about the principles of scalability in a serverless architecture, which will help guide you throughout your serverless application development. By making your applications asynchronous and utilize caching, your serverless application will scale effectively. You've also added headers to explicitly control caching behavior and utilized queues and other asynchronous methods. In the next chapter, you will be learning about Durable Functions, and how you can use them to orchestrate long-running workflows.