One of the foundational features of NServiceBus is the support of multiple queuing technologies known in NServiceBus parlance as a Transport. NServiceBus transports encapsulate the logic required to connect to their respective queue technologies to produce and consume messages.

Testing is one of the more challenging aspects of message based systems and is probably one of the top reasons it is common to see http endpoints instead of messaging in microservices.

There are a number of subtle but important aspects of message based systems that are not apparent until after you have started building one and running it in production. One of those aspects is message headers. NServiceBus message headers contain metadata about each message that will help you correlate, route and trace the history of a message in your system.

Message retries are one of the most powerful patterns in message based systems. Retries are probably one of the more compelling reasons to use a message based architecture and make a system that uses them significantly more durable and accurate.

One of the most painful parts of starting with a new team is to learn all of the nuanced patterns and practices you must adhere to. Often these nuances are not documented and to make matters worse, the common response given for why is, "that is just how we do it here". The tribal knowledge runs so deep it starts to look like cargo cult culture and in some cases it is just that.

I've been experimenting with Pivotal Cloud Foundry recently and put this quick tutorial together for deploying an ASP.NET Core application using PCF. I was amazed at how easy this was and I'm sure you will be too. This is a quick getting started with Pivotal Cloud Foundry and ASP.NET Core.

Managing secrets on your development machine can be a challenge. This is evident in the high number of secrets that are regularly found publicly available in GitHub. I recently found that Spring Cloud Config Server running in Docker on my workstation has made managing those secrets without including them in my source control alongside the code a little easier.

The role of Software Architect is typically not well defined in most organizations and I've found Gregor Hohpe's description of The Architect Elevator to be the most enlightening.

Change is hard as a individual. Implementing lasting change in a team or organization is probably one of the most difficult things one can attempt. I say lasting change, because it is easy to impose short term change, but hard to make that change stick.

Meditating on a software development task and picking a random number is a guess. There are other methods that provide equally effective methods of planning that do not include guesses.