Building Messaging Endpoints in Azure: Container Instances

Posts in this series: Evaluating the Landscape A Generic Host Azure WebJobs Azure Container Instances In the last post, we looked at Azure WebJobs as a means of deploying messaging endpoints. And while that may work for smaller loads and simpler systems, as the number of message endpoints grows, dealing with a "sidecar" in a WebJob starts to become untenable. Once we graduate from WebJobs, what's next? What can balance [Read More]

Building Messaging Endpoints in Azure: WebJobs

Posts in this series: Evaluating the Landscape A Generic Host Azure WebJobs Azure Container Instances In the last post, I looked at creating a generic host endpoint that many of the deployed versions in Azure can share. By using a hosted service, we can then host NServiceBus in just about anything that can work with the .NET Core generic host. The differences then come to hosting and scaling models. First [Read More]

Immutability in Message Types

In just about every custom I've worked with, eventually the topic of immutability in messages comes up. Messages are immutable in concept, that is, we shouldn't change them (except in the case of document messages). Since messages are generally immutable in concept, why not make them immutable in our applications dealing with the messages themselves? Immutabilty has a number of benefits, ask Mark Seemann laid out in a discussion question [Read More]

Building Messaging Endpoints in Azure: A Generic Host

Posts in this series: Evaluating the Landscape A Generic Host Azure WebJobs Azure Container Instances In the last post, we looked at the many ways we can consume messages in Azure as a message endpoint. Unfortunately, there's not an easy answer. We don't have a simple, PaaS solution to a background service. We basically have some very bare serverless options, some shimmed options, and IaaS options through containers. Regardless of [Read More]

Message Naming Conventions

One of the first design decisions teams starting with messaging are presented with are - what the heck do we name these things? When building out request/response types for typical API/web applications, I name the responses usually after the resource they represent, or the route, or controller/action. There's something already "around" my message that tells me what to name it. Durable messages are a bit different - [Read More]