Lesson 5.1: Introduction to Serverless Architecture in Azure

In the last few years, the concept of serverless computing has become much more prominent, but what does that actually mean? There are clearly servers in the cloud running code to implement our web application or service. But with serverless cloud implementations, we free developers from infrastructure management and allow the cloud providers to manage and scale the service depending on its traffic.

In an article on MartinFowler.com, they provide this definition:

“Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.“

In Azure, the term serverless has two distinct but related meanings:

• Backend as a service (BaaS). Back-end cloud services, such as databases and storage, provide APIs that enable client applications to connect directly to these services. But they do not need to manage the configuration or running of those systems.
• Functions as a service (FaaS). In this model, a “function” is a piece of code that is deployed to the cloud and runs inside a hosting environment that completely abstracts the servers that run the code.

Both definitions have in common the idea that developers and DevOps personnel don’t need to deploy, configure, manage, or scale servers on a regular basis. Some additional important characteristics are:

1. Compute resources are allocated dynamically as needed by the platform.
2. Consumption-based pricing: You are charged only for the compute resources used to execute your code.
3. The compute resources scale on demand based on traffic, without the developer needing to do any configuration.

The cost benefits of this serverless architecture is that we only pay for resources that we use. We do not reserve servers (in the form of IaaS virtual machines) or capacity (like in Cloud Service AppPlans) based on what we estimate we will need.

In server-based architectures, developers need to be very aware of the server infrastructure and need to plan and manage scaling of those servers. By requiring a minimum capacity, there are cycles wasted when all of the resources aren’t being used. As a matter of fact, may developers plan for higher capacity than they actually have to give room for growth, so they are spending more than is required for their Azure hosting costs. However, IaaS and PaaS are more familiar programming models for most developers.

For our game client, the Blazor and game logic actually runs on the client so it’s using the device’s computing power. And Azure Functions charges for the time and memory required to process each request. So we never run into a case where we are wasting compute resources that we do not use.

This makes for a cost-effective deployment and management environment.

Architecture

Here is a diagram of the proposed serverless web application and service architecture on Azure:

The architecture consists of the following components:

Blob Storage. Static web content, such as HTML, CSS, and JavaScript files, are stored in Azure Blob Storage and served to clients by using static website hosting. All dynamic interaction happens through JavaScript code making calls to the back-end APIs. There is no server-side code to render the web page. Static website hosting supports index documents and custom 404 error pages. Blazor WebAssembly produces a static website that can be deployed in this manner.

CDN. Use Azure Content Delivery Network (CDN) to cache content for lower latency and faster delivery of content, as well as providing an HTTPS endpoint. We won’t be enabling this in our game lessons, but you can use it for a fully production system.

Function Apps. Azure Functions is a serverless compute option. It uses an event-driven model, where a piece of code (a “function”) is invoked by a trigger. In this architecture, the function is invoked when a client makes an HTTP request.

API Management. API Management (is optional) provides an API gateway that sits in front of the HTTP function. You can use API Management to publish and manage APIs used by client applications. Using a gateway helps to decouple the front-end application from the back-end APIs. We may not make use of this capability in our game lessons, but may do a quick tour of the features.

Cosmos DB. Cosmos DB is a multi-model database service. For this scenario, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client. We will investigate Cosmos DB as well as a few other options for Azure storage options.

Azure Active Directory (Azure AD). Users sign into the web application by using their Azure AD credentials. Azure AD returns an access token for the API, which the web application uses to authenticate API requests (see Authentication). We aren’t going to delve into authentication in our game, because that could be a whole tutorial series of its own.

Azure Monitor. Monitor collects performance metrics about the Azure services deployed in the solution. By visualizing these in a dashboard, we can get visibility into the health of the solution. It also collected application logs.

Azure Pipelines. Pipelines is a continuous integration (CI) and continuous delivery (CD) service that builds, tests, and deploys the application. We have already used Azure Pipelines to provide automated builds of our Blazor game. We will also use them to deploy our static web application, and provide CI/CD of the Azure Functions services.

That’s the high-level architecture of our serverless application. We covered a lot of concepts here, and will dive into the details of each area throughout the lessons in the chapter.

Mapping Architecture to Our Game

In our game, we have already built the first piece of this architecture – the static web application. Blazor WebAssembly projects build into static web applications that can be deployed to various service providers by just copying the build output to the right place and providing a public endpoint. Up until now, we have just been running the game locally on our development machine, but our first step in this chapter will be to build an automated deployment pipeline to take our web game build output and publish it to Azure.

Once we complete that, we will have built the top half of the diagram – a single page application deployed into an Azure storage account that is configured as a static website. And from that point on, our game will be accessible to everyone on the internet.

Then we will look at building RESTful web services using Azure Functions. These services will expose our game data, so that they can be maintained on the service and decoupled from the game itself. We will look at strategies for creating the services, how/when our game loads this data from the cloud service, and what REST means.

Next we will look at storage solutions for our game data. In the diagram above Cosmos DB is called out as the Azure service to use for storage, and it is a great option for high-availability, global-scale services, but there are also other options, like Azure blob storage and Azure Tables… which we will investigate as well.

Finally, we will touch on using Azure Monitor to see how our service is running and automatically detect errors with it.

Additional Requirements

To start creating resources in Azure, you will need to have an Azure developer account – Free Azure subscription.

We may also use the Azure CLI installed (command line interface), so it’s best to install that too.

In conclusion, we’re going to be touching on a lot of new technologies and tools as we build our game services. Most of these are common tools used for build any type of web services, whether its for games or line of business applications or our next startup idea. We will be doing less direct C# coding than we did previous chapters, but hopefully learning these technologies in the context of the game we are already comfortable with will make the experience easier to understand.