Beyond ServiceMatrix

When we originally started developing ServiceMatrix, our vision was to develop a tool that could help design distributed systems. One of our main goals was to enable architects to graphically design an immediately executable solution so they could quickly iterate on their designs. We also wanted to help developers who were new to NServiceBus to get started more quickly and avoid many common pitfalls with messaging.

Unfortunately, even after years of effort, we just could not find the right balance between the “it just works” code generation experience and leaving developers enough control over how their solution was built. Although we were aware of many other companies who had struggled with this very issue, we also fell into that well-worn trap of thinking “this time will be different”.

We haven’t given up though, and have started down a different path instead - one that doesn’t rely on code generation and is more integrated with the rest of the platform.

🔗First - NServiceBus

One of the benefits of ServiceMatrix was that it made it very easy to define how messages should flow between your endpoints. ServiceMatrix also made it much easier to build sagas - generating the code responsible for mapping messages to saga state. What we came to realize was that the regular NServiceBus routing configuration and saga APIs were too complex.

The good news is that with the upcoming version 6 of NServiceBus, you’ll already see some improvements in these areas - and going forwards, we’ll be rolling out even more simplifications.

🔗Then - Visualization

One of the most requested features of ServiceMatrix we couldn’t ever quite figure out was how to “import” an existing code base so that developers could get a visualization of how their system worked. There were just too many differences in how developers structured their solutions and how our code generation needed to work.

We think we’ve found a better way to visualize your existing solutions. Instead of trying to reverse-engineer your code and project structure, we’re basing it on the stream of audited messages - something that is much more stable.

In short, you’ll be able to get a graphical representation of the types of messages in your system and how they flow between the various endpoints, a kind of living documentation for how everything works - regardless of how you structure your code.

We’ve been evaluating this approach with a number of customers and are now releasing it as a Community Technology Preview at Particular Labs so that you can try it out.

🔗Finally

We really do appreciate all the support you’ve given us over the years and remain as committed as ever to providing you with the best tools and infrastructure for your systems. Although at times we will make mistakes, we will be open and honest with you about them and do our very best not only to correct them but to make things right by you as well.

With thanks,
Udi Dahan and the rest of the team in Particular