There are many communications platforms that can help improve the reliability of a distributed application, including several within Azure. Each of these tools serves a different purpose. Let's review each tool in Azure to help choose the right one. The architecture of our pizza ordering and tracking application requires several components. A website, back-end service, data storage, and so on. We combined the components of our application together in many different ways and a single application can take advantage of multiple techniques. We need to decide which techniques to use in the Contoso slices application. The first step is to evaluate each place where there is communication between multiple parts. Some components must run in a timely manner for our application to be doing it's job at all. Some may be important but not time-critical. Finally, other components like our mobile app notifications are a bit more optional. Messages and events are both data grams, packages of data sent from one component to another. They are different in ways that at first seem subtle, but can make significant differences in how you architect your application. In the terminology of distributed applications, the defining characteristic of a message is that the overall integrity of the application may rely on messages being received. You can think of sending a message as one component, passing the baton of a workflow to a different component. The entire workflow maybe a vital business process and the message is the mortar that holds the components together. A message generally contains the data itself, not just a reference like an ID or a URL to data. Sending the data as part of the data gram is less brittle than sending a reference. The messaging architecture guarantees delivery of the message and because no additional look-ups are required, the message is reliably handled. However, the sending application needs to know exactly what data to include to avoid sending too much data, which requires the receiving component to do unnecessary work. In this sense, the sender and receiver of a message are often coupled by a strict data contract. In Contoso slices new architecture, when a pizza order is entered, the company would likely use messages. The web front-end or mobile app would send a message to the back-end processing components. In the back-end, steps like rising to the store near the customer and charging the credit card would take place. An event triggers a notification that something has occurred. Events are lighter than messages and are most often used for broadcast communications. Events have the following characteristics. The event may be sent to multiple receivers or to none at all. Events are often intended to fan out or have a large number of subscribers for each publisher. The publisher of the event has no expectation about the action the receiving component takes. Our pizza chain would lightly use events for notifications to users about status changes. Status change events could be sent to Azure Event Grid, then onto Azure Functions, and to Azure Notification Hubs for a completely serverless solution. This difference between events and messages is fundamental because communications platforms are generally designed to handle one or the other. Service Bus is designed to handle messages. If you want to send events, you would likely choose Event Grid. Azure also has Azure Event Hubs, but it is most often used for a specific type of high-flow stream of communications used for analytics. For example, if we had network sensors on our pizza ovens, we could use Event Hubs coupled with Azure Stream Analytics to watch for patterns in the temperature changes that might indicate an unwanted fire or component wear. Azure Service Bus can exchange messages in three different ways. These are queues, topics, and relays. Let's explore each of these now in a little more detail. A queue is a simple temporary storage location for messages. A sending component adds a message to the queue. A destination component picks up the message at the front of the queue. Under ordinary circumstances, each message is received by only one receiver. Queues decouple the source and destination components to insulate destination components from high demand. During peak times, messages may come in faster than destination components can handle them. Because source components have no direct connection to the destination, the sources unaffected and the queue will grow. Destination components will remove messages from the queue as they are able to handle them. When demand drops, destination components can catch up and the queue shortens. A queue response to high demand like this without needing to add resources to the system. However, for messages that need to be handled relatively quickly, adding additional instances of your destination component can allow them to share the load. Each message will be handled by only one instance. This is an effective way to scale your entire application while only adding resources to the components that actually need it. A topic is similar to a queue but can have multiple subscriptions. This means that multiple destination components can subscribe to a single topic, so each message is delivered to multiple receivers. Subscriptions can also filter the messages in the topic to receive only messages that are relevant. Subscriptions provide the same decoupled communications as queues and respond to high demand in the same way. Use a topic if you want each message to be delivered to more than one destination component. It's important to note that topics are not supported in the basic pricing tier. Finally, what is a relay? A relay is an object that performs synchronous two-way communication between applications. Unlike queues and topics, it is not a temporary storage location for messages. Instead, it provides bidirectional on buffered connections across network boundaries such as firewalls. Use a relay where you want direct communications between components as if they were located on the same network segment but separated by network security devices. It's important to note that although relays are part of Azure Service Bus, they do not implement loosely coupled messaging workflows and are not considered further in this lesson. There are two Azure features that include message queues, Service Bus and Azure storage accounts. The key advantages of Service Bus queues include, it supports larger message sizes of 256 kilobytes, standard tier or one megabyte, premium tier per message versus 64 kilobytes. It supports both at most once and at least once delivery. Choose between a very small chance that a message is lost or a very small chance that it is handled twice. It guarantees first-in, first-out order. Messages are handled in the same order they are added. Although FIFO is the normal operation of a queue, it is not guaranteed for every message. It can group multiple messages into a transaction. If one message in the transaction fails to be delivered, all messages in the transaction will not be delivered and it supports role-based security. It does not require destination components to continuously poll the queue. The advantages of storage queues are, its supports unlimited queue size versus an 80 gigabyte limit for Service Bus queues and it maintains a log of all messages.
