Book Image

The Azure Cloud Native Architecture Mapbook

By : Stéphane Eyskens, Ed Price
Book Image

The Azure Cloud Native Architecture Mapbook

By: Stéphane Eyskens, Ed Price

Overview of this book

Azure offers a wide range of services that enable a million ways to architect your solutions. Complete with original maps and expert analysis, this book will help you to explore Azure and choose the best solutions for your unique requirements. Starting with the key aspects of architecture, this book shows you how to map different architectural perspectives and covers a variety of use cases for each architectural discipline. You'll get acquainted with the basic cloud vocabulary and learn which strategic aspects to consider for a successful cloud journey. As you advance through the chapters, you'll understand technical considerations from the perspective of a solutions architect. You'll then explore infrastructure aspects, such as network, disaster recovery, and high availability, and leverage Infrastructure as Code (IaC) through ARM templates, Bicep, and Terraform. The book also guides you through cloud design patterns, distributed architecture, and ecosystem solutions, such as Dapr, from an application architect's perspective. You'll work with both traditional (ETL and OLAP) and modern data practices (big data and advanced analytics) in the cloud and finally get to grips with cloud native security. By the end of this book, you'll have picked up best practices and more rounded knowledge of the different architectural perspectives.
Table of Contents (13 chapters)
Section 1: Solution and Infrastructure
Section 2: Application Development, Data, and Security
Section 3: Summary

Introducing Azure architecture maps

Although we have already presented a small map, let's explain how Azure architecture maps were born and how to make sense of them. However rich the official Microsoft documentation might be, most of it is textual and straight to the point, with walk-throughs and some reference architectures. While this type of information is necessary, it is quite hard to grasp the broader picture. An exception to this is the Azure Machine Learning Algorithm Cheat Sheet (, which depicts, in a concise way, the different algorithms and their associated use cases. Unfortunately, Microsoft did not create cheat sheets for everything, nor is there any other real visual representation of the impressive Azure service catalog and its ecosystem. That gap leaves room for some creativity on the matter…and that is how Azure architecture maps were born. The primary purpose of Azure architecture maps is to help architects find their way in Azure, and to grasp, in the blink of an eye, the following:

  • Available services and components: Since there are so many services and products out there, our primary purpose is to classify them and associate them with the most common customer concerns and use cases. However, keep in mind that Azure is a moving target! We will try to be as comprehensive as possible, but we can never guarantee exhaustive or complete coverage. It simply isn't possible.
  • Possible solutions: These architecture maps are like a tree with multiple branches and sub-branches, and finally the branches end with flourishing leaves. On many occasions, there are multiple ways to tackle a single situation. That is why we will map alternative use cases, based on real-world experiences. However, we strongly encourage you to form your own opinion. You need to exercise your critical reflection on every topic, as to not blindly apply the map recommendations. The unique particularities of your own use case will often require a different solution (or at least a modified solution).
  • Sensitivity and trade-off points: Architecting a solution is sometimes about choosing the lesser of two evils. Some of your choices or non-functional requirements might affect your final solution, or they might lead you to face some additional challenges. We will highlight sensitive trade-off points with specific marks on the maps.

Given the size of the Azure service catalog, a single map would not suffice. Hence, we created specialized maps. They are not restricted to Microsoft services and, when applicable, may also refer to marketplace and third-party solutions. Let's jump to the next section, which explains how to read and make sense of the maps.

How to read a map

The maps proposed in this book will be your Azure compass. It is therefore important to understand the fundamentals of how to read them. We will therefore go through a sample map to explain the semantics and its workings. Figure 1.10 presents a very tiny, sample map:

Figure 1.10 – A sample map

Figure 1.10 – A sample map

The central point that the diagram depicts is the Master Domain (MD), the central topic of the map. Each branch represents a different area belonging to the MD. Under the sub domains, you can find the different concerns. Directly underneath the concerns, the different options (the tree's leaves) might help you address the concerns (see POSSIBLE OPTION in Figure 1.10). There might be more than one option to address for a given concern. For example, CONCERN 2 in the diagram offers two options: ALTERNATIVE 1 and ALTERNATIVE 2.

From time to time, dotted connections are established between concerns or options that belong to different areas, which indicates a close relationship. In the preceding example, we see that the ALTERNATIVE 2 option connects down to the SUB DOMAIN 2 concern. To give a concrete example of such a connection, we might find a Dapr leaf under the microservice architecture concern that is connected (by a dotted line) to a Logic Apps leaf under the integration concern. The rationale of this connection is because Dapr has a wrapper for self-hosted Logic Apps workflows. Let's now see how, as an architect, you can get started with your cloud journey.