Azure Architecture Styles

Introduction

Architecture style refers to grouping of architectures based on common characteristics, problems they address or constraints. This is the highest level of abstraction while building an architecture for an application. The architectural effort should start by choosing an effective architectural style and then decide on a design pattern and other aspects.

Architecture Style may consist of the below components,

Core Components like Compute or Storage that address business concerns
Integration Components like API Services or Messaging Queues that address integration concerns
Network Components like Load Balancers, VPN that enables all communication between components.
Security Components that address security concerns
Conditions and Criteria that aggregate all components to form a system.
Rules and Constraints that define the property of the system

Architecture Styles are applicable to software systems being designed on Azure. Microsoft has identified Architecture Styles applicable to Azure solutions. Microsoft has come up with these Architecture Styles based on the below,

Application System Description and Logical diagram
When to use and concerns it addresses
Best Practices, Benefits and Constraints
Deployment Style followed

In this article we will have a look at different Azure Architecture Styles at a very high level.

N-Tier Architecture Style

This is one of the commonly followed architectural styles and has been there for ages. The application is divided into layers, each layer having a specific concern to address. The most common layers designed are a Presentation layer that addresses user Interface concerns, Business Layer that address Business concerns and Data Layer that interacts with database and supplies data to business layer. Presentation layer can interact with Business layer and Business layer interacts with Data Layer. However, there is a very tight dependency among different layers.

This style is mostly seen in Infrastructure as a Service solutions as any layered application can easily be migrated to the cloud using Infrastructure as a Service approach.

The below figure depicts a n-tier application where each layer is deployed in load balanced Azure Virtual Machines. Virtual Machine Scale Sets are the best fit here for each of these layers. There is a DMZ server that acts as interface between public interface traffic and Azure Virtual Machines on Azure Virtual Network that is not public.

Microservices Architecture Style

Here the entire application is divided into autonomous, self-contained services. Each of these services address a single business concern. The services are loosely coupled and can be developed independently. The services are deployed as independent unit and they scale independently. Each of these services persist their own data and communicate with each other using well defined API endpoints.

Each of these services are hosted in a container or a Virtual Machine called as node. Concerns like high availability, deployment and scalability for each of these nodes should be handled by an Orchestrator that can manage these nodes. Azure Service Fabric or Azure Kubernetes Services can be used to build applications that use this architecture style.

Event Driven Architecture Style

These are pub-sub (publisher-subscriber) pattern where the publisher publishes event and the intended subscriber consumes the event. This architecture style comes in handy when each subscriber processes the event data differently. This style is also commonly used to decouple different systems that handle tons of data where a publishing system emits tons of data for a subscribing system to process. This decoupling addresses the scalability concern that would have been there if the systems would not have followed pub-sub model thus leading to a performance bottle neck.

Below represents Event Driven Architecture Style. Event Publisher ingests event data to Ingestion Hub that can be an Azure Event Hub or Azure IOT Hub. Event Data is filtered per the Subscription Filters applied and are consumed by the respective Event Subscribers.

Big Data Architecture Style

This Architecture Style handles ingesting, storing, managing and analyzing very huge and complex data that are difficult for traditional data systems to handle. Data handled by this system can the data at rest or can be data that is ingested real time. Predictive Analytics and Machine Learning are easily handled with systems implementing this kind of Architectural style.

Data can come from real time sources like IOT devices or traditional applications. Data at rest is usually stored in Azure Data Lake that is capable of handling such a large amount of data. Batch processing of the data is done either using Azure HD Insights or Azure Data Lake Analytics job. Real time data is usually ingested using Azure IOT Hub or Azure Event Hub. Stream Data Processing is done using Azure Stream Analytics. Azure HD Insights can be used as Analytical Data Store from where Analytics tool can access analytics ready data and process it. All these data processing operations can be handled using an orchestrator like Azure Data Factory and Azure Data Bricks.

Big Compute Architecture Style

This Architecture Style helps in processing work loads that need huge compute power like operations that requires multiple cores and huge memory. These applications are usually compute intensive and memory intensive and should be processed in parallel. These applications are also referred to as High-Performance Computes. Azure Batch Service is the best way to handle such scenarios. The tasks are scheduled on worker Virtual Machines in batches using a task scheduler. The task scheduler monitors, manages and aggregates the tasks running on the workers in parallel.

Web-Queue-Worker

This Architecture Style is a perfect example of modern Platform as a Service Solution. This style usually involves a public facing application that can be hosted on Azure Web App. The Web App can push long running, time intensive tasks to Azure Storage Queue or Azure Service Bus Queue. A worker that can be an Azure Function can pick items from the Queue and process it. Azure Function can get data from a Platform as a Service database like Azure Cosmos DB for the first time and keep a copy of the data in a cache like Azure Redis Cache for subsequent access. Such systems are highly scalable and are true cloud-based platform as a service application.

Winding Up

Here in this article we explored different Azure Architecture styles that can be leveraged to build cloud-based applications on Azure. All Azure based applications design should start by adopting one of these architecture styles.