The course is part of these learning paths
Azure Artificial Intelligence Services
Design for IoT
Design Messaging Solution Architectures
Design Media Service Solutions
The Microsoft Azure 70-535 exam has a large section focused on creating practical solutions using Azure technologies. About 10-15% of the exam will cover Azure products focused on AI, Messaging, Internet of Things, and Video Media. This will require familiarity with dozens of Azure solutions.
This course will take you through all of the relevant technologies and ensure you know which ones to pick to solve specific problems. After taking this course you should be well-prepared for the 70-535 exam. However this is not only a test prep course. This course is also for developers, engineering managers, and cloud architects looking to get a better understanding of Azure services.
Whether your app deals with artificial intelligence, managing IoT devices, video media, or push notifications for smart phones - Azure has an answer for every use case. This course will help you get the most out of your Azure account by preparing you to make use of many different solutions.
Design solutions using Azure AI technologies
Design solutions for IoT applications using Azure technologies
Create a scalable messaging infrastructure using Azure messaging technologies
- Design media solutions using Azure media technologies and file encoding
People who want to become Azure cloud architects
People preparing for Microsoft’s 70-535 exam
General knowledge of IT architecture
Now that you have some context around messaging systems and push notifications we’re going to do a thorough survey of the relevant Azure solutions. Some of them you likely already know. We covered several in the previous section. Others we have covered in other Cloud Academy courses. For this lesson, we will do a short review of those technologies covered in the section on IoT. The other technologies that have not yet been introduced in this course will be covered after that.
So let’s start with a brief review of Azure Event Grid, Azure Event Hubs, Azure Service Bus, and Azure Notification Hubs. Azure Event Grid, as you may recall, is an intelligent event routing system. It takes, as an input, some event source, such as IoT Hubs or blob storage, and connects it to a downstream service such as Azure Functions or Logic Apps. It is not meant for message processing or ingestion but rather relaying. Azure Event Hubs, like IoT Hub, IS an event ingestion system. It can be used to ingest generic messages, since events are a type of message, however it is optimized for an event-based use case. It is designed to be extremely scalable and performant. With the right configuration you can ingest literally millions of messages per second.
Now as for Azure Notification Hubs, which we talked about for IoT, we’re actually going to give it its own lesson. The 70-535 exam expects you to know how to actually create a push notification system and Azure Notification Hubs will be your primary solution. So no worries, we will revisit it in significant depth soon.
So that leaves Service Bus for review. Azure Service Bus is probably most directly relevant to this section as it is indeed designed for generic message handling. Service Bus is more than just a queuing system that supports publish/subscribe based approaches. As you can see in the comparison below it is a “high value enterprise messaging” system. Similar to Kafka, it can use topics for sending and receiving messages. Topics can have multiple subscriptions making it easy to scale horizontally.
Now as we discussed previously Service Bus has a number of additional features that make it more robust than just a typical message queue. You get durable transactions, scheduled delivery, dead-lettering for messages that cannot be delivered - you can store and process them later - you also get client side batching options, filtering for subscription rules to ensure downstream consumers only get specific messages, message duplicate detection, and some handy security features including role-based access control and SAS aka shared access signatures.
So, whew! That’s a lot that it can do. It may seem like Service Bus should then be your go-to solution for messaging with Azure. Mmm...not quite. There are tradeoffs with Service Bus that we will discuss when we start talking about the other messaging solutions later in this section.
One other important thing we need to cover before moving away from Service Bus is Azure Relay. This is a very important component of the Azure product line that has gone under significant change and is directly related to the Service Bus overall platform. At a high level Azure Relay is a system for connecting corporate enterprise networks to the wider public cloud, without the need to open firewalls or make changes to corporate network infrastructure. If you have had to work with corporate network security with Windows, you may already be familiar with WCF relays - Windows Communication Foundation, that is. WCF is the legacy relay for enabling remote procedure calls securely. Azure Relay subsumes this feature and offers a second feature known as Hybrid Connections.
So what’s the difference between WCF and Hybrid Connections. Well to start, see the chart here. Hybrid Connections is actually an open-protocol evolution of the WCF relay approach. It can be implemented in any language with websockets support. Its feature set is entirely based on HTTP and websockets. To set it up all you need to do is define a relay namespace in your Azure account.
Now we don’t need to get into the nitty gritty technical details of how Azure Relay implements all of this. The diagram should give you some idea and we’ve included a link to the documentation for people that want to know more. The key thing is to understand the problem it solves: Allowing your messaging system to safely connect traffic from the public internet to an on-premise or corporate network. (https://docs.microsoft.com/en-us/azure/service-bus-relay/relay-what-is-it)
Now let’s get into the as yet uncovered messaging solutions. We need to talk about Azure Storage Queues, Azure Functions, and Azure Logic Apps.
Let’s take them in order. Azure Storage Queues are the most popular message queuing system within Azure. This is because of their incredible simplicity and flexibility. All you need is an Azure storage account and you can begin creating queues of work to process asynchronously. Using HTTP or HTTPS calls you can process millions of messages from a single queue. The two limitations to keep in mind are 1. The total capacity of your storage account and 2. Individual messages in a queue can only go up to 64 KB in size. Service Bus, by contrast, supports messages from 256 KB up to 1 MB in size depending on your tier. Even with these restrictions, Azure Storage Queues are usually better for most simple message queue use cases. They are simpler to configure than Service Bus and often cheaper. They also have wider library support as their are Azure storage libraries for C++, Python, Ruby, PHP, Node.js, and Java, as well as PowerShell and .NET.
Now, one tradeoff is that Azure Storage queues do not give you the same ordering guarantees as Azure Service Bus. You get an “at least once” delivery guarantee and have to make sure your app has logic to properly order operations and transactions. For this and other reasons Storage Queues are generally better for simply managing messages within your Azure app. See the detailed comparison in the slide here. As you can see there are a number of feature differences between Storage Queues and Service Bus. So thinking about use cases, if, for example, you are dealing with backend worker processes that need to communicate with frontend services, all within an Azure infrastructure, Storage Queues would probably work fine. In this use case the overhead of Service Bus is likely unnecessary. Once you need to start integrating with external apps and you need more guarantees and real transactions, Service Bus may be the better way to go.
So now let’s switch gears and talk about Azure Functions. If you’re familiar with Amazon Lambda then you already have a basic idea of Azure Functions. They are a service for executing “code on demand.” They are not a message queue or ingestion system. Rather they are for processing messages coming from some other source. So often you will have something like an Event Hub or Service Bus act as an input to an Azure Function. The function takes the message, executes some code to process it, and then outputs it to some other endpoint based on your architecture. Functions are ‘pay per use’ in terms of pricing and super easy to scale; since they are serverless, Azure will do all of the scaling for you.
So how do we actually use an Azure Function? The basic approach is to set triggers. As you can see here there are many kinds of triggers. A Function can be triggered by messages arriving in an Azure Storage Queue, or an Event Hub, or Service Bus. Functions can also be triggered by HTTP requests, Github webhooks, timers, and other generic types of webhooks. You get a range of options and strong integration with Azure services like Event Grid, Notification Hubs, Cosmos DB, and Azure Storage. So if you’re application logic - your startup’s “special sauce” - can be easily translated into discrete code calls to be run as an Azure Function, this may be the simplest and most scalable paradigm for message processing available.
Finally, let’s talk about Azure Logic Apps. Logic Apps are a tool for automating workflows in Azure. So what exactly is a workflow? Well a workflow is just a business process broken down into a series of steps. It may involve grabbing data from storage, executing a function, posting a message somewhere, sending an alert, firing an email, etc. etc. What Logic Apps do is allow you to automate these workflows and add, surprise surprise, logic! This means you can add conditions - you can make it so that workflows only trigger after specific events. You can define logic apps using the Azure Portal or by writing JSON definitions. You can also use PowerShell.
Logic Apps are not for creating custom code or complete software applications from scratch. They are really for wiring together parts of your Azure infrastructure or connecting it with legacy systems. So how does this relate to messaging? Well, consider the diagram here. Your messaging system needs to do more than just ingest messages. It may need those messages to trigger additional processes. You may be able to do that with an Azure Function, but that would require writing code. With an Azure Logic App you could, for example, have a message trigger an update to a Slack chatroom by having the app monitor your blob storage. This could be set up with just a few clicks on the Azure portal. Pretty cool.
So that about does it for our review of Azure messaging solutions. There is A LOT of content in this lesson so don’t feel bad if you need to review it a few times. We’re going to focus in on our push notification use case in the next lesson and do some light review in the final part of the section covering scalability. See you there!
About the Author
Jonathan Bethune is a senior technical consultant working with several companies including TopTal, BCG, and Instaclustr. He is an experienced devops specialist, data engineer, and software developer. Jonathan has spent years mastering the art of system automation with a variety of different cloud providers and tools. Before he became an engineer, Jonathan was a musician and teacher in New York City. Jonathan is based in Tokyo where he continues to work in technology and write for various publications in his free time.