Introduction to Serverless Applications

Azure Functions belongs in the category of serverless applications. Serverless applications are cloud-native applications that are deployed in such a way that all infrastructure setup is outsourced to the cloud provider.

Even though these applications are called serverless, it doesn’t mean that there are no servers involved. Any web application requires some kind of server to host it. Hosting would not be possible without a server. The word “serverless” refers more to the fact that we don’t take into consideration how the servers are set up.

If we want to deploy a serverless application, our responsibility is limited to the following:

• Building the application

• Deploying the application

• Configuring the application (which includes scaling, orchestrating, and securing it)

We don’t need to configure the host or set up a virtual machine to host the application. All of this is done automatically by the cloud provider. For example, we can state how many instances of a particular application we want, or whether or not we want it to scale itself as the amount of incoming data increases. It will then be the responsibility of the hosting platform to set up the appropriate infrastructure to achieve this configuration.

How serverless applications differ from traditional web applications

Because serverless applications are set up differently from traditional web applications, they are typically different in structure too. Typically, a serverless application is built with the following characteristics:

• It’s lightweight.

• It executes an atomicAtomic means something that is small but cannot be reduced any further if it is to remain useful. piece of functionality, which typically runs for a short time.

• It’s stateless, which means that it doesn’t preserve any data between runs.

• It doesn’t have any long-running background processes.

• It can be triggered automatically when needed.

• It isn’t running unless needed.

There are some exceptions to these, especially in terms of statelessness and long-running background processes. For example, durable functions are designed to run for a long time and can maintain their state. But even then, they only run when they are needed and are much more lightweight than a traditional application performing similar functionality.

Based on these characteristics, serverless applications are also structured differently from traditional web applications. A typical web application would contain many components, as it is responsible for a large chunk of functionality inside a whole website. It will need to have a request processing filter, a rich dependency injection system, the ability to maintain the session state, and so on. A serverless application, on the other hand, would consist of isolated endpoints, each of which is designed to perform a relatively simple action. For example, while we would use a traditional web application to deliver a web page, we would call a serverless application endpoint to perform a single calculation.

There are scenarios where traditional web applications are more suitable than serverless applications. As has been already mentioned, it would probably be difficult to build a web application back-end functionality by relying purely on serverless application endpoints. Traditional web application frameworks, such as ASP.NET Core, allow us to achieve it with much less effort because they were designed for this specific purpose. Nevertheless, there are many scenarios where serverless applications are a much better choice than traditional web applications.

The benefits of using serverless applications

There are many benefits of using serverless applications. Some of them are purely technical, while others are cost-related. They can be summarized as follows:

• The deployment and configuration of a serverless application is quick because there is no need to manage the hosting infrastructure.

• A serverless application is not running while it’s not doing anything, saving the costs on resources.

• A serverless application endpoint tends to be better decoupled from the rest of the code, which makes it easier to modify it when needed.

• Serverless applications can be easily configured to work with many different types of triggers, events, and data bindings, such as standard HTTP endpoints, message queues, etc.

• Serverless applications can be configured by using timers, which makes them suitable for timed background jobs.

• Serverless applications can be configured to scale automatically when the demand increases.

The ability to scale the application automatically is known as elasticity. It is worth being mentioned in more detail.

Elasticity

An application is elastic when it can scale itself in or out depending on the demand. For example, we might have a period when no requests are coming into the system. In this case, having a single application instance on standby is sufficient. It’s still sufficient when we have only a few requests coming in.

Let’s assume that the number of requests suddenly increases. It might be a particular time of the day when more users than usual want to visit our website. Or it might be some event that prompted all these users to visit it. Whatever it is, we need to be prepared.

So with elasticity in place, when the system detects that the current number of instances is getting close to their maximum capacity of being able to deal with the incoming requests, it spawns another instance. Now, there are multiple instances of the application running and we can deal with a much higher number of incoming requests without any performance penalties. If the number of requests increases even more, the application will scale itself out again.

However, the peak of requests will eventually subside. When this happens, we no longer need all these application instances. Imagine that we have 10 application instances and only 5 incoming requests per minute. Keeping these redundant instances is not wise. They will use resources and it will cost us money. But if the application is elastic, it will address this, too. The application will be automatically scaled back so there are no redundant instances left.

Without elasticity, changes in the load are much harder to deal with. We already covered the fact that leaving all redundant instances running is not cost-effective. But likewise, writing our own script that is capable of detecting the changes in load and scaling the application accordingly is difficult and time-consuming. The built-in elasticity of serverless applications saves us time, effort, and costs.