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 (https://docs.microsoft.com/en-us/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
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.