Messaging
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.
October 12th, 2018
Message design anti-patterns for event-driven architecture
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
Kafka on Azure Event Hub – does it miss too many of the good bits?
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
Handling Protocol Buffers backwards compatibility between versions 2 and 3 using C#
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
Data design for event-driven architecture: autonomy, encapsulation and ordering
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
Comparing nServiceBus and MassTransit: Do we still need .Net integration frameworks?
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
Why REST is not a silver bullet for service integration
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
Don’t assume message ordering in Azure Service Bus
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
Messaging shouldn’t be used for queries
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 a tolerant reader for web service integrations in .Net
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
The problem with tiered or layered architecture
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
Eventual consistency and the trade-offs required by distributed development
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
Writing a brokered messaging client for Azure Service Bus that is production-ready
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.