Brighter and Azure Service Bus — Contributing to Open Source
Part of the Spektrix migration to Azure involved a significant piece of work to replace our existing on-premise RabbitMQ servers with the more cloud native Platform as a Service (PaaS) Azure Service Bus offering. Fundamentally the same principles of message queuing applied (albeit with slightly different terminology) so we were confident we could switch out the service in the components that needed them. In our attempts to begin the process of decoupling our Monolith, we use a CQRS pattern and to support this we use an open source component called Brighter.
Brighter describes itself as:
“…a Command Processor & Dispatcher implementation with support for task queues that can be used as a lightweight library.
It can be used for implementing Ports and Adapters and CQRS (PDF) architectural styles in .NET.
It can also be used in microservices architectures for decoupled communication between the services”
In some of our components, we hand off to Brighter to send and receive messages to a message bus and we already had this configured to use RabbitMQ. When we began our analysis of migrating this to Service Bus we realised we had a little bit of a problem. At the time Brighter only had partially implemented support for Azure Service Bus and this wouldn’t be sufficient for our use cases.
So we got to work writing the implementation and after a few iterations we did it. Of course there were a few challenges along the way — for example, making sure we correctly handled asynchronous methods and events, disposed of connections when we should and that we implemented the package in the way Brighter expected components to behave. We were careful to add the right amount of logging so that we could see how the component was working and adjusting where required. We made sure to handle exceptions, retry transient connection failures with Polly policies and where necessary throw the types of exceptions that the core Brighter component expected so it would function in the way it was expected to.
We work in an agile iterative manner at Spektrix and once our confidence was high enough we swapped out our RabbitMQ implementation with our Service Bus implementation and our new component performed really well, perhaps just needing the occasional tweak. The last time any significant work was done to this component was around September 2020 and all components needing this integration were modified and successfully deployed to Production.
Fast forward to March 2020 and some members of the original implementation team were tagged on a Twitter thread:
Our previous Principal Engineer, Domenico Musto, had submitted an early pull request but this was before the team had fully completed getting the component into production. Dom tagged us in the thread and asked if we could submit what we had done back to the core Brighter project. We spoke about it at our early morning stand-up and decided it would be best if we ran this past senior management as it would be the first time Spektrix had done something like this. There was enthusiastic support from our Principal Engineer Andrew Jones-Weiss and CEO Michael Nabarro as the opportunity to share our knowledge aligned with the company’s wider principles of collaboration.
The team put the pull request together by making a few changes to the project to align it with the core Brighter solution (for example namespace changes and a largely painless update from nUnit to xUnit). The PR was submitted later that day much to the delight of the Brighter core maintainers and other contributors interested in taking this implementation forward. Additional features that we hadn’t added as part of our implementation were required along with some other changes necessary to make the component fully generic.
From the team’s perspective it felt so great to be in a position where we could actively contribute back to the open source community and fulfil an immediate need of members of that community. It’s such a great example of giving back and being recognised for the contribution. I’ve personally worked in companies where this just wouldn’t be possible or the amount of approvals required would just be overwhelming. It’s a true testament to the agility and trust developers are given at Spektrix.
And as for the future of our bespoke Service Bus component implementation, I can imagine we’ll look to swap out our implementation with the one soon to be provided natively with Brighter and once again reap the benefits of open source software.
