Stepping into a forest of legacy enterprise systems as the newly minted enterprise architect can be daunting. Imagine being handed a map to a labyrinth, where every turn reveals a new layer of decisions made by well-intentioned predecessors. Our current environment is a vibrant tapestry woven from MassTransit, NServiceBus, MSMQ, and Azure Service Bus threads. Some of these systems have served their purpose, but now it's time to weave a new narrative.
We're not here to point fingers or assign blame. These systems were likely the right choices at the time and have been instrumental in our journey thus far. But just as a snake sheds its skin, we need to shed our old systems to allow for new growth.
Enter NATS.io, our potential path out of the forest. NATS.io is like the Marie Kondo of systems. It promotes simplicity, allowing us to build a solid foundation and then, if needed, layer complexity on top. It's perfect for quick, lightweight connections but can also shoulder the weight of full-scale, reliable solutions. And the best part? It doesn't demand exclusivity. We can keep using other solutions that still make sense.
Here's our evolving game plan as we embark on this journey:
- We bid adieu to MSMQ. It's been a reliable ally, but its time has come.
- The NATS client can run anywhere our legacy clients can, providing a smooth path forward for everyone. This will ensure our older apps can transition smoothly when they're ready, irrespective of the side of the message they're on.
- Azure Service Bus isn't packing its bags. It remains a viable option for teams that are comfortable with it.
- For our critical systems, we'll continue to rely on NServiceBus and pay the luxury tax.
- NATS will serve as the backbone and bridge that can accommodate on/off ramps and cross-bus communication, if necessary.
It's worth mentioning that navigating politics and risk aversion can be as challenging as any technical issues. As we begin to establish a stronger reputation for our system and showcase the benefits of our evolved event-based architecture, we'll be in a position to leverage NATS for bigger and better things. That's why we're starting with NATS as our bridge before making any sweeping decisions about migrating away from one technology or the other.
This is just the beginning of our journey. As architects, we don't claim to have all the answers upfront, but we're committed to making informed, intelligent choices for our architecture. As I navigate this maze of legacy systems, I'll attempt to shed light on the "why" behind our architectural decisions, documenting our steps, successes, and stumbles along the way. So, stay tuned for the next installment in our ongoing saga! If you have thoughts or questions, don't hesitate to connect @RickDotNet.