Particular Software Blog

MSMQ is dead

We gather here today to mourn the passing of a dear friend. Microsoft Message Queuing, better known by its nickname MSMQ, passed away peacefully in its hometown of Redmond, Washington on October 14, 2019, at the age of 22. It was born in May 1997 and through 6.3 versions lived a very full life, bringing the promise of reliable messaging patterns to users all around the globe. It is preceded in death by Windows Communication Foundation and Windows Workflow Foundation, and survived by Azure Queues and Azure Service Bus. It will be greatly missed.

Fallacy #5: Topology doesn't change

It's easy for something that started out simply to become much more complicated as time wears on. I once had a client who started out with a very noncomplex server infrastructure. The hosting provider had given them ownership of an internal IP subnet, and so they started out with two load-balanced public web servers: X.X.X.100 and X.X.X.101 (Public100 and Public101 for short). They also had a third public web server, Public102, to host an FTP server and a couple random utility applications.

And then, despite the best laid plans, the slow creep of chaos eventually took over.

Infrastructure soup

When it starts to get colder outside I start to think about soup. I love soup, especially chili. But I don't want any of that watery gunk that's just tomato soup with a few lonely beans floating in there somewhere. No sir! I want it thick and chunky. Load it up with ground meat, beans, onions, tomatoes, cheese, green peppers, jalepeños, pineapple–it's all good!

Just like with chili, we sometimes see code that feels kind of "thick and chunky." It's got validation, logging, exception handling, database communication, business logic, and so much more. But unlike chili, the result does not taste good.

We see this kind of bloated, muddled code all over the place, regardless of what language or framework is being used, and NServiceBus is no exception. Here's an example where someone has stuffed an NServiceBus message handler full to the breaking point:

The new MongoDB support for NServiceBus

If you're using (or considering) MongoDB with NServiceBus, we've got good news: we've just released our official MongoDB persister. This replaces the previous community-created (but now abandoned) MongoDB persistence options and is now a fully supported part of the Particular Service Platform.

Fixing malformed messages with ServicePulse

Did you ever look at a failed message in ServicePulse and think "I wish I could just edit this quickly and dump it back in the queue"? Yes, you should follow best practices and investigate the root cause and make sure the error doesn't come back, but the real world moves faster than that and sometimes you just need to get &#@%! done and figure it out later.

Now you can. Using ServicePulse 1.21.0+ and ServiceControl 4.1.0+, you can edit the headers and body of a failed message and quickly get back on track.

Multi-tenancy support in SQL Persistence

Multi-tenant systems are a popular way to use the same codebase to provide services to different customers while minimizing the effect they have on each other. In a distributed message-based system you need to partition customer information and segregate messages from different customers as well. Additionally, you have to make sure different system components are tenant-aware.

In NServiceBus SQL Persistence 4.6, we have added new features that make it a bit easier to create multi-tenant systems. Let's see how it all works.

Fallacy #4: The network is secure

There are a myriad of security-obsessed organizations scattered throughout the world that take security concerns to the verge of paranoia.

In one such organization I've heard of, there existed two separate networks. Everyone had two computers without external disk drives of any kind. Inserting a USB drive would not work, and trying to use one would instantly alert the sysadmins that a workstation was compromised. To get data from a different network, you needed to browse in a separate room, as workstations did not have access to the Internet.

Once you found the data you needed, you could download it to a floppy disk and then hand the floppy over to a sysop. The sysop would copy the contents to a mirror folder, which would analyze the contents with every virus scanner imaginable before mirroring them to the development network. But that sync only occurred once per hour.

Paranoid? Maybe. If you're just selling widgets on a website, then probably. But if your organization is working on defense contracts or controls critical infrastructure like electrical grids, perhaps the paranoia is justified.

The only truly secure computer is one that is disconnected from any and all networks, turned off, buried in the ground, and encased in concrete. But that computer isn't terribly useful.

What does idempotent mean?

When you start to accumulate home theater components to go with your TV, you end up with a bunch of remote controls. One remote for the TV, one for the receiver, and one for the DVD/Blu-Ray player. One for a cable box, satellite, or set-top streaming box. Maybe you've got a multiple-disc CD player, or even a turntable. (Vinyl is making a comeback!) Maybe you've even still got a VHS?…no I'm kidding, nobody has those anymore.

The solution, rather than dealing with a stack of remotes, is to get one universal remote to rule them all. But once you do, you find that not all components are created equal, at least when it comes to the infrared codes (the actual signals sent by the remote control) that they accept.

A cheap A/V receiver might accept codes like PowerToggle or NextInput. These make it nearly impossible to reliably turn the unit on and set the right input, especially if someone has messed with the receiver manually.

A good receiver will have additional codes for PowerOn and PowerOff, even though those buttons don’t exist on the remote, and will also have an independent code for each input, like InputCable, InputSatellite, and InputBluRay.

This is the essence of idempotence. No matter how many times your universal remote sends the PowerOn and InputBluRay commands, the receiver will still be turned on and ready to watch Forrest Gump. PowerToggle and InputNext, however, are not idempotent. If you repeat those commands multiple times, the component will be left in a different (and unknown) state each time.

Fallacy #3: Bandwidth is infinite

Everyone who is old enough to remember the sound of connecting to the Internet with a dial-up modem or of AOL announcing that "You've got mail" is acutely aware that there is an upper limit to how fast something can be downloaded, and it never seems to be as fast as we would like it.

The availability of bandwidth increases at a staggering rate, but we're never happy. We now live in an age when it's possible to stream high definition TV, and yet we are not satisfied. We become annoyed when we run a speed test on our broadband provider only to find that, on a good day, we are getting maybe half of the rated download speed we are paying for, and the upload speed is likely much worse. We amaze ourselves by our ability to have a real-time video conversation with someone on the other side of the world, but then react with extreme frustration when the connection quality starts to dip and we must ask "are you there?" to a face that has frozen.

Today, we have DSL and cable modems; tomorrow, fiber may be widespread. But although bandwidth keeps growing, the amount of data and our need for it grows faster. We'll never be satisfied.

Has Microsoft really changed?

People have a lot of opinions about the "new" Microsoft under CEO Satya Nadella. They've embraced open-source, including .NET Core. They declared Microsoft ❤ Linux. They acquired GitHub. It's been a wild ride for those of us used to the closed, dare I say grumpy Microsoft of the past.

But are things different today? When the rubber hits the road, is Microsoft really more open, more accessible, more helpful?

When we were building the Azure Service Bus transport for .NET Core we got a chance to find out.