![]() ![]() It’s not like using logging libraries that are effectively interchangeable and can be configured to push out pretty much any output. When I say that messaging is a common concern, it isn’t really a generic one. Do you really want to be tied into an opinionated set of patterns and abstractions that you don’t control? Your choice of messaging library can be a strategic decision that you’ll be bound by for some time. the kit that regulates service collaboration. You are talking about one of the most important parts of your infrastructure, i.e. However, messaging is something that needs particular care. At some point you need to hold your nose and get some work done. Getting locked inĮvery technology decision involves some element of lock-in. In this case, a common technical implementation won’t be available, and you will need to focus instead on asserting a common messaging format. You could find yourself trying to connect a legacy ASP.Net website with Java Spring applications or containerised microservices written in Node.js. Larger ecosystems tend to be messy affairs, often growing through a combination of acquisition and haphazard decision-making. nServiceBus has its own set of headers, while MassTransit seems to push a lot of this stuff into the message body. Rebus writes more than a dozen special headers to handle semantics such as correlation identifiers, timestamps, routing slips and content encoding. This is hard as there is no consistency in this area. If you want to get mixed ecosystems to participate in messaging patterns, you’ll need to roll an implementation of your chosen library’s message format. ![]() None of them provide any kind of cross-platform support. For example, Java has Spring Cloud Stream while Python has Celery. Other eco-systems have similar libraries that abstract away the underlying messaging transport. They do not address the problem of event-based messaging across diverse technical stacks. Net options are predicated on running a recent Microsoft development stack. Messaging endpoint libraries tend to assume a homogenous ecosystem. Well, occasionally, yes… Technology stack You shouldn’t be writing a messaging library simply for NIH reasons, but can it ever make sense to roll your own? If you want to get into more sophisticated patterns such as sagas, you’ll find yourself handicapped by an implementation that won’t play along without a huge investment of work. It’s hard enough getting your service boundaries and event design right without adding the extra overhead of plumbing.Ĭustom messaging implementations can also be very limiting. Who would be responsible for maintaining it? What tends to happen is that the original authors of these libraries move on, leaving a legacy of impenetrable code behind them. You may grow old and die long before your new library is fully hardened.Īsserting a shared library between all your services can be quite a burden. They will often be nuanced, involving unpredictable asynchronous behaviour, and may only be visible at scale in your production environment. ![]() The kinds of bugs you’ll get will be extremely difficult to spot. Getting something genuinely battle-tested up and running is quite an undertaking. That’s just the basics you need to get pub-sub messaging going. There are a bunch of concerns to figure out, including routing, serialization, logging, transactions, retries, exceptions and scheduling. The problem is that implementing basic messaging patterns is much harder than it looks. There is a very strong argument that you… just… shouldn’t… do… this… The health warning After all, it’ll give you direct control over your integrations and allow you to implement something that directly fits the unique demands of your environment. Given that these libraries tend to enforce an opinionated set of conventions onto the way you design and implement messaging, it can be tempting to build your own. they take care of all the nuance of message sending and handling so developers can focus their efforts elsewhere. These libraries all serve pretty much the same purpose, i.e. Net ecosystem this has given rise to a selection of libraries that abstract away the underlying transport, such as nServiceBus, MassTransit and Rebus. This will assert consistency and prevent developers from wasting time on generic concerns around message handling and formatting. ![]() Enterprise messaging patterns are complex beasts that often warrant a common implementation across your endpoints. ![]()
0 Comments
Leave a Reply. |