Asynchronous messaging is still my preferred means of facilitating looslely coupled collaboration, but it’s rife with hidden complexity. Particularly at scale, where the smaller edge cases can quickly turn into overwhelming data leaks.
February 8th, 2020
Message design in an event-driven architecture can be quite nuanced, especially if you want to achieve any of the benefits of loose coupling that they can be associated with.
December 14th, 2019
Enterprise messaging patterns are complex beasts that often warrant a common implementation across your endpoints. Should you ever be tempted to roll your own?
April 21st, 2019
Microsoft have published advice for maximising performance with Azure Service Bus, but there doesn’t appear to be any explicit advice for optimising the newer .Net Standard based SDK.
October 12th, 2018
Event-driven integration can improve the scalability, resilience and scalability of distributed applications… but this does depend on the design of your event messages…
July 10th, 2018
Microsoft have added a Kafka façade to Azure Event Hubs, presumably in the hope of luring Kafka users onto its platform. This makes sense as the platforms have a lot in common, though there are some missing Kafka features that may prove critical.
November 13th, 2016
You will inevitably be pushed towards upgrading your protocol buffer messages to Proto3, particularly if you want a client that supports .Net Standard that .Net Core. This can be done, but there are a couple of speed bumps along the way.
February 1st, 2016
When you’re implementing an event-driven architecture, the design of your events is absolutely critical to realize the benefits of loose coupling.
November 26th, 2015
Both nServiceBus and Mass Transit plugged an important gap in Microsoft’s integration landscape, but do they have a role in a future that is likely to be dominated by diverse technologies and autonomous agile teams?
January 4th, 2015
REST is sometimes described as the next “evolutionary step” in service integration. The problem is that REST provides too much of a “dumb pipe” to support genuinely decoupled, fault-tolerant service integration.
December 16th, 2014
Azure Service Bus can provide first-in-first-out messaging in theory, but this is not the same as guaranteeing the order in which your messages are processed.
August 21st, 2014
When developers first start using messaging they can be tempted to use it as a brand new hammer for every nail. Messaging brings a lot to the party, but it isn’t necessarily a suitable transport for fast, synchronous query processing.
July 22nd, 2014
Using version tolerant readers can help you to cope with changes to service contracts though this does come at the expense of a weaker contract. The approach is more appropriate for fluid services that are prone to frequent change.
July 9th, 2014
An architecture based on tiers or layers is too inflexible to deal with the more flexible demands of modern systems, particularly when you working with high-volume systems that require distributed processing.
May 4th, 2014
Developers who have been brought up on the certainties of ACID transactions often have a problem trusting eventual consistency. Once you start exploring the requirements in more depth this really so much of a handicap.
April 22nd, 2013
Azure’s Brokered Message API provides a basic set of methods that make it easy to start sending and receiving messages through the Azure Service Bus. The problem is that it doesn’t do much to provide some of the basic scaffolding required by a serviceable messaging client.