Microsoft Azure is a powerful cloud computing platform designed to make big businesses agile and infinitely scalable for a fraction of the cost.
While often overlooked, Azure is used by 90% of Fortune 500 companies to build low latency, high data-volume apps. Between Azure clients like Linkedin, News Corp, and Wikipedia, you probably use an Azure app at least once per day without knowing it. The secret to these popular apps lies in Azure’s microservices support, which allows apps to be both resilient and reactive.
Today, we’ll give you a quick introduction to Azure and its impressive microservices functionalities.
Here’s what we’ll cover today:
Learn to combine event-driven and microservice architectures in your own Azure applications.
Azure includes all the standard cloud services like Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), which each offer a different scale of cloud implementation to fit each company’s unique needs.
While relatively late to the cloud platform scene, Azure offers unique functionalities:
Lower pricing than AWS or GCP for larger companies or companies that already use Microsoft tools.
Supports deploying hybrid environments that mix on-premise, serverless, and cloud-native architectures.
Free live security updates that keep your data safe from new cyberattacks the moment they’re found.
Data centers across more regions than any other provider including areas like Africa and Oceania that are underserved by other providers.
Charged per virtual machine (VMs), not monthly. This allows you to scale up to match larger workloads on the fly without service stoppages.
Extensive API gateways to let Azure easily interface with existing front-end and back-end systems.
These factors combine to make Azure a great cloud platform choice for existing mid to large-scale companies looking to get the most out of their cloud service and embrace modern DevOps techniques.
One way companies can get the most out of their cloud is to design web applications with event-driven architecture (EDA).
An event-driven architecture uses events to trigger and communicate between decoupled services. Components send events anytime a state is updated within their scope such as a user adding an item to their cart or posting a comment on a post.
This structure makes each component responsible for notifying other areas of the system about state changes. Event-driven architecture is the opposite of traditional request-driven architecture, in which the state of a component is only revealed when another component asks for its current state.
Event-driven architecture is common in systems built with microservices. Microservices architecture is a way to break down an application into separate, independent components that make it easier to maintain and scale.
In Azure, you can either use Microsoft’s Azure Service Fabric or the open-source Azure Kubernetes Service (AKS) for building microservice applications as well as handling deployment lifecycle and container orchestration.
Event-driven architecture synergizes with a microservice architecture to further increase scalability because it allows the separate components to communicate reactively regardless of their size or separation.
Some benefits of an event-driven architecture over traditional monolithic applications are as follows:
Agility: Event-driven architecture allows your application to react in real-time to changes in the market or new feature reception.
System awareness: Because events are logged as they happen, the entire application has an up-to-date reference for its current status via IoT devices.
Scalability: Event-driven systems have event producers and event consumers. You can add more of either type at any time to increase scale without reworking any of the structures.
Predictive decisions: Event-driven applications can be combined with machine learning technology to analyze events as they come in to produce real-time trend predictions.
Event-driven architecture is becoming a popular design pattern because of how perfectly it meets modern needs. However, it can be difficult to get an event-driven system started because all event-handling systems must be built upfront. It’s best to only use event-driven architecture when its unique strengths fit the product’s design.
Use event-driven architectures when:
Multiple subsystems or services will process the same event.
Your application features low latency real-time updates such as a weather or streaming app.
You need complex event processing like pattern matching or delayed responses.
Your application will handle big data or quickly changing data flows.
Become an Azure cloud engineer in half the time. Educative’s text-based courses feature live coding environments and real-life projects to give you the hands-on knowledge you’ll need to get hired.
In Azure, event-driven systems are best implemented with three components: an event grid (EG), one or more FIFO queue, and a collection of Azure Functions
The event grid is the primary event processor and essentially acts as a post office that intakes, evaluates, manipulates, and redistributes any events traveling from event producer to handler. Event grids have a few major parts:
Event Producers that generate events
Topics or EndPoints, which acts as a path from producers to the Event grid.
The Grid that filter and distribute events as an intermediary between producers and handlers.
Subscriptions that act as a path from the Grid to handlers.
Event handlers that react to the event.
Event grids can be configured very differently based on what type/frequency of event should be allowed through. All event grids will at least have a dead-letter queue and some kind of event filter.
The dead-letter queue is a FIFO queue data structure that stores the events which did not successfully reach their handler . Once stored, the events can be resent and analyzed by developers to find possible bugs.
The event filter is a set of criteria that the Topic uses to decide which events move on to their handler and which will be blocked. It can also manipulate the event to a different type if the desired handler can only handle certain types.
If an event filter is working correctly, only actionable and applicable events will be delivered to a particular handler.
Building applications with EDAs in Azure is a great way to learn the platform. To tackle this project yourself, you’ll need to complete the following 4 steps.
1. Set up an Azure Account
You’ll need an Azure account to create an Azure environment and create a DevOps project workspace to practice in. You can get a free trial of Azure on Microsoft’s official site.
2. Build the foundational structure
Next, you’ll need to create resource groups, an automation account, and a database.
Resource groups are containers that we can use to gather all our resources in one place. They allow you to organize how resources are managed and grouped based on your needs.
Azure accounts act as containers for your source files. Automations are a container for all your runbook, runbook executions (jobs), and the assets that your runbooks depend on.
A runbook is a collection of routine operations that help you evaluate the system.
Finally, you can create a database using the Azure-supported mySQL database software. Once you install
Az.mySQL, you can enter
New-AzMySqlServer into your command-line or PowerShell to initialize the server.
3. Create Event Storage
Your application needs a way to store the events it can’t complete right away. Queues are a great option because they store events in the order they’re received and ensure events aren’t skipped.
A 3 queue system is very effective for event-driven applications:
The Main Queue, which receives all events
The Retry Queue, which takes failed events from the Main Queue and schedules them for future reentry.
The Succeeded Queue, which stores a record of all successfully processed events for statistics and reporting purposes.
4. Add Azure functions
These functions act as an intermediary between your runbook and Event Grid. They also perform event validation and process messages.
You’ll at least need the following:
Validation Function that is triggered when the Event Grid sends a message to the Main Queue.
Retry Function which triggers periodically to requeue any failed events from the Retry Queue back into the Main Queue.
A RESTful API Function that works on an HTTP trigger and can run the entire process from runbook or Admin UI.
This is just the first step on your journey to learn Azure. While tricky to get started, learning Azure will set you up for success when you learn other cloud platforms.
As you continue your journey, check out these intermediate topics:
To help you take these next steps in your Azure journey, Educative has created Building Event-Driven and Microservices Architecture in Azure. This course starts off with an in-depth exploration of event-driven architecture and Azure tools available to build your microservice systems.
By the end, you’ll have hands experience building multiple Azure web apps and have the skills to set up your own CI/CD solutions.
Join a community of more than 1 million readers. A free, bi-monthly email with a roundup of Educative's top articles and coding tips.