Particular Software Blog

It's a pretty cool time to be a .NET developer. Don't believe it? Check out this excerpt from a popular children's book¹:

Congratulations! Today is your day.
You're off to Great Places! You're off and away!

Maybe you like Linux or have a MacBook,
Or want to host code without breaking your checkbook.
The license for Windows can be a bit pricey.
Getting approval for more servers can be a bit dicey.

But now you have choices, it's a bit of a shocker.
You can even choose to deploy your apps using Docker!
With your skills in .NET no opportunity shall go by,
When you can even deploy on a Raspberry Pi.

And now NServiceBus is ready, we've got your back.
The ultimate cross-platform messaging stack!
You're off to Great Places! Today is your day!
There's more than Windows now, so…get on your way!

-Adapted from Oh, the Places You'll Go! by Dr. Seuss

In other words, NServiceBus 7 for .NET Core is here.

I'd like to share some highlights from a recent chat I had with Bryan Hogan on his No Dogma Podcast.

We kicked off with NServiceBus and how it helps building distributed systems and microservices. We talked about the general challenges such as coupling, communication, and fault tolerance. We also investigated some of the patterns that help, such as events, retries, and long running processes. We wrapped up with the importance of system monitoring, and what's next for NServiceBus.

While you probably wouldn't expect this from a software infrastructure company, we opened a theme park! Welcome to Particular World.

By building expression trees at startup and then dynamically compiling them, we were able to achieve 10X faster pipeline execution and a 94% reduction in Gen 0 garbage creation. In this post, I'll explain the secret to getting these kinds of performance boosts from expression tree compilation.

Have you ever had to deal with a function that had hundreds and hundreds of lines? Code that had duplication all over the place? Chances are you were dealing with legacy code that was written years ago. If you're a Star Wars fan like I am, it's like dealing with the Force. As Yoda would say, “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.” In my 15+ years of coding, every single time I've dealt with legacy code, fear, anger, hate, and suffering were pretty common.

If you've been looking forward to using .NET Core with NServiceBus on Azure, I'm afraid we've got some bad news. Instead of making their existing Azure Service Bus client library support .NET Core, Microsoft has released a brand-new incompatible client. This makes it impossible for us to upgrade the NServiceBus Azure Service Bus transport you know and love to support .NET Core as is, and forces us to write a brand-new transport as well. Here's the full story.

Today we're happy to announce that you can start building production-grade NServiceBus systems on .NET Core. Although the bits are currently marked as beta, a release candidate with a go-live license is coming soon.

Decision making is tricky business. Decisions often move up and down the chain of command without the input of those best equipped to make those decisions. In smaller companies, there's often too much reliance on the CEO, and that doesn't scale as the company grows. Ultimately, we can easily end up in a situation where the input of those most knowledgeable is not considered.

While we've been working hard on supporting .NET Core lately, you may have noticed that we also released a brand new (and dare we say better?) persistence library for NServiceBus called SQL Persistence. The new persister supports multiple database engines and uses raw ADO.NET and native SQL queries, without the need for an intermediate ORM. We dreamed up some powerful new features that would take NServiceBus persistence to the next level. Up until now, our primary method of persisting data in relational databases used NHibernate, which was making it impossible to realize those dreams. We decided it was time for NServiceBus to make an evolutionary leap forward in its persistence capability.

I read the script and performed my lines well. College, good jobs with increasing responsibility in corporate America, marriage and kids. When suburbia beckoned, it wasn't too hard to swap my briefcase for the diaper bag. At least for some period of time, home was a lot more interesting than my work experience had been. Children have a charming way, though, of exposing the insecurities we don't even know we have. My revelation came during the first opportunity to meet our five-year-old's teachers.

I remember the first time I deployed a system into production. We built a custom content management website backed by a single SQL Server database. It was a typical two-tier application with a web application and a database. Once the system was deployed, I wanted to see if everything was working properly, so I ran through a simple checklist

In a previous blog post, I discussed a very complex and intricate process: how my family unloads our dishwasher using a chain of responsibility. We examined a happy-path scenario in which each person hands a dish to the next. Every step takes the same amount of time, and the process hums along like clockwork. You can almost hear us singing “Whistle While You Work” while we gleefully put away dishes.

Anybody can write code that will work for a few weeks or months, but what happens when that code is no longer your daily focus and the cobwebs of time start to sneak in? What if it's someone else's code? How do you add new features when you need to relearn the entire codebase each time? How can you be sure that making a small change in one corner won't break something elsewhere? Complexity and coupling in your code can suck you into a slow death spiral toward the eventual Major Rewrite. You can attempt to avoid this bitter fate by using architectural patterns like event-driven architecture. When you build a system of discrete services that communicate via events, you limit the complexity of each service by reducing coupling. Each service can be maintained without having to touch all the other services for every change in business requirements.

