Hosting your application and data and having it scalable, secure, and highly performant is nice, but wouldn't it be great if you could add intelligent features to it?
Search is a common feature in most applications, and yet it has traditionally been a difficult function to implement. Azure Search provides a lot of the "plumbing" to do search. You spin up an Azure Search instance, create an index that helps you search, and fill it with data—that's it. There are lots of options that you can use to tweak Azure Search, and there are lots of great features that will make searching easier for your users:
You could implement Azure Search to help users search your product catalogue in an e-commerce application.
With Azure Cognitive Services, you can add incredible intelligence to your applications. Cognitive Services is a collection of APIs that you can use to accomplish what at times appears to be magic.
There are more than 25 APIs in the categories of Vision, Speech, Language, Knowledge, and Search. Here's a glimpse of the APIs that you can use:
The Cognitive Services get their smarts through machine learning and artificial intelligence, which you can train with your own datasets. These services are simply amazing and open up possibilities that we couldn't even dream of a mere few years ago.
The Azure Bot Service makes it easy for you to create a bot—a piece of software that can automatically and autonomously interact with users.
Creating a bot is no trivial task. You need to keep track of the context of your interaction with the user, and you must be ready to respond to a multitude of possible interaction parameters. Bot Service helps you with this in the following ways:
An example of a bot that you can build with Bot Service is one that provides your users with answers to their most frequently asked questions. The interface of the bot can be a chat box that is on your website.
Modern, globally distributed applications often must deal with large amounts of messages coming in and need to be designed with decoupling and scaling in mind. Azure provides several services to help with event ingestion and analysis and messaging patterns.
The core of messaging in Azure is the Azure Service Bus. The Service Bus service encompasses a collection for services that you can use for messaging patterns, most important among them Azure Services Bus Queues and Topics.
You use Azure Service Bus Queues to decouple systems from one another. Here's an example: A web application receives orders from users and needs to invoke a web service to process the order. The web service will take a long time, maybe up to five minutes, to process the order completely. Of course, it's unacceptable for the web application to wait five minutes between the user placing an order and showing feedback. A good way to solve this is to use a queue to decouple the web application from the web service.
The web application receives the order and writes it in a message on an Azure Service Bus Queue. After it has done that, it can inform the user that the order is being processed. The web service takes messages from the queue, one by one, and processes them. When the web service is done processing an order, it sends an email notification to the user that the item has been ordered.
By decoupling the systems, the web application can work at a different speed from the web service, and both can be scaled individually to the applications' needs.
Services Bus Queue is a simple mechanism. Multiple applications can put messages on the queue, but a queue message can be processed by only one application at a time. It has some clever features to work with messages on the queue, like duplicate detection and a dead-letter subqueue to which messages are moved when they fail to be processed correctly.
Just like Service Bus Queues, Azure Service Bus Topics are a form of application decoupling. Here's the differences between the queue and topics:
Service Bus Topics works just like a queue, and multiple applications can process the same message. Applications can create a subscription on the topic, that indicates what type of messages they are interested in. Just like queues, topics have features like duplicate detection and a dead-letter subqueue to which messages are moved when they fail to be processed correctly.
There are Service Bus Queues, but there is also Azure Storage Queues. They basically do the same thing, but there are subtle differences between them. Table 3-1 looks at each of them.
Table 3-1: A comparison of features between Service Bus Queues and Storage Queues
Azure Service Bus Queues | Azure Storage Queues |
Message lifetime >7 days | Message lifetime <7days |
Guaranteed (first in–first out) ordered | Queue size >80 GB |
Duplicate detection | Transaction logs |
Message size ≤1 MB | Message size ≤64 KB |
In our world of ubiquitous software, data is being generated from many applications, devices, and locations, all the time. Today, it's becoming more common for enterprises to capture massive amounts of that data to analyze it or transform and move it for later use. Azure Event Hubs can help.
Event Hubs is designed for massive data ingestion. You can throw millions of messages per second at it, and it will handle that data for you effortlessly. It can retain messages for up to seven days, or retain them indefinitely by writing them to a data store using the Event Hubs Capture feature.
You can use Event Hubs to filter the data with queries, as it comes in, and output it to a data store like Azure Cosmos DB. You can even replay messages if you need to.
Just like Event Hubs, Azure IoT Hub is built for massive data ingestion. It is specifically geared toward handling the enormous volume of data messages from devices on the Internet of Things (IoT; refer to the sidebar in Chapter 1, "Who uses Azure?" for an example), like smart thermostats or sensors in cars. It has many of the same properties as Event Hubs, like the ability to retain messages for up to seven days and replay them.
What makes IoT Hub unique is that in addition to receiving messages from devices, it can send messages to them, as well. It has the ability to manage your complete IoT infrastructure. You can use IoT Hub to register devices and report their state, manage them by securing them and restarting them and sending data to devices.
Azure Event Grid, offers a different type of messaging. Event Grid offers a fully managed, publish/subscribe service that hooks into almost every service in Azure and can hook into custom publishers and subscribers.
This is different from working with the Service Bus Queues and Topics, for which you'd need to poll the Queue or Topics for new messages. Event Grids automatically pushes messages to subscribers, making it a real-time, reactive event service.
Services in and outside of Azure publish events (for example, when a new Blob is added or when a new user is added to an Azure subscription). Azure Event Grid can detect these events and make them available to event handlers and services that subscribed to the events (Figure 3-1). Event handlers can be things like Azure Functions or Azure Logics Apps, which can then act on the data in the event.
Figure 3-1: Azure Event Grid overview
Another important aspect of Event Grid is that it is serverless. This means that like Azure Logic Apps and Azure Functions, Event Grid scales automatically and doesn't need an instance of it being deployed. You just configure and use it. And, you pay only when it is used, not for it just being there.
Here's a usage example for the Azure Event Grid:
You want to be notified by email every time a user is added or deleted to your mailing list in MailChimp.
Azure Event Grid is used to activate an app in Azure Logic Apps and is configured to listen to changes to the MailChimp mailing list. The next step is to send an email containing the name of the user that has been added or deleted and the action that was performed (add or delete). Now, when a new user is added to the mailing list, Event Grid signals the Logic Apps, which sends an email.
Azure provides myriad options to do messaging and decouple applications. Which one should you use, and when? Table 3-2 sums up the differences to help you sort it out.
Table 3-2: When to use which Azure service for messages or events
| Event Grid | Event Hubs | IoT Hub | Topics | Service Bus Queues | Storage Queues |
Event ingestion | X | X | X |
|
|
|
Device management |
|
| X |
|
|
|
Messaging | X | X | X | X | X | X |
Multiple consumers | X | X | X | X |
|
|
Multiple senders | X | X | X | X | X | X |
Use for decoupling |
| X | X | X | X | X |
Use for publish/subscribe | X |
|
|
|
|
|
Max message size | 64 KB | 256 KB | 256 KB | 1 MB | 1 MB | 64 KB |