Journey to a Serverless Application in Azure

You already know how to develop and deploy an application with a client server architecture?
— GOOD, but is there maybe a different and more efficient way to do this?

In a lot of projects the default solution for most applications is a containerized approach. This works fine in most cases, but is there maybe a more lightweight solution? Yes, there is! In this series of articles I will show you how to create a simple todo app in a serverless way.

Why?

There are a lot of applications in the wild with big servers idling around most of the time. Let’s assume they are not overprovisioned in general, but require the full power only a few times a day to handle some peaks. This doesn’t sound really economic or environmentally friendly.
In this article I will show you a way how to build an application in a serverless way which only consumes and blocks the resources it really needs.

If you think about the application with the few peaks over the day again: even if it may not be possible to use a complete serverless solution for it, you might be able to handle the peak requests in a serverless way. With this hybrid solution you are able to run your software on a smaller machine and still can handle the peaks in a more cost efficient way.

Some other advantages of serverless applications are:

• lower costs to run an application with irregular load
• reduction of management complexity (zero servers or containers to manage and keep up to date)
• better scalability

If you want to read more about serverless computing in general, you can take a look at the wikipedia article.

Structure

This article is splitted into multiple parts. This part is about the motivation and the overall architecture of the example app. The second part is about the serverless backend and the Azure Functions itself. In the third part we talk about the frontend hosted as a static website. The last part demonstrates how you can implement serverside updates via websockets in combination with the SignalR service of azure to synchronize updates between different clients.

In the articles I use screenshots of the azure portal for the resource creation. In the repository you can find the terraform code for the same purpose.

Example Todo App

As example application we develop a simple todo app with the possibility to add tasks, view them and mark them as completed. We will have a shared task list for all users who visit the website. To do so we build a rest api with the following endpoints:

• POST: /api/tasks → Add a new task
• GET : /api/tasks → Get all not completed tasks
• POST: /tasks/{id}/complete → Mark task with id as completed
• GET: /tasks/completed → Get all completed tasks

A task has the structure:

{
  "id": "1234",                    // set by the create function
  "description": "Write Medium Blog Post",
  "dueDate": "2021-04-30",        // can be null
  "completedDate": "2021-05-03"   // set by the complete function
}

The focus is not set to the source code of the frontend or the logic of the functions itself. Instead this should demonstrate how a serverless architecture could look like.

Architecture

We develop the application in a completely serverless way, that means if there is no traffic, there will be zero running instances.

At the end the overall architecture will look like this:

rough architecture

For the rest api we develop one function for each endpoint. We use the serverless version of Cosmos DB as database. The frontend is stored and delivered by a Blob Storage.
At last we use SignalR to implement the websockets.

If you don’t want to miss any part of this journey or a lot of other interesting stories, feel free to subscribe to Leon Fausten or Holisticon.

Now let’s start in the next part with the Azure Functions.