During Build 2017, Microsoft released .NET Core 2.0 Preview 1. While we previously determined it was too early to seriously consider adopting .NET Core, with this release we now believe that the current platform can support a comprehensive, reliable, and production-ready version of NServiceBus. As a result, we are happy to say NServiceBus 7 will support .NET Core 2.0 running on any of the supported platforms.

If you're using Azure Storage Persistence and haven't upgraded to NServiceBus 6 yet, get ready for a tremendous performance boost for your application when you do---especially if you make use of sagas.

Welcome back. Over the last few months, the Particular Slack channels have been awash with interesting links, thoughts, and blog posts. Here are the ones that bubbled to the surface.

I'll admit it: I'm a huge fan of The Hitchhiker's Guide to the Galaxy. I've voted for Zaphod Beeblebrox in more than one election and had a cat in college named The Ravenous Bugblatter Beast (Rav, for short). True to her name, she was an adept and ruthless hunter of cockroaches.

Tests are the life blood of many large codebases. They protect you from introducing bugs and in some cases, are instrumental in your code's design. Because of this, maintaining those tests is every bit as crucial as the underlying code that it tests. Like the rest of the project, your tests should be clear, concise, and consistent with your code style. Otherwise, tests might fall into disrepair and end up in a large bucket called technical debt, never to be heard from again.

The new RabbitMQ transport for NServiceBus 6 has one overriding theme: speed. Although we've added a few other features as well, the biggest news is how much faster we've made the new version of the RabbitMQ transport. We've redesigned the message pump to be more efficient, so it can handle more incoming messages. Outgoing messages are sent faster. We've even contributed changes to the official RabbitMQ Client project to increase its performance. Almost everything we've done was focused on making your systems faster and more efficient.

Happy holidays to all of you readers out there! Lately, several of our staff members have been active in the community, sharing valuable insights into building distributed systems. We thought we'd take this opportunity to share some of those resources, as well as other fun stuff, with you. With a bit of async/await, Azure Service Bus, AngularJS, code-driven visualizations, and even a throwback to the Commodore 64, there's something in here for everyone. We hope you enjoy!

.NET Core is out. Officially. After a lot of waiting, it's finally a real, finished, RTM thing, and as developers who are passionate about the .NET ecosystem, we're very excited about it. How cool is it to know that we can write code in C# (or VB.NET, or F#, etc.) and have it run on Windows, Linux, and even macOS? So why on earth doesn't NServiceBus support .NET Core yet? Well, good question.

Many .NET developers have been busy upgrading their code to take advantage of the async and await keywords. These keywords make asynchronous programming a lot easier by allowing us to represent a call to an asynchronous method almost as if it were a synchronous one. We just add the await keyword, and the compiler does the hard work of dividing the method into sections and keeping track of where to resume execution once async work completes. However, it's difficult to hide all the complexity of asynchronous programming behind a couple keywords, and there are a host of pitfalls and gotchas that you should be aware of. Without proper tooling, it's all too easy for any one of them to sneak up and bite you.

In order to support the async/await keywords in NServiceBus 6.0, we had to make the first ever breaking change to the message handler API. We realize that this is a big change, and it's not one that we made lightly. The move to async/await required that the Handle method signature return a Task instead of void. At the same time, we replaced IBus with context-specific parameters to make it clearer which messaging operations are available from within a message handler. In order to make the conversion process as easy as possible, we've prepared a screencast that demonstrates how to convert a message handler from the previous syntax to the async-enabled API in NServiceBus 6.0.

Scaling out a web server is easy. All you have to do is stand up a bunch of web servers behind a load balancer like HAProxy and you're covered. Unfortunately, it hasn't been quite as easy to scale out MSMQ-based NServiceBus systems. That is, until now.

When I make a promise to someone, I do my best to keep it. If I'm pretty sure I won't be able to do something, I don't make any promises about it. Instead, I say I'll try to address it eventually. It's all about managing expectations. In some ways, a promise is like a software interface — a kind of contract between the other person and me. With asynchronous computations, we make promises in software too. They are similar to the promises you and I make, representing operations that haven't happened yet but are expected to happen in the future. In JavaScript, for example, there is an explicit Promise construct. In .NET, this is done with the System.Threading.Task class. Unfortunately, not everyone takes promises seriously — both in real life and in software.