Modern Serverless applications on Azure

Bigger picture, Frameworks, .NET changes and platform maturity

Stas(Stanislav) Lebedenko
5 min readSep 11, 2024
Bigger picture
Bigger picture

TL;DR; The serverless ecosystem on Azure matured well over the years, and with .NET 8 and new SDKs like .NET Aspire, Dapr, and Microsoft Radius, it has become the default choice for building greenfield projects. In this article, I will connect bits and pieces, providing a coherent view of components for building modern apps on Azure.

Plan

It seems like Microsoft’s plan is to provide a one-stop experience with Visual Studio the way it worked with Microsoft Service Fabric(if you know, you know:) ). But a few misconceptions exist in the developer community, so let’s straighten things out a bit.

  • Developer tools and frameworks
  • DevOps tools and frameworks
  • Summary
Responsibilities
Responsibilities

Developer

Let’s start with the code. .NET has come a long way from big bundles and moderate performance and provides many much-needed optimizations.

The introduction of an ahead-of-time compilation to minimize the application bundle has already impacted minimal APIs and will further boost Azure Functions’ cold start performance. There is an older version of this, called ready-to-run, available for your Azure functions, but since we are moving to the out-of-process model , everything will be unified.

Native ahead-of-time compilation
Native ahead-of-time compilation

Native resilience

We all know the Polly framework and have used it for many years with .NET applications, but this is another package that impacts bundle size and start performance. Now, we have native resilience components available for .NET apps.

native resilience
native resilience

Better alternative to docker compose

I can recall a time when Visual Studio tooling provided everything you needed, and we got that awesome experience back with the .NET Aspire framework.

Startup of a project with .NET Aspire
Startup of a project with .NET Aspire

Integration testing

Yes, there is a Testcontainers framework, and it is working very well. As we discussed before, Microsoft is doing a great job of minimizing external dependencies, and now it is possible to use .NET Aspire for integration testing as well.

Integration testing with .NET Aspire
Integration testing with .NET Aspire

Chiseled containers

The main component of the Azure Container Apps performance stack and the upcoming Azure Functions complete switch to an out-of-process model is lightweight containers. So your apps will start faster, and you get to decide how many dependencies you need, down to the 8 dependencies for AoT-optimized applications.

Chiseled containers
Chiseled containers

Azure Container apps (ACA)

Great abstraction over Azure Kubernetes Service with the ability to go with lightweight HTTP services or build advanced scenarios using Distributed Application runtime DAPR limited version. Some people want limited access to Kubernetes APIs here, but there is AKS to help with that.

As you can see in the grid below, you get access to the native resilience components of DAPR, scheduled jobs, and advanced networks if needed

Azure Container Apps key elements
Azure Container Apps key elements

Azure Container Apps provide a perfect way to start with your application and then easily migrate to Azure Kubernetes Service if needed.

DAPR manifest difference
DAPR manifest difference

DevOps

This part is related to understanding the difference between .NET Aspire and Microsoft Radius and how they fit together. It all boils down to the level of abstraction. Aspire solves the problem of applications working locally and on Kubernetes, while Radius prepares recipes to deploy your application everywhere — preferably to Azure, of course :), but also to any Kubernetes cluster.

Short comparison between Radius and Aspire
Short comparison between Radius and Aspire

Let’s look at Radius; I will skip terminology and documentation rehearsal and provide a documentation link in the link section.

Radius is still in a preview but already offers a command line and some UI functionality to understand application topology, configuration, and network port 3000 for app configuration and 7007 for portal if you will connect to your Kubernetes cluster with port forwarding.

Application configuration
Application configuration

And Radius portal.

Radius control panel
Radius control panel

As you can see, the infrastructure description is currently done via Bicep language, but Terraform is coming, so there might be more alternatives in the future.

Bicep code for application service with two Radius and Mongo
Bicep code for application service with two Radius and Mongo. Nevermind red import, it is working good ;)

Summary

So, let’s have a look at the bigger picture again.

Bigger picture
Bigger picture

So, Microsoft aims to provide you with the full lifecycle ecosystem to develop microservices, start with lightweight serverless microservices, and then grow easily with the help of DAPR, AKS, and Radius recipes to host your application anywhere.

Thanks for reading. Ping me on LinkedIn if you have any questions, and say hi at the conference; don’t be a stranger.

Links

--

--

Stas(Stanislav) Lebedenko
Stas(Stanislav) Lebedenko

Written by Stas(Stanislav) Lebedenko

Azure MVP | MCT | Software/Cloud Architect | Dev | https://github.com/staslebedenko | Odesa MS .NET/Azure group | Serverless fan 🙃| IT2School/AtomSpace

No responses yet