Posts related to azure

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”

More powerful Cosmos DB persistence

The key to a successful Cosmos DB system is its data partitioning strategy. Like the rows of shrubs in a hedge maze, the logical partitions that divide data must be carefully planned, because that affects the scalability of the system and defines the boundaries for logical transactions.

In version 1.1 of our CosmosDB persistence package, we’ve made defining the partition key for each message processed by NServiceBus much more straightforward, without needing a custom pipeline behavior. We’ve also added pessimistic concurrency support for more reliable processing of sagas with high contention patterns.

What's new with NServiceBus and Azure Functions

Do you think Azure Functions are pretty great? Us too! Do you hate boilerplate code? Yeah, us too.

Have you heard of C# source generators ¹ and thought they sounded pretty cool but didn’t really know how they could be useful?

In the newest version of our Azure Functions integration, we’ve used source generators to reduce the boilerplate needed to set up an NServiceBus endpoint on Azure Service Bus down to just a few lines of code.

Cosmos DB Persistence — Questions & Answers

We recently released NServiceBus.Persistence.CosmosDB version 1.0, which provides saga and outbox storage for NServiceBus endpoints that is transactionally consistent with the business data you store in Cosmos DB.

This component was previously offered as a preview package. Now that it has reached version 1.0, our full support policy applies, including API stability and backporting of bugfixes.

Now that our Cosmos DB persistence has reached general availability, let’s answer some common questions about Cosmos DB and what it means to use Cosmos DB with NServiceBus.

NServiceBus with Azure Functions turns 1.0

NServiceBus support for Microsoft Azure Functions, previously available as a preview package, is turning the big 1.0 and is now generally available.

Over the past nine months, we’ve been offering NServiceBus support for Microsoft Azure Functions as a Preview. This marked the first in a series of previews designed to provide new capabilities to the Particular Software Platform and explore new options for NServiceBus customers.

Now we’re adding Version 1.0 to its credentials, which means that in addition to production support, we’re also committing to all aspects of our support policy, including API stability and backporting of bug fixes. Plus we added a few more features, so you can do a lot more with Functions too.

Let’s take a look.

Azure Storage Queues learns some new tricks

Transactions with Azure Table Persistence

The power of Cosmos DB comes to NServiceBus

Update: NServiceBus persistence for Cosmos DB is now 1.0. In addition to full production support, that means API stability and backporting of bugfixes. See our release announcement here.

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.

Support for Azure Functions

Update: NServiceBus hosting with Azure Functions for Azure Service Bus is now 1.0. In addition to full production support, that means API stability and backporting of bugfixes. See our release announcement here.

Microsoft Azure Functions provide a simple way to run your code in the Azure Cloud. They are easy to deploy, scale automatically, and provide many out-of-the-box ways to trigger your code. Rather than pay for an entire virtual machine, you only pay for compute while your code is being executed.

NServiceBus makes Azure Functions even better. You can use a simple but powerful API to consume and dispatch messages, add robust reliability features like delayed retries, an extensible message processing pipeline, and a suite of tools to help you monitor and maintain your message-driven system. We think they go together like milk and cookies.

The end of the legacy Azure Service Bus transport

A while back, we introduced a brand new transport for use with Azure Service Bus. This transport was a necessary step in our Azure offering to allow users to target .NET Standard and .NET Core. It also used the new Microsoft.Azure.ServiceBus client rather than the older, deprecated client.

More importantly, it started the process of deprecating the now-legacy Azure Service Bus transport. At the time, we didn’t have details about how we would do that; now we do.

Getting NServiceBus ready for the cloud

More and more companies are realizing that it’s in their best interest to move to the cloud. As software consultants at Headspring, we’re often tasked with helping organizations migrate their highly complex legacy systems to modern cloud environments. For clients using NServiceBus to facilitate messaging, moving to the cloud without it seems untenable. So how do we prepare to take NServiceBus with us?

For complex software systems like the ones we’re used to working with, moving to the cloud often involves more than a simple “lift and shift.” NServiceBus proves to be just as valuable in a cloud environment, but various aspects of its configuration and integration into the system need to be modified in order to take full advantage.

One of our recent clients—a government agency—was already using NServiceBus and wanted to migrate their system to Azure. The steps we took to get NServiceBus ready to run in Azure may be helpful to you as you map your own cloud moves. I’ll walk you through exactly what we had to do differently in the cloud, explain the hybrid-cloud solution we built with NServiceBus for reporting, and demonstrate how we handled logging in the cloud, as well as our client’s need to run locally on occasion.

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.

Introducing the new Azure Service Bus transport for .NET Core

The wait is over! Today we’re releasing the new Azure Service Bus transport, which is fully compatible with NServiceBus 7 and .NET Core.

You will now be able to run NServiceBus endpoints using Azure Service Bus anywhere.

NSBCon 2015: All about Transports

Knowing which NServiceBus transport is best for your application is not easy. There are many factors involved in selecting a message transport; distributed transactions, legacy integration, cross-platform capabilities, and cloud deployments are a few that might be considered. At NSBCon 2015 Andreas Öhlund outlines the different transports that are available for NServiceBus. He covers the highlights and lowlights of each. Rather than telling you which transport is the right one, Andreas provides you with the tools to make that decision yourself, within the context of your project.