Azure

Building Messaging Endpoints in Azure - Evaluating the Landscape

Jimmy Bogard

Jun 21, 2019 • 2 min read

Posts in this series:

When looking at moving traditional on-prem solutions to the cloud, I try as much as possible to avoid any kind of lift-and-shift strategy and instead leverage as many platform-as-a-service (PaaS) offerings as possible. Since our systems mainly consist of web applications backed by some sort of database, it's often a fairly straightforward transition. Web applications become hosted as Azure App Services, and our databases become Azure SQL.

One component that isn't nearly as easy to understand how to move are messaging endpoints. A messaging endpoint is some sort of autonomous background process that sends and receives messages. There's no user interface for these types of applications, only processing messages completely in the background.

Typically, our on-prem solution for messaging endpoints is a Windows Service - usually built with something like TopShelf and NServiceBus. It's been our solution for quite a few years now, since Windows has a built-in concept of a background process that can be started, stopped, and well-established APIs for installing and controlling them.

The story, unfortunately, is quite a bit muddier when looking at moving these services to Azure. There's no direct analog to Windows Services in Azure like there is with moving an IIS application, so we have to carefully evaluate our choices to see what makes the most sense.

First, we need to understand what our possible options are before looking at what can be a reasonable option. Messaging endpoints can be run in anything can run a .NET (Core) process, so while it can be run in almost any Azure service, some are more geared towards background autonomous processes than others.

Our Many Possible Services

Even getting a list of Azure services can be a challenge, the best we can do is pull from the availability list and select "All Products". The list is looooooong but we can start to narrow down our overall possible options:

And inside of Azure App Service, we have more sub-options:

Web Apps
Web App for Containers
Web Jobs (not really a first-class service)

A few of these we can try to eliminate out-of-the-box, as either highly proprietary or more or less deprecated solutions:

Cloud Service
Service Fabric

Or ones that would be difficult/impossible to migrate existing code into:

Logic Apps

Or ones that are a lift-and-shift strategy:

Virtual Machines

That leaves us with:

App Service (and its many options)
Container Instances
Azure Functions
AKS

Unfortunately, none of these options are truly analogous to a Windows Service, but we do have a spectrum from Serverless to Infrastructure as a Service. If we look at a web application, we have many options along the spectrum:

It becomes more difficult to evaluate messaging endpoint options, there's nothing in our list that is in that "PaaS" solution spot. There's really no right-click-deploy solution for a messaging endpoint, which as demoware as it is, highlights how Microsoft wants to make it super easy to deploy a web application to the cloud. There's just nothing like an App Service for Windows Services. It all assumes you're deploying a web application.

In this series, we'll look at the different tooling and deployment options for delivering messaging endpoints to Azure, benefits and drawbacks and each, and see while there are strides being made, the story still won't be quite as nice as re-platforming a web application.

Our Many Possible Services

Sign up for more like this.