I recently explored four common software design problems and legacy application issues that are holding organizations back today, positing that all of them can be successfully addressed with Microsoft Azure Service Bus. Today, I’ll dig deeper into Azure Service Bus’ reliable cloud messaging, how it can help you modernize your applications, and why it’s able to solve for such a diverse set of challenges.
What’s Holding Your App Back: A Recap
First, here’s a quick refresher on those top software design problems we role played last week:
- Tight Coupling: The applications in your ecosystem (e.g. your customer-facing website and CRM) talk directly to each other, creating a messy dependency chain, an unclear separation of responsibilities, and applications that no developer wants to touch. Tight coupling can threaten your ability to scale and attract or retain engineering talent.
- Polling: A Windows service or scheduled job runs over and over to check for new data or a new file. For example, you could be polling an email inbox every 15 minutes to check for new messages. The problem with polling is that it’s highly inefficient, especially when you’re polling incessantly only to get back an unchanged state.
- Unreliable Messaging: There is a mission-critical business process that fails often enough that it has become someone’s job to check on it regularly and resubmit failed tasks. This could be your invoice processing system, which when it fails requires someone in Accounts Receivable to manually load each failed invoice.
- Nonreactive UX: You’ve got a website or app that is only capable of presenting a given user with the latest data each time that user starts a new session, leading to frustration. The experience falls short of a modern user’s expectations and keeps your application from serving useful pop-up message notifications, etc.
It may sound too good to be true, but Azure Service Bus can help you address all of these issues and more. It’s a pub/sub messaging service that offers a reliable and secure platform for the transfer of data and state. With it, you can solve integration problems for applications that vary in environments, communication protocols, domains, and networks. You’ve probably heard the term pub/sub being kicked around, as it’s gotten a fair amount of attention in recent years. In short, pub/sub is a flavor of event-driven architecture. Whenever an event of interest occurs, the app which produced that event (the “sender”) publishes data into what is known as a “topic” in a well-known event library (usually referred to as a “message bus” or “service bus”). Any app interested in that particular type of event can subscribe to the topic, become a “receiver,” and be notified almost immediately whenever the event occurs.
With that in mind, let’s take a look at our problem areas above and how we can address each one using a pub/sub model.
Tight coupling is a thing of the past with pub/sub.
Azure Service Bus can decouple applications and services. If you want your team (or the world) to know when new users register on your website, your site can publish a message to a UserRegistered topic. Downstream systems can subscribe to that topic and, for example, log audit entries whenever a message arrives. What’s so great about that? None of these systems need to know anything about each other. Event producers can publish messages and go on with their lives, and event subscribers can process messages without getting in the way of each other.
Say goodbye to polling, too.
Instead of querying a database every five minutes to see if new records have been added from SomeApp, SomeApp can simply publish a message and SomeOtherApp can listen in and immediately go to work whenever a message arrives on that topic. Service Bus queues, which act as message brokers, do not need to have a receiver that polls for messages continuously.
All enterprise-level message buses offer reliable messaging.
If you want to save your team time and make sure all messages are successfully processed, turn on reliable messaging and go to town. When an application receives a message it’s unable to process because a database is down, it can throw an exception and the message will automatically be popped back onto the message bus and retried later. Even better, Azure Service Bus allows you to configure how often to retry a message and how many attempts to make before sending the message off to a special area called the dead letter queue. Add some monitoring to your dead letter queue and support staff can be notified that something’s been escalated.
Enhance your users’ experience in real time.
Finally, you can use a pub/sub model to ensure you always meet your users’ expectations. Let’s say you want to add a simple ‘Chat with Support’ module to your website and a matching Support Queue module to your internal admin website. With pub/sub, each site can publish messages to a SiteSupportChat topic, and each site can also subscribe to that very same topic. As messages are entered on either end, the other side will be notified immediately of new activity and can pop a message onto the appropriate user’s or administrator’s screen.
Making the Call: Azure Service Bus, or Bust?
In the Azure world, Service Bus is the underlying service that can support all of the above scenarios. If you think your application and organization could benefit from an event-driven, pub/sub approach, one of our experts at Polaris can help you confirm that Azure Service Bus is the route to go.
Contact us, and we can help you decide how to best utilize Azure’s messaging services–including Service Bus, Event Grid, and Event Hubs–to find the solution that best fits your needs. We’re passionate about helping businesses of any size solve for today’s goals and tomorrow’s.
Service Bus can be an integral part of your application modernization plan. But there’s even more Azure magic that can make the whole system work. Stay tuned and I’ll explore Function Apps, Logic Apps, and microservices via App Services in upcoming posts!