With Integration Monday gaining a wider audience reach, we thought it would be apt to get some sessions from the Product Group guys to let the community know what’s happening in the space of Azure and related technologies. The last two sessions (on September 14 & September 21) were on Service Bus and Azure API Management. We had Dan Rosanova from the Service Bus team speaking on the “Service Bus Premium Messaging Capabilities
” and Miao Jiang, a rising star PM in the API Management team, speaking on the latest updates in the Azure API management space
In this blog, we’ll give you a quick recap of the Service Bus Premium Messaging Capabilities session by Dan Rosanova.
[/ezcol_1fifth] [ezcol_4fifth_end]Dan Rosanova is a Senior Program Manager for the Internet of Things at Microsoft. He has a long history in distributed computing on a variety of platforms and has focused on large scale messaging and middleware implementations from inception to implementation. Before joining Microsoft, Dan was a five time Microsoft MVP. He is also the author of Microsoft BizTalk Server 2010 Patterns
In this session, Dan’s main focus was on Microsoft’s latest announcement on Azure Service Bus Premium Messaging Capabilities
, how it works, and when it is the best to use this messaging tier (rather, when you should not use it!).
Dan started off with the basic messaging concepts like Why Messaging, taking some analogies to understand the concept better. In a nutshell, messaging is something very similar to that of a postal service. Even though the concept/technology is old fashioned, it achieves the purpose quite easily – machine-to-machine communication. Say, for instance, you pay more, you get an Express Delivery service. The key take away point is –
Messaging is the pattern on which the cloud was built
No Messaging! What’s the Outcome?
Dan made the session interesting by considering a scenario where there’s absolutely no concept of messaging (say, you use direct service calls). Life without messaging looks simple at once, but actually its not. It becomes more complex than what you actually thought. Messaging protocols like HTTP, REST/Service bus with REST/Messaging Platform with REST and so on are not the right protocols to be used for messaging. This is the reason why Advanced Message Queuing Protocol (AMQP) has become the open standard for business message transactions between applications/organizations. Without messaging, you may feel you are getting something sophisticated/powerful by using the simplest technique, but in reality, without a messaging platform (such as BizTalk, RabbitMQ, and so on), its not the case! You end up investing pretty much just to realize that its not the right investment. Taking a U-turn at this stage is just suicidal.
A Powerful Messaging Platform Should Have These …
[ezcol_1quarter]Load Leveling[/ezcol_1quarter] [ezcol_1quarter]Load Balancing[/ezcol_1quarter] [ezcol_1quarter]Filtering[/ezcol_1quarter] [ezcol_1quarter_end]Partitioning[/ezcol_1quarter_end]
[ezcol_1quarter]Scheduled Delivery[/ezcol_1quarter] [ezcol_1quarter]Fan Out[/ezcol_1quarter] [ezcol_1quarter]Routing[/ezcol_1quarter] [ezcol_1quarter_end]Claim Checks[/ezcol_1quarter_end]
[ezcol_1quarter]Workflow[/ezcol_1quarter] [ezcol_1quarter]Taps[/ezcol_1quarter] [ezcol_1quarter]Logging[/ezcol_1quarter] [ezcol_1quarter_end]Dead Letter[/ezcol_1quarter_end]
[ezcol_1quarter]Sequence[/ezcol_1quarter] [ezcol_1quarter]Correlation[/ezcol_1quarter] [ezcol_1quarter]Expiration[/ezcol_1quarter] [ezcol_1quarter_end][/ezcol_1quarter_end]
Service Bus Standard Tier Features
Dan highlighted the list of features that are currently a part of the Standard Messaging Tier which makes Service Bus one of the most sophisticated messaging platform that has been developed.
[ezcol_1third]Scheduled Delivery[/ezcol_1third] [ezcol_1third]Poison Message Handling[/ezcol_1third] [ezcol_1third_end]ForwardTo[/ezcol_1third_end]
[ezcol_1third]Defer[/ezcol_1third] [ezcol_1third]Sessions[/ezcol_1third] [ezcol_1third_end]Batching[/ezcol_1third_end]
[ezcol_1third]Auto-delete on idle[/ezcol_1third] [ezcol_1third]OnMessage[/ezcol_1third] [ezcol_1third_end]Duplicate detection[/ezcol_1third_end]
[ezcol_1third]Filters[/ezcol_1third] [ezcol_1third]Actions[/ezcol_1third] [ezcol_1third_end]Transactions[/ezcol_1third_end]
Why Premium Messaging Tier?
In a high level service bus architecture, what basically happens is the following (we put it across in simple steps) –
- You (the user) send a message to the service bus from your client. This opens up a socket connection with the (stateless) Front End
- Front end connects with the (stateful) back-end
- Backend is always in sync with the storage in terms of transactions, updates, and so on. Backend writes the message to the storage, and your message is stored in the Service Bus!
- Handshake happens and an ACK is sent through every stage, thereby closing each connection, and you get the response back in your client machine stating the message was successfully stored
This looks simple, but what actually happens in reality is more complex. Dan’s way of putting across complex information in a very simple way is one of his trademark qualities to be noted. The following image shows how it actually works in reality. Sometimes, this can get problematic too! We’d highly recommend you to watch the video to understand the problems (such as Noisy Neighbor, ServerBusyException), and Dan’s usual correlations with an analogy ;-).
To basically address the problems that existed in the above mentioned high level architecture, the Azure Service Bus Premium Messaging tier was introduced. The main changes are done to the “Storage” tier and the “Backend” tier. On the storage tier, service bus now uses an advanced storage engine called the “Jet Stream” – the basic storage technology that lies under Event Hubs. Given the huge success of Event Hubs, the Service Bus team had no hesitations in using the Jet Stream (engine) for Service Bus Messaging. This solves a lot of performance issues that persisted with the SB Messaging capabilities since the past.
The Service Bus team has also improved the logic in such a way that each “Premium” message namespace gets its own piece of storage space instead of having a shared pool of Jet Stream storage for all namespaces. They have also improved the backend resources in such a way that each “premium” namespace gets its fair share of server resources (such as compute, memory, and so on). This eliminates the “Noisy Neighbor’ problem (we hope now you know what this means!).
Premium Messaging Model – Facts
Here are few important points from the Premium Messaging Model –
- You can select Premium while adding/creating new Namespaces (at the Namespace level)
- You cannot upgrade from Standard to Premium tier – since they don’t run on the same hardware any more!
- You can Select (Purchase) the number of Messaging Units (MUs)
- MUs are dedicated resource sets
- You can purchase them as either 1 MU, 2 MUs, or 4 MUs
- Pricing per MU – $22.26 USD/Day
- At present, Premium Messaging is available in Public Preview in 3 regions – U.S. (West), North Europe, and Hong Kong
When & When Not To Use Premium Messaging
You can use Premium Messaging when –
- You are highly latency sensitive (avoid Noisy Neighbor problems)
- You see so many ServerBusyExceptions
- You care only to send the best
- You have the scale
There are occasions when you better stay away from Premium Messaging, when –
- You are not in any of the above mentioned situations!
- You are COST SENSITIVE
- You are not in a hurry
The session dived into the Demo on how you can set up a new namespace with the Azure Service Bus Premium Messaging Tier. We recommend you to watch the video
to understand how to set up messaging using this model. We’ll leave it at this stage for you to get more insights from the video, and we bet, you must take a look at Dan’s way of presenting this new concept – In his full element of style!!
Stay tuned for our upcoming blog where we talk about the session from Miao Jiang on “Azure API Management Updates”.