
This past week I’ve been in Dallas,TX for the second edition of NSBCon 2015, the official NServiceBus conference.
[TL;DR]
It was a blast, I found the quality of the sessions and the activities very good and I met some nice and highly competent people. Oh, and great food!
As soon as the slides and videos are available online, I will add links.
Pre-Con Workshop
The week started out with a full day Advanced Saga Masterclass by Andreas Øhlund. Although most of the content was already familiar to me, I still had some nice takeaways from the day. The most important one is around integration patterns with external non-transactional resources. When dealing with non-transactional resources like web services in an NServiceBus architecture, it’s wise to place the interaction in a separate endpoint, and handling a command that you send from the Saga.
My takeaway was that you should leave the technical details of the web service interaction inside that integration endpoint. If an error occurs, just let NServiceBus handle it so you get First Level Retries and Second Level Retries for free. Only report back to the Saga with a functional reply, such as a Tracking# in case of a shipping provider. This way the Saga stays clean and functional, as does the integration handler.
Another important lesson is that a Saga are a good fit when there’s an aspect of Time in your domain logic. For example: a buyer’s remorse policy (the ability to cancel an order within x minutes). For logic like this, the RequestTimeout feature of a Saga really shines. You could state that if a Saga does not contain at least one timeout, you probably shouldn’t be using a Saga; instead you could just as well put it in a regular message handler.
The day ended in great company at Casa Rita’s Mexican Restaurant with a fantastic Briskett Burrito. (Hey, I’m a foodie)
Conference day 1
The first day of the regular conference was already packed with nice sessions. Udi’s keynote was sort of a State-of-the-Union on what Particular has been up to for the past year. Lots of work has been done on the internals of NServiceBus, more on that later. Most striking was probably the announcement that – a year after being introduced at NSBCon 2014 – ServiceMatrix is being discontinued.
To be honest, I am not really surprised and also not sorry for it. I’ve never believed in dragety-droppy modelling tools for building software and frankly I felt Particular was trying to go with that craze a little bit too much. As Udi explained, a tool like that will get you 80-90% there, but it’s the nitty gritty details in that last 10% that will break you up. So it’s back to the model of development that I’ve always liked so much about NServiceBus: put the developer in the driver’s seat.
That’s not to say that there is no demand for visual tools. Some of the efforts that have gone into ServiceMatrix are now being transformed into another form of visualisation, one that I much prefer: visualisation of your finished system as it runs. In other words: living documentation. I’ve always been a bigger fan of using simple tools for modelling: PowerPoint (yes I said it, I’m a PowerPoint architect), or much rather even: pencil & paper or a whiteboard. No modelling tool has ever really appealed to me, not the UML ones and especially not the “graphical coding” ones (looking at you Windows Workflow Foundation and BizTalk). Just stick with boxes and arrows and start coding, is my style.
NServiceBus V6
After Udi’s keynote, Particular solution architect extraordinaire Daniel Marbach took us through the new NServiceBus V6 release. V6 is all about embracing async/await, which means that an important chunk of NServiceBus Core was rewritten from the ground up to be async all the way.
Daniel did a great job of explaining why Particular did this. Ever since the introduction of the TPL and the async/await keywords, Microsoft has been pushing towards async code more and more. This is most apparent in the cloud, where all IO operations (Azure Storage Queues, Azure Service Bus, SQL Azure, etc) have an async API. Up till now, handlers in NServiceBus were synchronous, and made you implement a single method:
void Handle (MessageType message);
This makes it hard to consume async API’s for IO, because marking a void method as async is evil. Furthermore, the NServiceBus Core is not aware of any async code, so strange things can happen if you’re not careful. This lead the team to the decision that V6 should be a breaking change in order to go fully async. The interface for a handler now looks like this:
Task Handle(MessageType message, IMessageHandlerContext context);
You must now return a task (or Task.FromResult(0) if your implementation does not require async), and you receive an IMessageHandlerContext implementation that you can use to send or publish messages. No more public IBus Bus { get; set; }. This is done so that there is no more dependency on state across multiple threads. NServiceBus will make sure that you have the correct instance. It is also important to note that the use of ThreadLocal for caching is dangerous because of the introduction of async/await. All in all, an excellent talk by Daniel, who wrapped his lessons in a story about a Swiss Chocolate Factory. Gotta love the Swiss.
More interesting info on async/await and ThreadLocal can be found here:
[https://www.youtube.com/watch?v=4uWzIM1U-VA] Presentation about the pitfalls of async/await and the SynchronizationContext. Highly recommended, even if only because of the creative format.
[http://www.particular.net/blog/the-dangers-of-threadlocal] The dangers of ThreadLocal
Akka.NET
Andrew Skotzko from Petabridge did a riveting, high octane presentation about Akka.NET and the Actor Model. I’ve briefly looked at the actor model before and am interested in exploring it more, especially after this session. One of the things I’ve been wondering about for a longer time is how the actor model fits in with NServiceBus.
In his session, Andrew mentioned that Akka could be a great producer or consumer for NServiceBus. In Andrew’s words: “Akka is about Concurrency, NServiceBus is about Reliability”. I’d have to explore this some more but frankly I don’t really see a great fit as of yet. One of my main concerns with Akka is that remote messaging between actors is not reliable. It is supposed to be light weight and location transparent, but the model compromises on reliability. Akka has an “at most once” delivery guarantee, which doesn’t exactly guarantee anything. For communication between actors, Akka provides location transparency, i.e. you just use an interface to send a message, and the receiving actor can be either in memory or on a remote machine. Hmm, where have we seen this fail before? At least NServiceBus is always clear on the fact that when you send a message, it’s inherently remote. And NServiceBus has your back in making sure the message arrives.
So, I’m not yet really seeing the point of using an actor model inside, or alongside NServiceBus services, but it requires more investigation.
This seems to be the best place to start: http://LearnAkka.net
I must say though, both Andrew and Aaron Stannard from Petabridge are both extremely passionate and helpful. They’re very nice guys and we had good fun over a couple of beers.
Death to the Distributor
Sean Feldman from Particular talked us through a preliminary version of a new routing component in the NServiceBus plumbing which allows them to eliminate the Distributor component when you’re on MSMQ transport and want to scale out. A nice and short talk in which Sean showed a promising solution for decentral routing, with a pluggable strategy (you could write your own distribution logic if you’d like). With that basis, combined with realtime health info from endpoints, dynamic routing and commissioning and decommissioning of nodes will become possible. Interesting stuff that’s in the works.
There were also two interesting case studies on the first day: Building the Real-Time Web with NServiceBus and SignalR by Sam Martindale and a more high level session called Decomposing the domain with NServiceBus by Gary Stonerock II
Combining SignalR with NServiceBus has been a hobby of mine for a longer time, so the idea was already familiar to me. It was nice to see the application that Sam and his team put together: a multi-user graphical web application for “composing” and budgeting luxury homes that relies on SignalR and NServiceBus for on-the-fly budget calculation and distribution to multiple users at once. Sam was so nice to do a shout out of my earlier blogpost about the NServiceBus backplane for SignalR. With thanks to Ramon Smits of Particular, the sample has now been upgraded to the latest stable versions of both NServiceBus and SignalR. Thanks Ramon!
Gary’s session was interesting as well, sharing his journey designing a system for Medical Trials on a logical architectural level. Some key takeaways for me were:
- In modelling your domain logic, make sure that you model it for success (i.e. Logical Success Modelling). Try to factor out the edge-cases and exceptions by asking more questions about the business logic. You will end up with much simpler domains.
- Defer naming things; Don’t name services, domains or classes until you are more clear about its responsibilities. You will end up with much clearer names. Udi calls this “Things Oriented Architecture” in his ADSD course.
Hackathon!
Then it was time for the Hackathon! The assignment: come up with the most over-engineered Hello World application based on the NServiceBus building blocks. I teamed up with Anette, Daniel and Adam and after a couple of beers we came up with project Ivory Xylophone:

See? Pencil & paper FTW!
By sending a tweet with hashtag #ivoryxylophone, we set off a system that sends a message to a Saga that converts all the characters in the message to Morse code, gathers the characters, converts them back to plain text and sends the message to a handler that tweets out the message on Twitter. All NServiceBus message would go over a transport based on Git commits (…). Apart from the Git transport, we got it working end-to-end.

Mob programming
We got second place, just after the awesome Slack transport by Mark Gould.

Demo time for Ivory Xylophone
Conference day 2
Ted Neward kicked off day 2 with his keynote session “Platform Oriented Architecture“. He opened by establishing that the software industry has been through several cycles of inventing the same wrong solutions for the same problems multiple times. We’ve seen other people speak about that and frankly, he’s right. The nice thing about Ted’s talks was that he did a shot at how the future of architecture should look. He concludes that most of us are building a platform of some sorts. And in order to succeed, you need all of the good things that we’ve established: the 4 tenets of SOA are still a good idea, we still need to mind the 8 fallacies of distributed computing, but the most important thing is that a platform should have a clearly defined Domain and Context. Meetup, Uber, Yelp, AirBnb are all platform but each has its specific domain and give meaning to technology choices in their own context.
All About Transports
Swedish Chef Andreas Öhlund gave a great talk comparing the different transport options that NServiceBus gives, packed in a tasty tale of a Swedish Meatball company. I really liked his stylish slides, kudos! His message was important: different transports have very different characteristics and you should choose wisely. Do you choose a decentralised model with MSMQ or a broker style transport like SQL Server, Azure Service Bus or RabbitMQ? Talking about RabbitMQ – one does not simply install RabbitMQ and be done with it. It takes care to make RabbitMQ reliable (clustering) and you must be careful when you send messages inside a transaction that might fail, or you’ll end up with ghost messages. Andreas’ talk could be a great blogpost in itself. I hope Particular puts it on their blog soon.
Other interesting talks were Jimmy Bogard‘s Integration Patterns With NServiceBus where he shared some lessons learned about integrating legacy systems with newer NServiceBus systems, dealing with big files and his interesting Routing Slip Pattern.
Kijana Woodard had a funny and insightful talk about Things Not To Do With NServiceBus. I like seeing a talk like this as it shows that Particular isn’t just shoving NServiceBus down everyone’s throat as the end-all solution for everything. It’s not a golden hammer, so there are definitely cases where it doesn’t fit.

Beef ribs!
Again, a great day, which ended in the fantastic Brazilian Steakhouse Boi Na Braza. Did I mention I’m a foodie?
Day 3: Unconference
One of the things I enjoyed the most was the Unconference day. A day where participants set the agenda and get to do the talking. We collaborated on an agenda for the day and ended up doing multiple parallel tracks of discussions and knowledge sharing. I participated in discussions about Security & NServiceBus, UI Composition. Akka.NET & the Actor Model, Saga & Domain Concepts and Microservices. Got a ton of new insights. My sketchy notes might not be as meaningful to you as they are to me, but still…
All in all, NSBCon was well worth the trip to Dallas. All the Particular folks are very approachable, hospitable and helpful, the participants were great discussion partners and the quality of the sessions was very good.