Adding intelligence to your application

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?

Azure Search

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:

• Geo-search that gives users the ability to explore data based on the proximity of a search result to a physical location.
• Language analyzers from Lucene as well as Microsoft's natural language processors (NLPs), available in 56 languages to intelligently handle language-specific linguistics, including verb tenses, gender, irregular plural nouns (for example, "mouse" versus "mice"), word de-compounding, word-breaking (for languages with no spaces), and more.
• Monitoring and reporting that inform you as to what was searched for and how fast and successful the search was.
• User experience features like sorting and paging search results and intelligent filtering, and providing search suggestions.

You could implement Azure Search to help users search your product catalogue in an e-commerce application.

Azure Cognitive Services

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:

• Using the Face API, you can perform facial recognition and identification and can even determine the color of a person's eyes, even if that person is wearing glasses.
• The Emotion API determine which emotions an individual is showing in a picture.
• The Language Understanding Intelligent Services API (or LUIS) can actually understand text, based on the model you use to train it.
• The Translator Speech API turns speech into text and translates it for you in real time

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.

Azure Bot Service

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:

• It helps you to keep track of the interaction context and provides you with templates to get started from the Bot Framework.
• It has tight integrations with Cognitive Services, making it easier to make your bot "smart."
• It helps you to integrate with services like Facebook, Slack, Microsoft Teams, Telegram, and so on.
• It offers all the benefits of a managed service in Azure: massive scale, built-in Continuous Delivery (CD), and you pay only for what you use.

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.

Using events and messages in your application

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.

Azure Service Bus

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.

Azure Service Bus Queues

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.

Azure Service Bus Topics

Just like Service Bus Queues, Azure Service Bus Topics are a form of application decoupling. Here's the differences between the queue and topics:

• With a queue, multiple applications write messages to the queue, but only one application at a time can process a message.
• With a topic, multiple applications write messages to the topic, and multiple applications can process a message at the same time.

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.

Comparing Service Bus Queues and Azure Storage Queues

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 Event Hubs

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.

Azure IoT Hub

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

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.

What to use when?

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