Posts related to messaging

Managing success and growing pains

Every software system evolves through different stages of complexity. They start simple—attempting to solve a problem that might not yet be well-defined. As they grow, problems become more well-defined, and then they grow some more. Just like with lanky teenagers, this growth can sometimes cause growing pains. A skilled architect knows how to watch for the signs of these growing pains and how to apply more robust architectural patterns to ensure the system can continue to grow and flourish.

This post is the story of the growing pains experienced by our friends at VECOZO, a system integrator that ensures safe communication between numerous healthcare-related companies. They knew it would be irresponsible to design every piece of software to handle massive scale, even if it only had a few users. So, when the architects started to see telltale signs, they knew it was time to deploy more robust architectural patterns.

As you read on, maybe you’ll find that some of the challenges they faced sound familiar…

What they don't tell you about migrating a message-based system to the cloud

Migrating a message-based system from on-premises to the cloud is a colossal undertaking. If you search for “how to migrate to the cloud”, there are reams of articles that encourage you to understand your system, evaluate cloud providers, choose the right messaging service, and manage security and compliance.

Curiously, what’s often missing from the discussion is details, like how to handle all the other on-prem systems that integrate with your system, both upstream and downstream, that can’t be upgraded at the same time. This gets even more tricky when those integrations are over on-prem-only technologies, like MSMQ, that don’t integrate out-of-the-box with cloud alternatives like Azure Service Bus or Amazon SQS. It’s as if they’re saying, “Have you documented your system? Great! Have you chosen a cloud provider? Awesome! Do you have all the services in place? Wonderful! Now go rewrite all your code… we’ll wait…are you done yet?..What are you looking at me for? I’ve already told you to plan carefully, I can’t do EVERYTHING for you”

Banish ghost messages and zombie records from your web tier

Because it’s hard to write idempotent code effectively, NServiceBus provides the outbox feature to make your business data transaction and any sent or received messages atomic. That way, you don’t get any ghost messages or zombie records polluting your system. ¹

But the outbox can only be used inside a message handler. What about web applications and APIs?

With the new NServiceBus.TransactionalSession package, you can use the outbox pattern outside of a message handler too.

RPC vs. Messaging – which is faster?

Sometimes developers only care about speed. Ignoring all the other advantages messaging has, they’ll ask us the following question:

“But isn’t RPC faster than messaging?”

In place of RPC, ¹ they may substitute a different term or technology like REST, microservices, gRPC, WCF, Java RMI, etc. However, no matter the specific word used, the meaning is the same: remote method calls over HTTP. So we’ll just use “RPC” for short.

Some will claim that any type of RPC communication ends up being faster (meaning it has lower latency) than any equivalent invocation using asynchronous messaging. But the answer isn’t that simple. It’s less of an apples-to-oranges comparison and more like apples-to-orange-sherbet.

Let’s take a look at the bigger picture.

Cross-platform integration with NServiceBus native message processing

When the Romans met the Gauls for the first time, they couldn’t talk to each other. The Romans spoke Latin, and Gauls a Celtic language. How could they communicate? It must have been difficult to start with simple gestures, slowly building enough concepts, until a full translation guide was possible. Perhaps one day, as in Star Trek, a universal translator will enable us to talk to anyone regardless of their language, even if chah jatlh Tlhingan. ¹

Sometimes I feel like a Roman meeting a Gaul for the first time. Different technologies make sense to address different problems. For example, if your order entry front end can benefit from rapid prototyping, you should be able to use Ruby on Rails and Active Record. In your back-end system, you might benefit from event-driven architecture, automatic message retries, and orchestration of long-running business processes. In that case, you should be able to use C#, RabbitMQ, and a messaging framework like NServiceBus.

But then, how do we get these parts to communicate and work together?

Autosave for your business

If you’re a long-time video game player like me, your muscle-memory vividly remembers the F5 key’s location on your keyboard. For everyone else: F5 is a common key-binding for “quicksave” in computer-games. And like many others, I learned how to use it the hard way. After spending hours sneaking through dungeons, battling orcs, and looting valuable treasures, some nasty troll made an unexpectedly quick end to my character. That’s when I would realize that I hadn’t saved my game for a very long time and had to start over. From that moment on, I’d save my game as often as I could, and F5 became my closest ally.

Modern games now provide a built-in feature called autosave. These games save your progress automatically now and then so that you won’t lose all your progress—only a few minutes at worst. This might sound trivial and obvious, but it is a game-changer for player experience. The player can now focus on solving their mission rather than the mechanics of the game itself.

Why are we talking about video games when we have important business (let’s say, selling video games) to do? Let me ask a different question: what if that nasty end boss doesn’t come in the form of a troll? What if the end boss is a network error, power outage, concurrency conflict, or even squirrels?

What Starbucks can teach us about software scalability

In 2004, Gregor Hohpe published his brilliant post “Starbucks Does Not Use Two-Phase Commit.” When I read it, my time working at Starbucks during my college years suddenly became relevant. Over the years, I gradually realized there’s even more that programmers can learn from the popular coffee chain.

Although many people may want to build scalable software, it can be much harder than it first appears. As we work on individual tasks, we can fall into a trap, believing all things are equally important, need the same resources, and happen synchronously in a predefined order.

It turns out they don’t—at least not in scalable systems, and certainly not at Starbucks.

Empires fall: Decentralize your code to avoid total collapse

Status fields on entities – HARMFUL?