name

The service URL returned after creating our Principal Service

password

The password returned after creating our Principal Service

tenant

The tenant ID returned after creating our Principal Service

organization

project

webUrl

Discover how to design complex event-driven architectures in Azure, with insights into resource management, monitoring, and integrating VMs and databases for enterprise solutions.

Building Event Driven and Microservices Architecture in Azure.png

azure_microservices.tar.gz

run pwsh

run code

run code-cli

run code-cli-copy

Building a cloud infrastructure can be a challenging task. There are a lot of dependencies in your software and services like database, storage, and connections to log analytics that make it difficult.

In this course, you will learn how to easily design and build complex solutions based on the Event-Driven Architecture in the Azure Cloud. You will cover how to design, manage and monitor infrastructure. You will also learn how to select and combine resources like virtual machines and run books, databases, and application servers.

By the time you finish this course, you will be able to design and build complex architectures for enterprise-ready solutions based on Azure Cloud.

For the course, basic knowledge of Azure cloud or another cloud provider is needed.

Building Event Driven and Microservices Architecture in Azure

# Architecture
Let's begin by looking at the architecture diagram below.

## Event grid
An event grid is linked with a subscription listening to the events related to new virtual machine creation. It is necessary to add filtering here. Otherwise, the event grid will generate messages whenever any resource is created in a subscription or in the target resource group. All events are then delivered to the storage queue. 

## Queues
In the project above, we are using three queues:
- **Main queue** is a destination for all messages from the event grid.
- **Retry queue** receives all messages which failed during the first steps of validation and were scheduled for a future retry.
- **Succeeded queue** is used for all successfully processed messages. In this project, we have used this queue for statistics and reporting.

A storage account is also linked to Azure Log Analytics to synchronize all logs and alerts. For example, if the number of messages in the retry queue is more than the expected number, log analytics will log this as an error alert to the administrator.


## Function app
The next component is the Azure Function app that contains several Azure functions. These functions perform validation, process messages, and contain logic to trigger the runbook.

A __Validation Function__ is linked with the main event queue. When the Event Grid sends a message to the main queue, this function is automatically triggered.

A __Retry Function__ is based on a timer trigger and will run to check for failed messages which were in the retry event queue waiting to be sent again.

The Validation and Retry function workflow is demonstrated below.


Let's dive into the architecture using diagrams and Azure components workflow.

Introduction

Architecture

Building CI/CD

Conclusion

Building the Basic Structure

Architecture

Event grid