Particular Software Blog

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?

Fallacy #6: There is one administrator

In small networks, it is sometimes possible to have one administrator. This is usually the developer who creates and deploys a small project. As a result, this developer has all of the information about this project readily available in their head and, if anything goes wrong, will know precisely what to do.

I know quite a few developers and managers who talk about “bus theory” as a way to promote communication of critical knowledge. The central point is this: having only one person holding critical knowledge is dangerous because of what would happen if that person got run over by a bus. The term bus factor was coined to represent the number of people on your team who have to be hit by a bus before the project is in serious trouble.

Updates in ServiceControl 4.13

ServiceControl is the nerve center of your distributed system, storing the data and providing the APIs that allow ServicePulse and ServiceInsight to function.

In ServiceControl 4.13, we’ve made updates that make saga auditing more useful, provide better support for Azure Service Bus, simplify license management, and make it easier to keep ServiceControl up to date.

Transactions with Azure Table Persistence

What's new in SQL Server Transport 6.2

SQL Server Transport is one of our most popular transports. Customers often have deep proficiency with SQL and are able to use SQL Transport to add message queues to new or even legacy systems without needing to adopt (or get approval for) additional technology. This provides a glide path to begin using messaging, including all the advantages in loose coupling and reliability that come with it, and begin learning to design better software systems in a new way.

SQL Server Transport version 6.2.0 adds a few important features to make building complex systems even easier.

For extra secure systems, we’ve added support for SQL Server Always Encrypted so that messages can be encrypted so deeply that even SQL Server itself can’t read the messages without the correct keys. For scaled-out endpoints, you can now configure how the load balancing of batches is handled. We’ve also standardized the startup checks that endpoints do across all transaction modes.

Improvements to monitoring in ServicePulse 1.27

ServicePulse keeps on growing its arsenal of monitoring tools to help you uncover problems in your system and help fix them.

In ServicePulse 1.27 we decided to focus on the monitoring views of ServicePulse and make it easier to slice and dice information. We’ve also made some changes to message archiving. Keep reading to learn more about some highlights of what’s available to you now.

NServiceBus on AWS Lambda

The NServiceBus.AwsLambda.Sqs preview package makes it easier than ever to host NServiceBus endpoints in Amazon Web Services (AWS). AWS Lambda is Amazon’s serverless technology for running your code in the cloud with zero administration. You can run code for just about anything and Amazon takes care of running and scaling your code with high availability. You only pay for the compute time you consume.

As foundations go, this is as strong as bedrock. However, to build a complex distributed system on serverless technology that implements best practices from the Enterprise Integration Patterns book, you need something more that will bridge the gap between the “invisible” server infrastructure and your business code.

That is where our new AWS Lambda SQS package comes in. NServiceBus provides the infrastructure code not provided by Lambda so that you can write business code and execute it in the Lambda environment. You can even use Lambda, with its cheap hosting model for rapid prototyping, and only later take advantage of the NServiceBus abstraction to easily shift hosting to container-based deployment or even to a competing cloud platform.

The power of Cosmos DB comes to NServiceBus

With the recent preview release of NServiceBus.Persistence.CosmosDB, you can now use Azure Cosmos DB with NServiceBus! Backed by Cosmos DB, a fully managed, globally distributed, elastically scaled, pay-as-you-go service, your NServiceBus-based systems can benefit from guaranteed single-digit-millisecond latency with 99.999% availability. If you are already using Cosmos DB to store your business data, you no longer need to use a different storage technology to store your NServiceBus saga data.

What's new in ServiceInsight 2.2

A common problem with most distributed systems is that it’s hard to get a good view of how all the disconnected pieces work together—unless you’re using ServiceInsight. From the audit records of successfully processed messages, ServiceInsight shows how messages are related and gives you visualizations so you can better understand how one message results in another, and how the different parts of the system communicate.

ServiceInsight 2.2 is out now, with plenty of improvements. This release adds new insights (pun intended) to your distributed systems.

Optimizations to scatter-gather sagas

Over the last several months we’ve been noticing that some of our customers were having trouble with the performance of some of their sagas. Invariably, the sagas that were at fault were examples of the scatter-gather pattern, and the ultimate culprit was contention at the storage level due to the optimistic concurrency strategy that was being used.

This is a fairly common pattern for sagas to implement, and we didn’t want our customers to have to change how they model their business process to get around a performance problem, so we decided to fix it.

In this article, I’ll explain what the scatter-gather pattern is, how a pure optimistic concurrency strategy created a problem, and what we’ve done to fix it for you.