Enterprise architects

Enterprise architects oversee the IT and business strategies, and they make sure that every IT initiative is in line with the enterprise business goals. They are directly reporting to the IT leadership and are sometimes scattered across business lines. They are also the guardians of building coherent and consistent overall IT landscapes for their respective companies. Given their broad role, enterprise architects have a helicopter view of the IT landscape, and they are not directly dealing with deep-dive technical topics, nor are they looking in detail at specific solutions or platforms, such as Azure, unless a company would put all its assets in Azure. In terms of methodology, they often rely on the TOGAF (short for The Open Group Architecture Framework) framework and ArchiMate for modeling. The typical type of diagrams they deal with looks like the following:

As you can see, this is very high level and not directly related to any technology or platform. Therefore, this book focusing on Azure is not intended for enterprise architects, but they are, of course, still welcome to read it!

Domain architects

Domain architects own a single domain, such as The Cloud. In this case, the cloud is broader than just Azure, as it would probably encompass both public and private cloud providers as well as SaaS (Software as a Service) solutions. Domain architects are tech-savvy, and they define their domain roadmaps while supervising domain-related initiatives. Compared to enterprise architects, their scope is more limited, but it is still too broad to master the bits and bytes of an entire domain. This book, and more particularly our generic maps, will certainly be of great interest for cloud domain architects. Diagram-wise, the domain architects will also rely on TOGAF and other architecture frameworks, but scoped to their domain.

Solution architects

Solution architects help different teams build solutions. They have T-shaped skills, which means that they are specialists in a given field (the base of the T), but they can also collaborate across disciplines with the other experts (the top of the T). Solution architects are usually in charge of designing solution diagrams, and they tackle non-functional requirements, such as security, performance, and scalability. Solution architects may build both high-level, technology-agnostic diagrams, referred to as ABBs (Application Building Blocks), and more concrete implementations of ABBs, called SBBs (Solution Building Blocks). Azure solution architects typically focus more specifically on SBBs. While the concepts of ABBs and SBBs are borrowed from TOGAF, one might attempt an analogy with the C4 model where ABBs roughly correspond to C4's System Diagrams and SBBs to C4's Container Diagram. Figure 1.2 is an example of C4 System Diagram that could be seen as an ABB:

Figure 1.2 depicts a high-level view of a hybrid API pattern where on-premises clients reach out to Cloud-hosted APIs. It shows the different systems involved in this scenario but there is no information about the involved technologies. Conversely, Figure 1.3 gives much more details about what a concrete implementation would look like:

From this diagram, we identify several Azure building blocks, including Virtual Networks, Azure Firewall, and Azure API Management. Entra ID is used as the authorization server. Azure Solution Architects will be primarily interested in our next chapter, Solution Architecture.

Data architects

Data architects oversee the entire data landscape. They mostly focus on designing data platforms, for storage, insights, and advanced analytics. They deal with data modeling, data quality, and business intelligence, which consists of extracting valuable insights from the data, in order to realize substantial business benefits. A well-organized data architecture should ultimately deliver the DIKW (Data, Information, Knowledge, Wisdom) pyramid as shown in Figure 1.4:

Organizations have a lot of data, from which they try to extract valuable information, knowledge, and gain wisdom over time. The more you climb the pyramid, the higher the value. Consider the following scenario to understand the DIKW pyramid:

Figure 1.5 shows that we start with raw data, which does not really make sense without context. These are just numbers. At the information stage, we understand that 31 stands for the day, 3 as the month of March, and 3,000 as the number of visits. Now, these numbers mean something. The knowledge block is self-explanatory. We have analyzed our data and noticed that year after year, March 31 is a busy day. Thanks to this valuable insight, we can take the wise decision to restock our warehouses up front to make sure we do not run short on goods.Data Architects are also responsible for developing reference architectures that support a variety of data processing needs, including file-based batch ingestion, real-time streaming, Internet of Things (IoT) data flows, and both ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) pipelines. Their role extends beyond technical design, as they also guide how modern technologies like Artificial Intelligence (AI) can be strategically leveraged to gain deeper business insights, enhance decision-making capabilities, and foster a data-driven culture throughout the organization. Figure 1.6 is an example of IoT diagram a data architect might build:

Figure 1.6 illustrates the flow of data from sensors within an industrial network, passing through an IT network via Azure IoT Edge, and ultimately reaching Azure IoT Hub. From there, the data ingestion process begins, enabling further analysis.That is, among other things, the work of a data architect to help organizations learn from their data.Data is the new gold rush, and Azure, as well as Microsoft Fabric have a ton of data and AI services as part of their catalog, which we will cover in Chapter 7, Architecting Data Solutions as well as in Chapter 8, Artificial Intelligence Architecture

Technical architects

Technical architects have a deep vertical knowledge of a platform or technology stack, and they have hands-on practical experience. They usually coach developers, IT professionals, and DevOps engineers in the day-to-day implementation of a solution. They contribute to reference architectures by zooming inside some of the high-level components. They often act as a liaison between solution architects and engineers. For instance, if a reference architecture, designed by a solution architect, makes use of Azure Kubernetes Services (AKS), the technical architect might zoom inside the AKS cluster, to bring extra information on the cluster internals and some specific technologies. To illustrate this, Figure 1.7 shows a sequence from a high-level diagram a solution architect might have created:

Figure 1.8 shows the corresponding blueprint created by the technical architect:

Figure 1.8 contains precise technologies, such as KEDA (Kubernetes-based Event Driven Autoscaling), and some Azure components such as Virtual Networks, Azure Kubernetes Service, and Azure Blob Storage.Technical architects will mostly be interested in our detailed maps and our different use cases distributed throughout the book.

Security architects

In this hyper-connected world, security has become a top priority for every organization.. Security architects have a vertical knowledge of the security field. They usually deal with regulatory or in-house compliance requirements. The cloud and, more particularly, the public cloud, often emphasizes security concerns (much more than for equivalent on-premises systems and applications). With regard to diagrams, security architects will add a security view (or request one) to the reference solution architectures, such as the following:

In Figure 1.9, the focus is set on pure security concerns: encryption in transit (TLS 1.3) between the browser and the WAF (Web Application Firewall). The WAF ensures minimal protection against the well-known OWASP (Open Web Application Security Project) vulnerabilities. The virtual network is divided into multiple subnets to clearly identify the different layers of the solution and be able to define Network Security Group rules for every subnet. The security-minded person in you, will immediately spot a transition from TLS 1.3 to TLS 1.2, which is due to the fact that, at the time of writing this book, API Management is not yet compatible with TLS 1.3. The API gateway acts as a PEP (Policy Enforcement Point) before it forwards the request to the backend service. The backend authenticates to the database using MSI (Managed Service Identity), and the database is encrypted at REST with customer-managed keys. Azure Key Vault is used to store the key and must allow trusted services access in the public firewall. Figure 1.9 effectively integrates three key dimensions—Networking, Identity, and Encryption—highlighting the primary areas of focus for security architects.Security architects not only evaluate various solutions but also play a key role in strengthening the organization's overall security posture. They will assess Azure and container-based solutions using frameworks like MITRE ATT&CK, oversee SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and penetration testing, and ensure seamless integration with SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation and Response) systems, among other things.However, as we will explore further in Chapter 9, Security Architecture, mastering cloud and cloud-native security is a tough challenge for a traditional (on-premises) security architect. Cloud native's defense in depth primarily relies on identity, while traditional defense in depth heavily relies on the network perimeter. Over the past years, Azure has also evolved towards a more perimeter-centric approach. Nevertheless, there still exists gaps between the cloud and non-cloud worlds.

Infrastructure architects

Infrastructure architects focus on building IT systems that host applications, or systems that are sometimes shared across workloads. They play a prominent role in setting up hybrid infrastructures, which bridge both the cloud and the on-premises world. Their diagrams reflect an infrastructure-only view, often related to the concept of a landing zone, which consists of defining how and where business assets will be hosted. A typical infrastructure diagram that comes to mind for a hybrid setup is the Hub and Spoke architecture (https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke):

Figure 1.10 is a simplified view of the hub and spoke, which, in reality, is often much more complex than this. Infrastructure architects are also involved in topics such as backup/restore, disaster recovery, and so on, which we will explore this further in Chapter 3, Infrastructure Design. We will also stress some important aspects related to legacy processes, so as to maximize the chances of a successful cloud journey.

Platform architects

Platform architects have become increasingly important in recent years, playing a key role in building cloud platforms. Beyond managing infrastructure, they specialize in designing efficient, fully CI/CD-driven platforms that empower application teams to accelerate development and deployment. Their growing importance coincides with the rise of container orchestration platforms that bring new challenges and an entirely new mindset nurtured by DevOps and GitOps practices. Platform architects can be seen as Infrastructure architects 2.0, who have already totally embraced cloud native practices and automation in their daily routine. They often have a mixed background, allowing them to bridge the traditional silos which are infrastructure and application teams.

Application architects

Application architects focus on building features that are requested by the business. Unlike other architects, they are not primarily concerned by non-functional requirements. Their role is to enforce industry best practices and coding design patterns to build maintainable and readable applications. Their primary focus is on code quality and the adherence to well-known principles, such as SOLID (https://en.wikipedia.org/wiki/SOLID), DRY (Don't Repeat Yourself) and Clean Code. With regard to Azure, their primary concerns are to integrate with the various Azure services and SDKs, as well as leverage cloud and cloud-native patterns that help them support their business case. Beyond this book, a good source of information for them is the Microsoft documentation on cloud design patterns (https://docs.microsoft.com/en-us/azure/architecture/patterns/).The main challenge for application architects is to correctly understand the broader Azure ecosystem. Today, there is a clear shift toward breaking down monolithic architectures. This involves decomposing systems into multiple decoupled components, resulting in highly distributed architectures. In modern applications, many common responsibilities are offloaded to specialized services— which are mainstream in the cloud but often unfamiliar to traditional application architects. For example, API gateways come with built-in policies for API throttling, token validation, and caching, eliminating the need for custom implementations. Message brokers such as Azure Service Bus, have built-in features such as entity forwarding, sessions, etc. which would be a pain to implement in code. Application architects should familiarize themselves with the extensive capabilities offered by the Azure service catalog, which is not an easy task. Another key consideration for application architects is the cloud's horizontal scaling model, which requires applications and services to be multi-instance aware—an aspect rarely addressed in monolithic designs, often still prevailing in on-premises data centers.We will explore cloud native practices further in Chapter 6, Application Architecture.

Azure architects

From the top to the bottom of our enumeration, the IT landscape shrinks, from the broadest to the narrowest scope. It would be very surprising to ever meet an Azure enterprise architect. Similarly, it is unlikely that we will stumble upon an Azure domain architect, since the parent domain would rather be - the cloud - which is much broader than just Azure.However, it makes sense to have Azure-focused solution architects, technical architects, and data architects, because they get closer to the actual implementation of a solution or platform. Ideally, Azure architects should be subject matter experts in all architectural disciplines depicted earlier, as well as in all service models described in the following sections.

Architects versus engineers

Before we move on, we need to address the engineer that we all have inside of us! What differentiates architects from engineers is probably the fact that most architects have to deal with the non-functional requirements piece. In contrast, engineers, such as developers and IT engineers, are focused on delivering and maintaining the features and systems requested by the business, which makes them very close to the final solution. While this book primarily focuses on architecture, it also aims to provide value to engineers by featuring in-depth technical explanations.Now that we are familiar with the different architect roles, it is time to get started with the different service models and acquire the essential vocabulary that every Azure architect should know.

Cloud service models map

Figure 1.11 is a sample map, which depicts the different cloud service models and introduces some vocabulary. This map features two additional dimensions (costs and ops) to each service model, as well as some typical use cases:

In terms of cost models, we see two big trends: consumption and pre-paid compute/plans. The consumption billing model is based on the actual consumption of dynamically allocated resources. Pre-paid plans allocate compute capacity at all times, independent of the actual resource consumption. In terms of operations, the map highlights what is done by the cloud provider, and what you still have to do yourself. For instance, very low means that you have almost nothing to do yourself. We will now walk through each service model.

IaaS (Infrastructure as a Service)

IaaS (Infrastructure as a Service) is probably the least disruptive model. It is basically the process of renting a data center from a cloud provider. It is business as usual (the most common scenario) in the cloud. IaaS is not the service model of choice to accomplish a digital transformation, but there are a number of scenarios that we can tackle with IaaS:

• The lift-and-shift of existing workloads to the cloud.
• IaaS is a good alternative for smaller companies that do not want to invest in their own data center.
• In the context of a disaster recovery strategy, when adding a cloud-based data center to your existing on-premises servers.
• When you are short on compute in your own data center(s).
• When launching a new geography (for which you do not already have a data center), and to inherit the cloud provider's compatibility with local regulations.
• To speed up the time to market a little, by optimizing some legacy practices and processes to align with the cloud delivery model.
• By leveraging Infrastructure as Code to automate most deployments.

With regard to costs and operations, they are almost equivalent to on-premises, although it is very hard to compare the total cost of ownership (TCO) of IaaS versus on-premises.Of course, facilities, physical access to the data center, among other things, are all managed by the cloud provider. It is no longer necessary to buy and manage the hardware and infrastructure software by yourself. Many companies today have a hybrid strategy, which consists of keeping a certain number of assets on-premises, while gradually expanding their cloud footprint. In this context, IaaS is often required to bridge the on-premises and cloud worlds.

PaaS (Platform as a Service)

PaaS (Platform as a Service) is a fully managed service model that helps you build new solutions or refactor existing ones much faster. PaaS features off-the-shelves services that already come with built-in functionalities and whose underlying infrastructure is fully outsourced to the cloud provider. PaaS is quite disruptive with regard to legacy systems and practices.Because PaaS is very different from traditional IT, it demands strong engagement across all levels of the organization and the backing of a top executive sponsor to ensure the necessary mindset shift occurs.Make no mistake: going to the Cloud is a journey, especially when adopting Cloud native service models. With PaaS, much of the infrastructure and most operations are delegated to the cloud provider. The multi-tenant offerings are cost-friendly, and you can easily leverage the economies of scale, provided you adopt it for what it is. PaaS is suitable for many scenarios:

• Green-field projects
• Internet-facing workloads
• The modernization of existing workloads
• API-driven architectures
• IoT and AI workloads
• A mobile-first user experience
• An anytime-anywhere scenario, and on any device

The preceding list of use cases is by far not exhaustive, but it should give you an idea of what this service model's value proposition is.

FaaS (Function as a Service)

FaaS (Function as a Service) is also known as serverless. It all started with stateless functions that were executed on shared multi-tenant infrastructures. Nowadays, FaaS expanded far beyond functions, and is the most elastic flavor of cloud computing. While the infrastructure is also completely outsourced to the cloud provider, the associated costs are calculated based on the actual resource consumption (unlike PaaS, where the cloud consumer pre-pays a monthly fee based on a pricing tier). From a cost perspective, FaaS is ideal for non-sustained workloads, meaning workloads that frequently idle throughout the day. If the workload remains consistently active without idle periods, FaaS can become more expensive than pre-paid PaaS plans. FaaS is ideal in numerous scenarios:

• Event-driven architectures: Receive event notifications and trigger activities accordingly. For example, having an Azure function being triggered by the arrival of a blob on Azure Blob Storage, parsing it, and notifying other processes about the current status of activities.
• Messaging: Azure Functions, Logic Apps, and even Event Grid can all be hooked to Azure Service Bus, handle upcoming messages, and, in turn, push their outcomes back to the bus.
• Batch jobs: You might trigger Azure Logic Apps or scheduled Azure Functions to perform some jobs.
• Asynchronous scenarios of all kinds: Performing activities by leveraging the Fan-Out/Fan-In pattern is a good example.
• Unpredictable system resource growth: When you do not know in advance what the usage of your application is, but you do not want to invest too much in the underlying infrastructure, FaaS may help absorb this sudden resource growth in a cost-friendly fashion.

Some services are solely based on the FaaS service model but many PaaS services have an equivalent serverless pricing tier that allows cloud consumers to focus on building their applications while benefiting from elastic scaling in a cost-friendly way. While FaaS offers elasticity, it is best suited for workloads that can tolerate moderate latency and temporary capacity reductions. In recent years, Azure has experienced significant capacity constraints across multiple regions, affecting all compute models—though FaaS has been particularly impacted. Additionally, although FaaS is an outstanding service model, it is often shunned by large enterprises because of a reduced control over the security perimeter. FaaS is an even more disruptive service model than PaaS towards traditional IT and security practices, which may slow down its adoption in large companies.

CaaS (Containers as a Service)

CaaS (Containers as a Service) is between PaaS and IaaS. Containerization has become the new normal, and cloud providers could not miss that train. CaaS often involves more operations than PaaS. For example, AKS (Azure Kubernetes Service) and ARO (Azure Red Hat OpenShift) involve frequent upgrades of the Kubernetes version on both the control plane and the worker nodes, although recent versions feature an auto-upgrade mechanism.The operational workload increases even more when sharing a cluster among multiple applications, as it involves resource sharing, cost reporting, and dealing with challenges such as noisy neighbors, network isolation, and more. Moreover, it is not uncommon to see solutions built around services such as MongoDB or RabbitMQ, also hosted within the cluster, requiring mechanisms for backup, replication, resilience, etc., whereas services like Azure Service Bus and Cosmos DB natively include these features. Working with services such as AKS and ARO is like opening Pandora's box as the CNCF (Cloud Native Computing Foundation) ecosystem is vast and complex. Here is a pointer to the CNCF landscape: https://landscape.cncf.io/. On the other hand, services such as Web App for Containers, ACA (Azure Container Apps) and Azure Container Instances (ACI) are fully managed by Microsoft and tend to reduce the level of complexity. ACI even sits between serverless (the consumption-pricing model) and CaaS. Admittedly, CaaS is probably the hardest model when it comes to evaluating both costs and the level of operations because it varies according to how you use them. It is, nevertheless, suitable for the following scenarios:

• Lift-and-shift: During a transition to the cloud, a company might want to simply lift and shift its assets, which means migrating them as containers. Most assets can be packaged as containers without the need to refactor them entirely.
• Cloud-native workloads: Building modular, stateless and resilient solutions by leveraging Kubernetes and its broad ecosystem.
• Portability: CaaS offers a greater portability, and helps to reduce the vendor lock-in risk to some extent.
• Microservices: Most microservice architectures rely on service meshes, which are mainstream in the world of container orchestrators. We will cover them in Chapter 4, Working with Azure Kubernetes Service.
• Modern deployment: CaaS uses modern deployment techniques, such as A/B testing, canary releases, and blue-green deployment. These techniques prevent and reduce downtime in general, through self-healing orchestrated containers.
• Event-driven applications: CNCF solutions such as KEDA enable intelligent scaling of workloads based on system and custom events, optimizing compute resource utilization. This, combined with the agility, robustness of container orchestrators, make CaaS a first-class citizen for any event-driven architecture.

Additionally, ACI is great for running isolated, short-lived batch jobs without the overhead of a full Kubernetes cluster.We will explore the CaaS world in Chapter 2, Solution Architecture, AKS (Azure Kubernetes Services) in Chapter 4, Working with Azure Kubernetes Service and in Chapter 5, Other Azure Container Services

DBaaS (database as a service)

DBaaS (database as a service) is a fully managed service model that exposes storage capabilities. Data stores, such as Azure SQL, Cosmos DB, Azure MySQL, etc., significantly reduce operations, while offering strong high availability and disaster recovery options. Other services, such as Databricks, Data Factory, and Synapse do not strictly belong to the DBaaS category, but we will combine them for the sake of simplicity. Azure DBaaS was initially based on pre-paid resource allocation, but Microsoft introduced the serverless model in order to have more elastic databases. DBaaS brings the following benefits:

• A reduced number of operations, since backups are automatically taken by the cloud provider, while remaining configurable.
• Fast processing with Table Storage
• Advanced replication mechanisms, thanks to built-in zonal and regional redundancy.
• Potentially infinite scalability with Cosmos DB, provided proper engineering practices were taken up front
• Cost optimization, when the pricing model is well chosen and fits the scenario

We will explore DBaaS in Chapter 6, Data Architecture.

XaaS or *aaS (anything as a service)

Other service models exist, such as Model as a Service (MaaS) and Identity as a Service (IDaaS), to such an extent that the acronym XaaS, or *aaS, was born around 2016, to designate all the possible service models. It is important for an Azure architect to grasp these different models, as they serve different purposes, require different skills, and directly impact the cloud journey of a company.

Important note

We do not cover SaaS in this book. SaaS is a fully managed business suite of software that often relies on a cloud platform for its underlying infrastructure. SaaS examples include Salesforce and Adobe Creative Cloud, as well as Microsoft's own Office 365, Power BI, and Dynamics 365 (among others).

Now that we reviewed the most important service models, let's dive a little more into the rationale behind our 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.12 presents a very tiny, sample map:

The central point that the diagram depicts is the Master Domain (MD), which is 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.12). 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 (Distributed Application Runtime) 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, how you can get started with your cloud journey.

Defining the vision with the right stakeholders

Write a vision paper to identify what you are trying to solve with the cloud. Here are a few example questions for problems you might want to solve:

• Do you have pain points on-premises?
• Do you want to make data monetization through APIs?
• Do you want to outsource your infrastructure and operations?
• Is the hardware in your data center at its end of life?
• Are you about to launch new digital services to a B2C (Business-to-Consumer) audience?
• Are your competitors faster than you to launch new services to consumers, making you lose some market shares?

Finding answers to these questions help identify the main business and IT drivers that serve as an input for your strategy.Business drivers should come from the company's board of directors (or other corporate leaders). IT drivers should come from the IT leadership. Enterprise architecture may play a role in identifying both the IT and business drivers. Once the vision is clear for everyone, the main business and IT drivers should emerge and be the core of our strategy.

Defining the strategy with the right stakeholders

In order to achieve the vision, the strategy should be structured and organized around the vision. To ensure that you do not deviate from the vision, the strategy should include a cloud roadmap, cloud principles, and cloud governance. You should conduct a careful selection of candidate assets (greenfield, brownfield, and so on). Keep in mind that this will be a learning exercise too, so start small and grow over time, before you reach your cruising speed.You should conduct a serious financial capacity analysis. Most of the time, the cloud makes companies transition from CAPEX to OPEX, which is not always easy. Moreover, building a cloud platform even increases the overall expenditures as you must still keep the lights on on-premises at the same time. It will undoubtedly cost more upfront, but you may achieve a return on investment over time.You should see the cloud as a new platform. Some transversal budgets must be made available, and should not be too tightly coupled to a single business project. The new platform you are building should have its own lifecycle, independently of the projects in scope. Lastly, do not underestimate the organizational changes, as well as the impact of company culture over the cloud journey. Make sure that you integrate a change management practice as part of your strategy.In terms of stakeholders, the extent to which the executive committee is involved should depend on the balance between business drivers and pure IT drivers. In order to be empowered to manage the different layers, the bare minimum requirement is to at least leverage a strong business sponsor. You should also involve the Chief Information Officer, or, even better, the Chief Digital Officer.

Starting implementation with the right stakeholders

This phase is the actual implementation of the strategy. Depending on the use case, such as a group platform, the implementation often starts with a scaffolding exercise. This consists in setting up the technical foundations (such as connectivity, identity, and so on). It is often a good idea to have a separate sandbox environment, to let teams experiment with the cloud. Do not default to your old habits, to using products you already use on-premises. Do your homework and analyze Azure's built-in capabilities. Only fall back to your usual tools after having assessed the cloud-native solutions. Stick to the strategy and the principles that were defined up front.In terms of stakeholders, make sure you involve your application, security, and infrastructure architects (all together) from the start. Usually, the Azure journey starts by synchronizing Active Directory with Azure Active Directory for Office 365, which is performed by infrastructure teams. Since they start the cloud journey, infrastructure teams often tend to work on their own, and look at the cloud with infrastructure eyes only, without consulting the other stakeholders. Most of the time, this results in a clash between the different teams, which creates a lot of rework. Make sure that all the parties using the cloud are involved from the ground up, to avoid having a single perspective when designing your cloud platform.The above advice is useful when building a cloud platform for a company. However, these factors are also often important to know for third-party suppliers, who would be engaged on a smaller RFP (request for proposal). To deliver their solution, they might have to adhere to the broader platform design, and the sooner they know, the better. Let us know go through a practical scenario.

Practical scenario

As stated in the previous sections, crafting a few key principles that are signed off by the top management may represent a solid architecture artifact when engaging with various stakeholders in the company. Let's now go through a business scenario for which we will try to create an embryonic strategy:Contoso is currently not using the cloud. They have all their assets hosted on-premises and these are managed in a traditional-IT way. The overall quality of their system is fine, but their consumer market (B2C) has drastically changed over the past 5 years. They used to be one of the market leaders, but competitors are now showing up and are acquiring a substantial market share year after year. Contoso's competitors are digital natives and do not have to deal with legacy systems and practices, which enables them to launch new products faster than Contoso, responding faster to consumer needs. Young households mostly use mobile channels and modern digital platforms, which is lacking in the Contoso offering. On top of this, Contoso would like to leverage artificial intelligence as a way to anticipate consumer behavior and develop tailor-made services that propose a unique customer experience by providing digital personal assistants to end users. However, while the business has some serious ambitions, IT is not able to deliver in a timely fashion. The business asked the IT department to conduct both an internal and external audit so as to understand the pain points and where they can improve.Some facts emerging from the reports include - but are not limited to - the following:

• The adoption of modern technologies is very slow within Contoso.
• Infrastructure management relies entirely on the ITIL framework, but the existing processes and SLAs have not been reviewed for the past 5 years. They are no longer in line with the new requirements.
• The total cost of ownership is rather high at Contoso. The operational team headcount grows exponentially, while some highly qualified engineers leave the company to work in more modern environments.
• Some historical tools and platforms used by Contoso became end of life, and are discontinued by vendors, in favor of their corresponding cloud counterpart, which made Contoso opt for different on-premises solutions, leading to integration challenges with the existing landscape.

As a potential solution, the auditors proposed a magical recipe: the cloud (Azure in our case)! Now, it's up to you, the Azure architect, to manage expectations and advise Contoso on the next steps. We will see an example of this work in the next sections.

Strategy

We could write an entire book on how to conduct a proper strategy, so we will simplify the exercise and give you some keys to get started with your strategy. To understand all the aspects that you have to keep an eye on, you can look at the Microsoft Cloud Adoption Framework (https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/). This is a very good source of information, since it depicts all the aspects to consider when building an Azure cloud platform. Another interesting source of information is about the enterprise-scale landing zones (https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-scale/). Back to the strategy, you could also leverage governance frameworks such as COBIT (Control Objectives for Information and Related Technologies) (https://www.isaca.org/resources/cobit) to help transform verbal intentions into a well-documented strategy, and to consolidate the different aspects so as to present them in front of executive people. COBIT also connects the dots between the business goals and the IT goals in a tangible fashion. One of the key COBIT artefacts is what they call the seven enablers, which are applicable to any governance/strategy plan:

The diagram offers a short definition of each, and their relative impact on the journey. You can easily map them to the dimensions you see in the CAF:

1. Principles, Policies, and Frameworks: This could be summarized as such: what is clearly thought is clearly expressed. You should identify your core principles and policies that are in line with the business drivers. These will be later shared and reused, among all involved parties. Writing a mission statement is also something that may help everyone to understand the big picture.
2. Processes: The actual means to executing policies and transforming the principles into tangible outcomes.
3. Organizational Structures: A key enabler to putting the organization in motion toward the business and IT goals. This is where management and sponsorship play an important role. Defining a team (or virtual cloud team), a stakeholder map, and first and foremost, a platform owner, accountable for everything that happens in the cloud, who can steer activities.
4. Culture, Ethics, and Behavior: This is the DNA of the company. Is it a risk-adverse company? Are they early adopters? The mindset of people working in the company has a serious impact on the journey. Sometimes, the DNA is even inherited from the industry (banking, military, and so on) that the company operates in. With a bit of experience, it is easy to anticipate most of the obstacles you will be facing just by knowing the industry practices.
5. Information: This enabler leverages information practices as a way to spread new practices in a more efficient way.
6. Services, Infrastructure, and Applications: Designing and defining services is not an easy thing. It is important to re-think your processes and services to be more cloud-native, and not just lift and shift them as is.
7. People, Skills, and Competencies: Skills are always a problem when you start a cloud journey. You might rely on different sourcing strategies: in-staffing, outsourcing, …, but overall, you should always try to answer the question everyone is asking themselves: what's in it for me in that cloud journey? In large organizations, a real change management program is required to accompany people on that journey.

Developing a strategy around all these enablers is beyond the scope of this book. Out of real-world experience, we can say that you should work on all of them, and you should not underestimate the organizational impacts and the cultural aspects, as they can be key enablers or disablers, should you neglect them. A cloud journey is not only about technology; that's probably even the easiest aspect.To develop our strategy a little further, let's start with some principles that should help meet the business drivers expressed by Contoso, for whom time to market is the most important one:

• SaaS over FaaS over PaaS over CaaS over IaaS: In a nutshell, this principle means that we should buy instead of building first, since it is usually faster to buy than build. If we build, we should start from the most provider-managed service model to the most self-managed flavor. Here again, the idea is to gain time by delegating most of the infrastructure and operational burden to the provider, which does not mean that there is nothing left to do as a cloud consumer. This should help address both the time to market driver, as well as the exponential growth of the operational teams. From left to right, the service models are also ordered from the most to the least cloud-native. CaaS is an exception to this, but the level of operational work remains quite important, which could play against our main driver here.
• Best of suite versus best of breed: This principle aims at forcing people to first check what is native to the platform before bringing their own solutions. Bringing on-premises solutions to the cloud inevitably impacts time. Best of suite ensures a higher compatibility and integration with the rest of the ecosystem. Following this principle will surely lock you more to the cloud provider, but leveraging built-in solutions is more cost- and time-efficient. In the Contoso scenario, this approach makes perfect sense. However, if your company already has a strong multi-cloud presence and relies on third-party systems for a unified view across cloud environments, this principle may not be the best fit.
• Aim at multi cloud but start with one: In the longer run, aim at multi-cloud to reduce vendor lock-in. However, start with one cloud. The journey will already be difficult, so it's important to concentrate the efforts and stay focused on the objectives. In the short term, try to make smart choices that do not impact cost and time: do not miss low hanging fruit.
• Design with security in mind: This principle should always be applied, even on-premises, but the cloud makes it a primary concern. With this principle, you should make sure to involve all the security stakeholders from the start, so as to avoid any unpleasant surprises.
• Leverage automation: Launching faster means having an efficient CI/CD toolchain. The cloud offers unique infrastructure as code capabilities that help to deploy faster.
• Multi-tenant over single-tenant building blocks: While single-tenant building blocks might give you more control, it also means a risk of reintroducing your on-premises practices to the cloud. Given the audit reports we had, we see that this might not be a good idea. Leveraging multi-tenant PaaS services that have been designed for millions of organizations worldwide is a better response to the business drivers.

This is not necessarily where the list ends. Other principles could be created.Having different drivers would give us different principles. The most important thing is to have concise, self-explicit, and straightforward principles. Now that you have this first piece done, you can build on it to further develop your policies and the rest of your strategy. This will not be covered in this book, so do work on this in your own time. The time has now come to recap this chapter.

Understanding Systems of Engagement

This category regroups services that allow a company to engage with its own employees as well as with external parties. Software components such as user interfaces, mobile apps, APIs, etc. are channels that help engage with first and third parties:

In Figure 2.2, the SoE category map includes the following top-level groups:

• Systems of Intelligence (SoI)
• Frontend
• API
• Near Real-Time
• Notifications

The Systems of Intelligence group in Figure 2.2 includes several subgroups, one of which is CHATBOTS. Over the years, chatbots have gained popularity because they provide instant, automated interactions that enhance customer experience and reduce operational costs. Azure has a lot to offer in that area. Azure Bot Service integrates with many channels (Alexa, Direct Line, Facebook, Microsoft Teams, Slack, etc.) and can be seen as the transport layer of your chatbots. It helps increase their reach. Azure OpenAI handles the conversational aspect of chatbots, while other Azure AI Services facilitate richer interactions. These services are also part of our Personal Assistants sub group, as they can be used to propose tailor-made services to users. Some real-world project examples include a recipe assistant that helps customers generate shopping lists from cooking recipes. Another example is a legal chatbot designed to assist jurists in specialized legal domains.All types of assistants and agents can be built with Azure AI Services, and in particular Azure OpenAI. We will see in more details how to build Retrieval Augmented Generation (RAG) and Cache Augmented Generation (CAG) solutions, later in Chapter 8 – Artificial Intelligence Architecture. While the bot framework allows you to build custom bots, it is also possible to build them in minutes with Copilot Studio without prior development experience. Another interesting service that can bring extra intelligence and capabilities to any SoE is Azure Communication Services (ACS). ACS enables developers to integrate voice, video, chat, SMS, and email communication into their applications, all enriched with AI capabilities. SoIs add intelligent capabilities to SoE and are often coupled to Frontend applications and devices, which is our next group.For building regular frontends, we can use Azure App Service as well as Static Web Apps, which are typically used to host web apps. Static Web Apps were built from the ground up to host SPAs (Single Page Apps), while Azure App Service is rather used for MVC (Model View Controller) types of web apps but can also be used for SPAs. While Static Web Apps promise a streamlined deployment process for SPAs, they introduce complexity as it feels you're locked into Azure's way of doing things. Last but not least, any container-based system can also be used to host either an SPA, either an MVC application. No matter which building block you choose for your frontend, most internet facing web apps require a Content Delivery Network (CDN) component to speed up content delivery. This task, among other things, can be handled by Azure Front Door.Frontends usually talk to APIs, which brings us to the next sub group, namely API. Azure API Management (APIM) is the preferred service to manage APIs at scale and its gateway to proxy the API backends. The API gateway acts as a Policy Enforcement Point (PEP), which allows us to enforce some controls such as rate-limiting, JSON token validation, etc. Additionally, APIM streamlines the management of APIs by facilitating version control (both minor and major versions), debugging, and organizing them into products for seamless exposure to consumers. Backends can be hosted in Azure App Service, which supports a wide set of programming languages (at the time of writing, this includes .NET, Java, Node.js, PHP and Python). App Service can easily be integrated with a deployment factory for Continuous Integration and Continuous Deployment (CI/CD) purposes. App Service allows for zero-downtime and provides rollback mechanisms through the use of deployment slots. App Service is ideal for the following scenarios:

• MVC web applications
• API backend services
• Lift and shift of legacy .NET applications, by using Azure Web App for Containers (AWC) with Windows
• Pre-container-orchestration scenarios, by using AWC with Linux or Windows

App Service relies on App Service plans, which define the compute resources that is allocated to the service(s). Plans are a group of virtual machines of a certain size, managed by the Azure platform itself. As a user, you don't have access to the machines but you decide about the size and the number of instances to use by selecting the appropriate pricing tier. Plans can be single or multi-tenant and support both vertical and horizontal scaling. They can also be shared across web applications. The advantage of App Service over container orchestrators is its simplicity and full management by Microsoft. It is also one of the oldest and most mature Azure service. If you need a stable and straightforward solution to host web apps, choose App Services.In addition to App Service, Function Apps can be used to host HTTP-triggered functions, effectively acting as micro-APIs. However, the Azure Functions runtime introduces some complexity and overhead, which may not be justified for simple HTTP APIs—making App Service a more suitable option in such cases, unless you are already leveraging functions for event-driven scenarios, where they excel. Function apps are primarily running on App Service Plans but are also available under the Consumption plan, which corresponds to the serverless model (FaaS) introduced in the previous chapter. The Consumption plan is mostly used for short-lived and resource-efficient tasks. A newer serverless model called Flex Consumption is now available. It combines some of the strengths of the Consumption tier while supporting virtual network integration, which is more in line with enterprise grade practices.Before exploring alternatives for backends, let's look at what an SoE channel might look like with App Services. Here is a simplified diagram showing how to articulate some of the previously described services together:

We see that the client (browser) talks to Front Door, acting as a CDN, WAF and reverse proxy. Front Door either returns a response from its CDN cache, either fetches the origin, which is a Single Page App (SPA) made available by an App Service. When the SPA calls its Backend for Frontend (BFF), it goes back to Front Door, which in turns forwards to APIM where policies can be enforced. At last, once all controls are passed, APIM forwards the request to the BFF, which in is also hosted on an Azure App Service. When the BFF component needs to call other API services (for example, microservices or backend APIs), it does so via APIM rather than calling them directly. An alternative for the frontend component would have been to use Static Web Apps, but as explained earlier, the way you transition from the frontend to the backend is more convoluted and less controllable.For advanced scenarios, such as high-scale microservice and distributed architectures, container orchestrators are often a better choice than Azure App Service and Function Apps. They offer built-in support for service meshes and advanced add-ons supporting these architectures. Service meshes understand the application layer and are able to differentiate HTTP/1 from HTTP/2, gRPC from REST, etc., optimizing traffic across services and components. Additional frameworks and solutions such as Distributed Application Runtime (Dapr) and Kubernetes Event Driven Autoscaler (KEDA) are native in container orchestrators but not usable in App Services nor Function Apps. However, Azure Functions can be self-hosted within a container orchestrator and in this case, integrate with Dapr and other solutions from the container ecosystem. Remember that for anything you self-host, you are on your own to ensure high availability, capacity etc., potentially increasing the complexity and the burden of IT operations. Further details will be covered in the Containerization section of this chapter, with additional insights in chapters 4 and 5.Here is a revised version of Figure XXX, where only AKS is used to host both the SPA and the backend services.

We see more or less the same traffic flow as in Figure 2.3 but an important difference is that we may decide to rely on a service mesh for traffic flying between the BFF and the other backend services. We hope that these two examples help you grasp some of the key differences between the different technology stacks.Next, let's move on to the Notifications top-level group of our SoE category in Figure 2.2. Azure Notification Hubs (ANH) enables sending push notifications to various systems. It is most often used as a way to push messages to mobile apps.Next, let us explore the Near Real-Time top-level group. Modern frontends provide feedback mechanisms to end users for every asynchronous task. Users might create actions that take time to complete but still expect to have feedback without refreshing the page or their screen in a mobile app. Services such as Azure SignalR Service and Azure Web PubSub provide a bi-directional channel between frontends and backends for near realtime communication, where backends typically send back task-related information that are surfaced on frontends, without requiring any action from the user. Here is an example that introduces SignalR to the previous use case:

The client (browser) establishes a bi-directional connection with Azure SignalR, which we use as a one-way channel to receive notifications from the backend. While the authentication details are beyond the scope of this section, a built-in mechanism ensures secure authentication between the frontend and the Azure SignalR service.To enhance communication, we introduced Azure Service Bus, enabling the BFF to queue commands, which are then processed by backend handlers. Once execution is complete, the backends send results back to Service Bus, allowing the BFF to pick them up and notify the frontend via Azure SignalR.This approach not only creates a feedback loop but also improves scalability by decoupling the BFF from other backend services.In the next section, we are going to discuss the Systems of Record.

Understanding Systems of Record

Strictly speaking, SoRs refer to databases and data integrity. A SoR might (or might not) be transactional or mission-critical:

For our SoR category map (Figure 2.6), we have the following top-level groups:

• Compute Models
• Data Warehousing
• Relational
• NoSQL
• Unstructured

Let's get started with the Compute Models top-level group. The serverless compute model available in Azure SQL and Comos DB enables on-demand scaling based on the actual needs of the workloads. This is very convenient for solutions that support variable performance and potential limited capacity from time to time. Use cases for serverless data stores include – but are not limited to – asynchronous calculations/operations performed by scheduled jobs, time-based peaks and non-user facing applications in general. Serverless is cost-friendly and is ideal for development and testing. Both vCore and DTU (Database Transaction Unit) compute models apply to Azure SQL. The DTU model bundles compute and storage into a single unit, making it less granular than vCore, which allows you to independently choose compute, memory, and storage resources based on your workload needs. Following is a small comparison table that should help you choose the most appropriate model:

Next, we have the Flexible Server model that applies to Azure MySQL and Azure PostgreSQL. This compute model tier is similar to Azure SQL's vCore and has replaced the Single Server mode, which you might still see in many organizations. Finally, Flexible Server includes an auto-stop mode similar to Azure SQL's serverless mode; however, unlike serverless, it does not support autoscaling.In the Data Warehousing group, we find Azure Synapse Analytics , which has replaced the former Azure Data Warehouse service. We will cover it more in Chapter 7, Architecting Data Solutions.That brings us to the next two top-level groups, namely, Relational and NoSQL. The rationale of using a NoSQL engine versus a SQL one is beyond the scope of this book but we can try to summarize the main reasons that lead you to choose either of these. NoSQL systems are designed to scale, and mostly rely on the Basically Available, Soft State, Eventual Consistency (BASE) model, whose biggest impact is eventual consistency. Their purpose is to respond fast to read requests, at the cost of data accuracy. They are suitable for big data, in other words, huge data volumes. In Azure, NoSQL data stores, such as Azure Table storage, also enable strong consistency, but will not scale as much as an eventual consistency-based stores. A good example is Cosmos DB, for which you can choose between different consistency levels, from eventual consistency to strong. The more you go towards strong, the less scalable and performant. On the other hand, traditional SQL engines rely on the Atomicity, Consistency, Isolation, Durability (ACID) model, which is centered around transactions and data accuracy, at the cost of speed. ACID-based data stores are convenient for most workloads and scalability is only a problem for massive volumes. There is no definitive threshold at which the volume of data becomes too large for an ACID-based data store, as it depends on factors such as indexing strategies and sharding. However, as a concrete example, Azure SQL Hyperscale supports a maximum storage capacity of 128 TB.However, one thing is certain: you shouldn't rush to NoSQL without careful consideration, as a poorly designed Cosmos DB can cause significant issues in production.Since SQL engines are nothing new, let us focus on the NoSQL ones. Cosmos DB is Azure's best NoSQL storage solution. It supports multiple API models: SQL, Mongo, Table, Cassandra, and Gremlin. The native MongoDB API is only available through Atlas, a marketplace product, or by self-hosting a MongoDB. Cosmos DB's preferred API model is SQL, as it offers the best performance, so you should try to favor this option first. Going for Cassandra or Mongo introduces an additional overhead incurred by the translation between Mongo or Cassandra to SQL behind the scenes. However, this might be acceptable in lift and shift scenarios consisting of migrating a Mongo database to Azure when the migrated database – and thus application - can survive the overhead. The Table API for Cosmos DB is meant to be an alternative to Azure Storage Tables. Azure Storage Tables are a cost-effective solution for high-capacity storage in a single region (from a write perspective), while Cosmos allows you to achieve global distribution (read/write). The following table gives an indication on when to use relational versus NoSQL data stores:

At last, in our Unstructured group, we find Azure Blob Storage, which allows storing raw blobs. It is commonly used alongside other data stores, where metadata is persisted in Azure SQL or Cosmos DB, while related blobs are referenced in Blob Storage to avoid saturating the database with binaries. Blob Storage itself has built-in system metadata and supports user-defined metadata as well. Azure Data Lake is nothing else but Azure Blob Storage with Hierarchical Namespace (HNS) enabled. Without HNS, blob storage is just a flat file structure behind the scenes, the concept of folders being totally emulated. With HNS enabled, files are organized with folders and sub folders, making Azure Data Lake faster and a better choice than mere Azure Blob Storage for high volumes. Last but not least, Azure Files is a sub resource of Azure Storage allowing Azure Virtual Machines, Azure Kubernetes Service and even from on-premises environments to mount file shares, using both SMB and NFS protocols. Azure Netapp Files is an alternative that is more suitable for very low-latency and high throughput workloads. It is an option to explore, especially if your company already uses Netapp on-premises. Many of the services we depicted so far have built-in activity logs, data protection features such as versioning, soft delete, automated backups, etc. making them suitable for SoRs.There are many other types of data stores in Azure, such as Redis cache, Service Bus, Event Hub, etc. but these are mostly used for for data in transit and not meant to be used directly as SoR. Let us now explore the SoIn (Systems of Insights).

Understanding Systems of Insight

This category regroups data analysis services, helping to extract valuable business insights out of both SoRs and specialized analytics data stores:

In our SoIn category map (Figure 2.7), we have the following top-level groups:

• Analytics
• ETL/ELT
• AI
• Unified

Let's start with the easiest one, the AI group. At this stage, we simply refer you to the dedicated chapter on artificial intelligence. However, it was important to include AI in the SoIns to highlight its role in extracting valuable insights from data.Let us move on to the Anaytics group, which comprises the Kusto Query Language (KQL)-based Azure Data Explorer (ADX) service. KQL is a powerful query language that is used everywhere in Azure to query logs and create alert rules for monitoring purposes. ADX is a fully managed, fast, and scalable data analytics service. It efficiently ingests and analyzes large volumes of structured and semi-structured data. In IoT scenarios, it can be used as an output data store from Azure Stream Analytics (ASA), which will be described later.Now, let's move on to our All-in-One sub-group where we find Azure Synapse Analytics described earlier as it is also part of the SoRs. Beyond having replaced Azure Data Warehouse, Synapse glues many data services together (Azure Data Lake, Power BI, Spark clusters, Azure Machine Learning, etc.) in order to analyze both enterprise and big data. Azure Synapse is intended to be used by both data scientists and traditional Business Intelligence (BI) analysts in a single consolidated service. Quick detour to our Traditional BI sub-group featuring Azure Analysis Services, which you can still use if you come from a traditional BI stack on-premises and want to gradually move to the cloud. Azure HDInsight is an easy and cost-effective method for running open analytics, such as Apache Hadoop, Spark, and Kafka.In our Computed sub-group, Power BI is a comprehensive service that allows you to create reports and dashboards, including real-time dashboarding, at an enterprise scale. Power BI's real-time dashboards can be very handy in any Business Activity Monitoring (BAM) scenario.Azure Databricks is a very comprehensive service that you can use to analyze data at scale. It relies on flexible clusters and can be fed by any data source. It encompasses AI capabilities by leveraging data science frameworks as well as can be used as a vector database. Databricks requires very specific skills, although the SQL language is accessible to non-data scientists.In the Extract Transform Load (ETL)/Extract Load Transform (ELT) sub-group, Azure Data Factory (ADF) is another fully managed service that can be used for both ETL and ELT purposes. It can be combined with Databricks notebooks and Azure Functions. ADF Pipelines can be triggered through API calls, and they can react to Azure Event Grid notifications. ADF is mostly involved in data-in-movement scenarios, such as pulling data from on-premises systems to the cloud using the Self-hosted Integration Runtime (SHIR), that is part of the Hybrid sub-group .Another hybrid solution is the on-premises Data Gateway, which acts as a bridge between the cloud and on-premises data sources. The gateway comes in two flavors: personal and shared. The personal gateway allows users to create Power BI reports against on-premises data, for their own use. The shared gateway is a cross-user and cross-service gateway. A more recent flavor of gateways is the Virtual Network Data Gateway, which is used to bridge Power BI, now part of Microsoft Fabric, with Azure-hosted workloads that have been privatized. It has become a common practice to shield any data service behind private endpoints, making those services inaccessible from Power BI, without a gateway to bridge the two worlds.Azure Stream Analytics (ASA) is a serverless service that belongs to the Near Real-Time subgroup. In essence, ASA processes data streams by analyzing and applying transformations in real time. It ingests data through inputs and sends the filtered or transformed results to specified output destinations.ASA is often used in conjunction with Power BI real-time dashboards for BAM and IoT scenarios, as well as with Synapse for further data analysis. For more advanced scenarios or when input channels are not supported by ASA, Azure Databricks Structured Streaming represents a good alternative to process and handle data as it flows. To conclude this section, let's look at the Unified top-level group. In recent years, Microsoft has made efforts to unify all data services under a single umbrella called Microsoft Fabric. It is a SaaS platform that integrates with data and AI services. We will zoom in deeper on the data services in a dedicated chapter. Let us now focus on SoIs.

Understanding Systems of Intelligence

We saw earlier that SoI can be tightly coupled to SoE because frontends, mobile apps, etc. – in other words – customer facing apps are enriched with intelligent capabilities surfacing on client devices. However, SoI also exists as an independent category when used from within backends. They differ from SoIn in that they are used to make near-real time decisions on current context as well as on historical data. Scenarios such as industrial automation, autonomous decision systems, etc. are all part of SoI and can be achieved through the use of Azure AI Services. We will explore them in Chapter 8, Artificial Intelligence Architecture. Let us now explore Systems of Integration (SoInt).

Understanding Systems of Integration (IPaaS)

SoInt, illustrated in Figure 2.8, represent the way to integrate systems together. In Azure, we can refer to this as Integration Platform as a Service (IPaaS). This category regroups services that enable integration between different layers of a single solution or across multiple solutions and systems.

In the Systems of Integration (IPaaS) category map (Figure 2.8), we have the following top-level groups:

• Event Driven Handlers
• API
• Point-to-Point
• Hybrid
• Pub/Sub
• Orchestration

In the Event Driven Handlers top-level group, we find Azure Functions, which have many built-in bindings and triggers allowing interactions with other services and reacting to events, such as when a message is delivered, a blob has landed onto Blob Storage and so on. Azure functions are gluing services together. As seen earlier, functions can be hosted on App Service Plans and are also available as serverless through the Consumption and Flex Consumption pricing tiers.Beyond Azure Functions, that are centered around application events, you can also rely on Azure Event Grid System Topics to react to events happening in Azure itself. More than 25 Azure services produce events that can be captured by Azure Event Grid. You can find an exhaustive list here https://learn.microsoft.com/en-us/azure/event-grid/system-topics. This can be used from within applications, such as for example, triggering an action when a new client connects to Azure SignarlR, as well as for monitoring, such as when a Key Vault certificate has expired or a new Kubernetes version is available.Nowadays, integration is made through APIs. Azure API Management (APIM), that is part of our API top-level group, is Azure's first-class citizen for exposing APIs to other systems and organizations. The following list highlights the main APIM features:

• Versioning: Dealing with multiple versions of the same API, for backward compatibility.
• Revisions: Testing API changes, with the ability to promote them later on, as the real/deployed versions.
• Products: Clubbing APIs together into a product, and then letting API consumers subscribe to the product.
• Policies: Enforcing controls, such as JWT token validation, throttling, HTTP header check, request/response transformations, and so on. Policies are enforced by the API gateway, which is also known as the Policy Enforcement Point (PEP). API gateways can also be self-hosted, mostly in hybrid scenarios (on-premises, cloud, or cloud-to-cloud).
• Workspaces to share APIM across multiple business projects.
• Developer portal: Letting consumers discover and subscribe to your APIs.
• Publisher portal (Azure Portal): Managing your APIs.

The preceding list is not exhaustive, but the key thing to remember is that all API management systems (not only Azure's APIM) play an important role when integrating different systems together. APIM is mostly used in Business-to-Business (B2B) contexts, when exposing APIs to other parties or as part of an integration landing zone, when application from different domains must interact. APIM supports a wide variety of protocols and specifictions such as OpenAPI, GraphQL, gRPC, WSDL and WADL over HTTP/1.1 and HTTP/2. Each APIM instance maintains its own catalog, which can become difficult to manage at scale when multiple instances are in use. Azure API Center addresses this challenge by serving as a centralized catalog for the entire organization, encompassing both APIM-managed and non-APIM APIs.Azure has native services to deal with all types of integrations. In the PUB/SUB top-level group in Figure 2.8, two services emerge: Azure Service Bus and Azure Event Grid (again). Both are suitable for Event-Driven Architectures (EDAs). The boundaries between a message and an event are sometimes blurred, because an event itself is a message. An event is generally used to tell others that something happened in a fire and forget way, while messages are rather commands to be processed by handlers.Both Azure Event Grid Custom Topics and Service Bus can be used to handle events using the Pub/Sub pattern. The major difference between them is that Event Grid is based on a push delivery model while Service Bus is mostly pull-based, although it also supports push-based delivery (via AMPQ's link credit feature), but this is never used in practice. In any case, Pub/Sub is used for discrete events. An example of discrete event could be: an order has been created. It is reasonable to consider that, for a given application, discrete event types can emerge as outcomes of an Event Storming session—a key practice in Domain-Driven Design. In contrast, Azure Event Hubs is ideal for telemetry, event streaming and event series, requiring high throughput, such as in IoT scenarios where IoT Hub is in fact internally based on Event Hub. Kafka-enabled Event Hubs can also be used for integrating on-premises Kafka instances with the cloud or migrating on-premises workloads that are using Kafka clients. Kafka is a special case because it is suitable for both discrete events and streaming.Pub/Sub is primarily used when multiple services might need to capture the same discrete event, that we explained earlier, as well as integration events. In microservice architectures, it's common for each service to maintain its own data store. While the use of a ubiquitous language helps ensure that data concepts are unique and aligned with each service's domain, the separation of data stores often introduces the need for data synchronization—typically handled through what we refer to as integration events.Figure 2.9 illustrates how Azure Event Grid and Service Bus differ from that perspective:

They both use topics and subscriptions but the main difference is the way they deliver the events, being push-based or pull-based.Here is a comparison of both services:

Table 2.3 – Comparison between Event Grid and Service BusBeyond semantics, the fundamental difference between commands and events lies in the messaging patterns they follow. Events are based on the Pub/Sub one, while messages are based on the Point-to-Point (P2P) one. Historically, P2P was often used for both because Pub/Sub did not even exist back in the days. You will still encounter many on-premises legacy integrations, where different systems exchange so-called events via P2P rather than using Pub/Sub. This bad habit can tend to repeat itself in the cloud, especially when migrating on-premises workloads, and that's where you step in as an Azure Solution Architect.In cloud native solutions, we try to avoid this situation and strictly use P2P within a single domain or within a single application. For example, P2P is ideal when relying on the Load Levelling Pattern illustrated in Figure 2.10:

In this example, Application A users use the frontend which ultimately generates commands such as submitting a shopping list for order, etc. The commands are then transmitted to the BFF, which in turn, queues them to a Service Bus queue. One or more background handlers will listen to that queue and process the messages to handle the heavy lifting work at their own pace. The ensures proper scaling during peak load, preventing the frontend and the BFF from being saturated. The message broker is the buffer between the frontend, BFF and the actual backend. Ultimately, a feedback loop can be done by the backends to the frontend through services such as Azure SignalR, which we will describe later. Another valid use case for P2P communication is SAGA choreographies within the same domain, where participants execute actions in response to queue-based commands. Azure Queue Storage Queues and Azure Service Bus Queues are the two main services enabling P2P. Below is a summary of the main differences between the two:

Table 2.4 – Comparison between Service Bus and Storage QueuesYou can find an exhaustive comparison here https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted.Now, let's dig into the Orchestration top-level group (see the bottom of Figure 2.8), as it allows us to handle orchestration-based SAGAs.For these workflow-like workloads, Azure Durable Functions and Logic Apps are the main services you would use. Logic Apps ships with hundreds of pre-built connectors and allow you to create workflows in minutes. Durable Functions require development skills as they make use of the Durable Framework, which you can integrate in your application. It is worth mentioning that Microsoft launched a preview of the Durable Task Scheduler in May 2025 that helps manage and monitor durable functions at scale. You should use Logic Apps whenever you target integrations with well-known third-party services (SaaS platforms) or integrate different systems together. You could use Durable Functions whenever you need orchestrations that are scoped to a single application.Hybrid services, our last top-level group, rely on on-premises agents that initiate outbound connections to Azure, creating a bi-directional communication channel for exchanging data. This approach is especially useful when there's no private peering between Azure data centers and on-premises environments, or when a cloud-based service needs to interact with on-premises systems. By running the agent locally, hybrid services can support protocols like NTLM and Kerberos—common in on-premises setups but not natively supported by most PaaS offerings. For example, Azure Hybrid Connections allow an Azure App Service to consume an on-premises database seamlessly, without the need of exposing the on-premises database to Internet no to have a private connectivity between the two worlds. Admittedly, this type of integration has become less common between PaaS services and the on-premises systems because most PaaS services now integrate fully with Virtual Networks, which in turn leverage the private connectivity. Yet, SaaS systems such as Power BI, still leverage this type of integration, as we described in the Sytems of Insights section.Let's now explore the Azure container landscape.

Learning about monitoring

Monitoring might not be the most exciting topic but is mandatory for any system that runs in production. The purpose of monitoring systems and applications is to detect adverse events as soon as possible, and respond manually or automatically. Monitoring also makes it possible to have global oversight of the running systems and be able to efficiently troubleshoot any issue, at either application, either infrastructure level. Additionally, you can then collect Key Performance Indicators (KPIs) to evaluate the service quality towards your proposed Service-Level Agreements (SLAs). See Figure 2.15 to zoom in on the monitoring category:

In Figure 2.15, we have three top-level groups: Common 3rd Parties, Native, and DSC. Let's discuss the Common 3rd Parties top-level group. Most organizations already have monitoring in place on-premises and many of them want to keep using the same monitoring infrastructure across all environments, cloud(s) and non-cloud. This is why we are often required to make diagnostic logs as well as application logs available to usual suspects such as Splunk and QRadar, the latter being focused on security logs. The good news is that such integration is rather easy since both Splunk and QRadar have built-in connectors allowing them to ingest Azure (security) logs. The only thing you have to do is to export logs to Azure Event Hubs. System Center Operations Manager (SCOM), a very common tool on-premises, has a management pack for Azure. However, even when integrating with third-party monitoring solutions, it's advisable to leverage Azure Monitor, as it is the native monitoring tool. Relying on external systems for alerts can be risky due to massive log ingestion, often causing on-premises systems to become overwhelmed, potentially disrupting them, or triggering alerts long after an issue has occurred. A more effective approach is to define alert rules in Azure Monitor and let it notify the other systems as needed. This way, you lower the delay between the occurrence of a problem and its detection while still integrating with on-premises systems to have a 360% view. Another benefit of such an approach is that you do not especially need to map all your KQL-based queries into Splunk ones. Moreover, this still allows you to centralize all logs to a platform such as Splunk, while not rely on these to generate alerts.This naturally bring us to the Native top-level group. Azure Monitor is the main service that collects all the metrics, while Log Analytics is usually used as a central log repository to query both diagnostic and application logs through KQL. Optionally, Azure Event Hubs can be used to centralize all logs to be ingested by Splunk. You can define alerts on both metrics and logs. Alerts are sent through action groups, which range from sending emails and SMS to triggering automated responses via Logic Apps, which integrates with virtually anything. Here is a high-level view of how this could look like:

Workloads send their logs to both Log Analytics and Event Hub. Log Analytics and Azure Monitor Metrics serve as the input to define alert rules. Logic Apps propagate alerts to a solution such as IBM Tivoli while Splunk pulls all the logs from Event Hub for centralization purposes.Azure Network Watcher is a set of tools for you to diagnose network-related problems. Application Insights focuses on application logs, enabling real-time observability (OpenTelemetry), request tracking, dependencies and allows developers to define custom traces. Application Insights integrate with Log Analytics Workspaces. Azure Workbooks are useful to quickly view a visual representation of a solution's health. Over the recent years, the rise of container-based solutions lead to the integration of Grafana and Prometheus as managed services. Grafana is centered around dashboarding, while Prometheus is a metric collector that is omnipresent in the container world.Lastly, in our DSC group (see Figure 2.16), Azure Automation is the only native Azure service that ensures a Desired State Configuration (DSC), with a focus over virtual machines. DSC consists of defining a desired configuration and get the service auto-correct deviations from that desired state. Azure Automation meets similar needs as Ansible, Chef, Puppet, and so on. Azure Automation can also be used to provision Azure Resources through Automation runbooks, either directly or from CI/CD pipelines through webhooks. Its hybrid workers also make it easy to interact with on-premises systems. Note that Azure Automation will be replaced by Azure Machine Configuration as of 2027.From the very beginning, an Azure solution architect should envision a monitoring strategy that is scoped to either a single solution or that is scoped to integrate with a strategy that is defined for the entire platform. This will impact deadlines if a monitoring strategy is not considered from the start. If a requirement from the landing zone is to redirect logs to Azure Event Hubs, then in order to let Splunk ingest them on-premises, you, the Azure solution architect, must supervise the activities accordingly, and reflect this in an initial set of solution diagrams.

Learning about factories (CI/CD)

Continuous Integration/Continuous Deployment (CI/CD) has become mainstream and is a key enabler for a successful cloud journey. The ultimate goal is to do Anything as Code, but, before getting there, a substantial amount of work must be provided upfront. In this second edition of the book, we decided to only shed some light on the CI/CD topic, so as to focus more on architecture. It remains nevertheless important for Solution Architects to assess the level of readiness of the existing CI/CD factory (if any), as it will influence the transition from drawing board to a tangible workload running in production. Poor CI/CD practices will impact your velocity as well as the resulting quality. Figure 2.17 zooms in on CI/CD spoke/area of our Solution Architecture Map:

Our CI/CD zoom-in map includes five elements:

• Delivery Modes
• Pipelines
• K8s/OpenShift
• IAC
• Quality Gates

Let's get started with the Delivery Modes top-level group. You might be surprised how DevOps and GitOps differ and how impactful those differences are towards organizing a CI/CD factory. In essence, the pursued objective is the same, we want to maximize automation and empower application teams to achieve more in less time. GitOps is pull-based, which means that the source of truth are the Git repositories themselves. This eliminates the need of pipelines. Repos are monitored by a tool that deploys what's known in the repos to the target environments, upon pull request (for control) or straight commit to a branch. Conversely, DevOps is push-based, which means that you still need to configure pipelines to build the code and deploy it to the target environments. Discussing about Pipelines, we typically use Azure DevOps YAML piplines for both, building and deploying apps. Classic pipelines were typically used for releases only but should not be used anymore. Another popular tool is GitHub, which relies on GitHub Actions to build and deploy applications. There are of course other platforms such as Jenkins, etc. that can be used for CI/CD, but since Azure DevOps and GitHub are part of the Microsoft ecosystem, it makes them first-class citizens when deploying to Azure.Container-based platforms such as K8s/OpenShift, are natively built on top of GitOps principles. ArgoCD and Flux are two CNCF projects that help deploy both infrastructure and applications to the clusters. In Azure, we typically provision AKS with an IaC (Infrastructure as Code) language but the internals of the clusters are typically managed by either Flux or ArgoCD. Both solutions support using Helm and Kustomize, two of the most popular ways to deploy components to K8s. Although GitOps is a best practice for K8s and OpenShift, it is possible to use push-based pipelines as well. The main difference between GitOps and DevOps for K8s, is that ArgoCD also supports DSC, detecting any drift between the desired state (repos) and the actual state (the cluster).In the IAC top-level group, we find the most frequently used languages to deploy to Azure, namely Terraform and Bicep. Pulumi differentiates itself by reusing well-known programming languages such as Python, TypeScript etc. ARM used to be the only way to deploy Azure infrastructure back in the days but is definitely not the primary choice anymore because of its complexity. If you use Bicep or Terraform, you should look at the Azure Verified Modules, which regroups IaC modules according to best practices. Here is the link to the website https://azure.github.io/Azure-Verified-Modules/.At last, the overall purpose of automation, is to improve velocity while improving quality. To do so, Quality Gates can be enforced before deploying anything to production. SonarQube and SonarCloud remain very popular and focused on code quality. They will impact quality attributes such as maintainability, evolvability, changeability, etc. and make sure the code adheres to well-known principles such as SOLID, DRY and Clean Code. Selenium is often used for integration tests. Snyk is a very good solution for anything-security. Whether you want to scan source code or container images, Snyk is a modern and developer-friendly solution. JFrog is a well-kown supply chain platform that covers the end-to-end supply of software. Organizations using JFrog will also typically use JFrog's Xray to scan container images. An alternative to Snyk and JFrog's Xray to scan container images, is to use Agentless Container Vulnerability Assessment, which replaces the former Defender for Containers.The list of solutions presented in the map are by no means exhaustive but represent some of the most commonly used ones when building and deploying solutions to Azure and its container ecosystem. Now, let's explore the identity solutions that Azure provides.

Learning about identity

In the cloud, identity is one of the most important layers, and it is often overlooked or not well-known by solution and security architects. There is a huge gap between on-premises identity systems and cloud-based identity systems, where OpenID Connect and OAuth are dominant protocols. Figure 2.18 zooms in on the identity category:

For the IDENTITY zoom-in map, we have four top-level groups:

• Hybrid
• B2E
• B2B
• B2C

In the Hybrid group, the Entra ID Proxy gives you remote, secure access to your on-premises apps. It allows you to authenticate cloud users to on-premises webapps and APIs transparently, without changing anything to the on-premises solutions. While this can be handy at times, you must accept the fact that the endpoint made available by the proxy is internet facing, somewhat playing the role of a DMZ (Demilitarized Zone). The proxy is able to handle protocol transition, such as signing in using OpenID Connect and generate a corresponding Kerberos ticket on behalf of the user to target the on-premises systems.Active directory and Entra ID do not have that much in common when closely looking at them. IAM (Identity and Access Management) teams have a solid learning curve ahead to master Entra, which is the cornerstone of the Microsoft Cloud. Identity is one of the key foundations that you must define before you host anything in Azure. It is an important part of the Cloud Adoption Framework and a solid foundational asset. An Azure Solution Architect must have a fundamental understanding of modern authentication mechanisms, as they bridge two key layers: the application layer, which handles user authentication and token requests/validation, and the infrastructure layer, where client applications and APIs must be registered with the identity provider before they can be used. A good knowledge in that domain helps guide both developers and cloud engineers.That brings us to our second group in the identity zoom-in map. In a B2C (Business-to-Enterprise or Business to Employees) context, Entra ID is used to authenticate internal employees and collaborators to systems and applications. Microsoft Entra Connect provides hybrid identity features, such as password hash sync, pass-through authentication, synchronization between your on-premises directory and Entra ID to let you leverage single sign-on. Entra Connect Passthrough Authentication is an alternative to ADFS (Active Directory Federation Services) that allows you to validate user credentials against your on-premises directory, while not having to plan for the full ADFS infrastructure. Additionally, Passthrough Authentication can seamlessly switch to Entra ID-only authentication, should the on-premises agent not be available.Next is Business to Business (B2B), our third grouping from Figure 2.18. Entra ID can also be used in a B2B context through B2B invites. That is typically how you can control who Office 365 users can invite in a B2B collaboration context. The same applies to custom workloads.Finally, we have our fourth/bottom group. In a B2C (Business to Consumers) market with many public-facing apps and APIs, Entra External ID is the preferred choice and is gradually replacing Azure Active Directory B2C for that matter. You can use Entra External ID's own user store or integrate with well-known identity providers such as Facebook and Google, and any other OIDC-compliant identity provider.Because identity is an important security pillar in the cloud, we will explore it further in Chapter 9, Security Architecture. Now, let's take a high-level look at the security landscape in the next section.

Learning about security

Security is a primary concern for every organization. Figure 2.19 is a very high-level and condensed view of Azure's security landscape:

We have six top-level groups for our SECURITY zoom-in map (Figure 2.19):

• Live Threat Detection
• Posture Management
• Live Threat Detection
• CASB
• PAM
• Appliances

Let's start with the Posture Management top-level group. Azure Policy is the corner stone of governance in Azure. In a nutshell, policies allow you to make sure deployed resources remain compliant with corporate standards. For example, you may want to make sure that every App Service is configured with encryption in transit (HTTPS). You might want to check that no public IPs can be created by default, etc. Since policies govern all deployments in Azure, as a Solution Architect, you must ensure compliance with organizational standards. Certain services may be restricted or prohibited, requiring an exemption request, which could introduce challenges from the outset. This is especially critical when working for a consultancy firm, where you may not be fully aware of the client's corporate policies. Similarly, we have seen countless of K8s-based vendor solutions that do not comply with the default built-in AKS policies, which either forces the vendor to rework its product, either you to lower your security level. It is your duty as a Solution Architect to anticipate on this.Another product that helps keeping a good security posture is Microsoft Defender. It is versatile and granular as you can enable Defender by workload types. For example, you may use it as an anti-virus for Storage Accounts, or let it analyze your API traffic and detect potential security flaws through its Live Threat Detection mechanisms.Microsoft Sentinel is a cloud-native service in Azure that helps organizations detect, investigate, and respond to security threats. It acts as both a Security Information and Event Management (SIEM) system and a Security Orchestration, Automation, and Response (SOAR) platform. As a SIEM, it collects and analyzes security data from various sources to identify potential threats. As a SOAR, it streamlines and automates security operations, helping teams respond to incidents more quickly and efficiently. Although it's built into Azure, Sentinel can also integrate with on-premises systems and other cloud environments, making it a flexible solution beyond just Azure-based workloads.Automated responses, named playbooks in this context, are performed through Logic Apps, which has built-in connectors to hundreds of first and third parties. One of Sentinel's biggest benefits is that it will automatically scale as needed. A few years ago, Sentinel was even not showing up in Gartner's Magic Quadrant but filled the gaps at an incredible speed and now is part of the leaders. Yet, the same usual suspects as for monitoring, namely Splunk and QRadar, are still often used in the enterprise for SIEM/SOAR purposes.In terms of Cloud Access Security Broker (CASB) solutions, organizations often use Netskope and Zscaler. The primary focus of such solutions is to enforce zero-trust, a principle that aims at validating each and every end user/system activity, as well as data leak prevention, with a strong focus on the cloud. In the past, CASB solutions used to be mostly used on client devices but they are now moving to backend systems as well. A concrete example of this could be egress Internet traffic coming from Azure backend services, such as API Management, AKS, etc. being sent to a Netskope SaaS tenant for further verification. The impact of such practices is not to be neglected as they might force all your Azure components to trust Enterprise Certificate Authorities that sign the intermediate certificates sent by Netskope, which can be a serious pain.Microsoft's CASB is a SaaS solution named Defender for Cloud Apps and aims to address the exact same concerns. As a Solution Architect, it is important to anticipate on this, because you will have to integrate with these systems or might even be unable to use certain services, especially if TLS inspection is enforced at CASB level.Our next top-level group is Privileged Access Management (PAM), for which Azure features Privileged Identity Management (PIM). The main purpose of PAM tools is to elevate user privileges only when required and for a short duration, while tracking sessions, etc. PIM is rather straightfoward to use, which is not the case of CyberArk, a worlwide leader in that space, but that is quite challenging to integrate with all aspects of Azure.Our last top-leve group is Appliances, under which we can find native and common third-party solutions. Azure Firewall is a built-in service allowing to apply layer-4 and layer-4 firewall rules. Its premium tier allows to enforce TLS inspection and IDS/IPS (Intrusion Detection System / Intrusion Prevention System), the same way as you would traditionally do with niche players such as Palo Alto, Fortinet and Check Point. These third-party offerings are typically hosted on virtual machines. Recently, Palo Alto recently introduced the Cloud NGFW for Azure SaaS (also available for AWS and Google), offering seamless integration with Azure while eliminating the need for infrastructure management. When it comes to WAF (Web Application Firewall), Azure features WAF Policies, which can either be attached to Azure Front Door, either Application Gateway. The core ruleset is based on OWASP (Open Worldwide Application Security Project), a well-known authority that establishes the most common web vulnerablities, among other things. Additionally, we can define custom rules to achieve a tailored configuration. Alternatives on the market are F5, Imperva, Barracuda and of course Cloudflare, a well-known authority in that field. Similar to firewalls, WAFs have an even greater impact on custom solutions, often generating false positives that block legitimate traffic and trigger arbitrary 403 (Forbidden) errors. To minimize issues, it is crucial to test solutions in a non-production environment using the same WAF rules, ensuring alignment with WAF policies. The choice between native and third-party services typically falls to the network and security teams.We will explore deeper all the security concerns in Chapter 9, Security Architecture.

Learning about networking

Like identity, networking is a very important pillar. While not necessarily knowing bits and bytes about networking in Azure, Solution Architects should understand what role it plays in the overall solution. Every asset might deal with public and private endpoints, with different types of reverse proxies and firewalls. When it comes to hybrid workloads, say, for instance, a frontend in the Cloud talking to an on-premises backend, connectivity becomes even more crucial. Cross-cutting concerns, such as performance and resilience, are directly related to the underlying network plumbing. Figure 2.20 shows the most important connectivity options at our disposal, in order to bridge Azure data centers to on-premises ones, as well as to route and secure traffic:

For the networking zoom-in map, we have four top-level groups:

• Reverse Proxies, WAF, and Load Balancers
• Routing
• Data Center, which you have to understand as on-premises data center
• Topologies

Let's start with Data Center. Azure ExpressRoute guarantees a certain bandwidth, a specific level of resilience, and a quality of service, but a mere VPN connection does not. Solution Architects should know what is already set up (if anything), in order to evaluate whether (or not) the underlying network plumbing satisfies the non-functional requirements, especially when dealing with hybrid workloads. Azure ExpressRoute is the de facto connectivity choice made by many organizations.The second top-level group is Reverse Proxies and Load Balancers, where we find Azure Front Door and Application Gateway. Both are reverse proxies, with or without WAF enabled, but Azure Application Gateway is a regional service while Front Door is global. Any geo-distributed application should either use Cloudflare (if Azure is discarded), either Front Door or Traffic Manager, which is a DNS-based load balancer. Unlike Front Door, Traffic Manager does not proxy traffic but rather redirects the client to the right backend using DNS-based rules. Commonly used third-party reverse proxies and WAF are F5 and Imperva, already introduced in the previous section. For load balancing, besides Traffic Manager, Azure has multiple types of internal (ILB)/external (ELB) load balancers based on different pricing tiers. Interestingly, it is possible to bind ILBs to Azure Front Door using Private Link Service. Load balancers are everywhere in Azure, whether managed by you or by Microsoft.One of the key considerations for a Solution Architect is identifying the Network Topology used in the Azure environment, as it significantly influences workload design and can even determine which services are viable or restricted. One of the most widely adopted topology is Hub and Spoke, where workloads are deployed to spokes and where hubs are virtual networks dealing with specific duties (firewalls, hybrid connectivity, DNS, etc.). You can choose to fully manage the Hub-and-Spoke architecture yourself or opt for partial management using Azure Virtual WAN, which introduces Virtual Hubs that are entirely managed by Microsoft. An alternative to Hub and Spoke is the Mesh Network topology which is a decentralized network architecture where nodes are interconnected. This can easily be achieved using Azure Virtual WAN. The initial value proposition of Virtual WAN was to connect all branch offices of an organization together with the least possible effort. Now, Virtual WAN has drastically evolved and even allows you to bring your own appliances. We will dive much deeper into Azure and Kubernetes networking in the next chatpers.Now, let's take a quick look at governance.

Learning about governance/compliance

Whether you like it or not, a properly managed Cloud environment must be governed. Governance is key to keep things under control and manageable at scale. While not being directly in charge of the overall governance yourself as a Solution Architect, you must understand the landing zone model that has been adopted by the organization. Some well-organized companies might decide which service you can use or not depending on non-functional requirements such as RTO (Recovery Time Objective) and RPO (Recovery Point Objective) as they might have already mapped Azure services to RTO/RPO levels. RTO/RPO plays a key role in being able to define a service level your solution must adhere to. This could even be more important for customer facing applications (B2B or B2C). Figure 2.21 depicts the main services involved in defining a governance:

The GOVERNANCE zoom-in map has five top-level groups:

• Pre-configure Complaint Workloads
• RBAC
• Hierarchy
• Global Oversight
• Frameworks

Azure governance is directly linked to the strategy of the Cloud journey, which we discussed in Chapter 1, Getting Started as an Azure Architect. The good news is that a documented strategy can be enforced in a tangible manner, through Azure Policy, that is part of our Global Oversight top-level group. As a Solution Architect, whether designing a solution for your own organization or for a customer, you must know which policies are enforced in the hosting environment. This must be anticipated, in order to avoid any unwanted surprises later on. Azure Policy lets you define virtually any rule that control how resources are deployed. It makes it possible to deny non-compliant deployments, to fix them on the fly or to simply audit deviations and remediate them later. Azure Policy is very powerful but can be very constraining at times. Common policies include managing deployment regions for services, restricting virtual machine sizes, preventing public access, enforcing service pricing tiers, and verifying whether resources are properly tagged, among other controls. Another way to rule the system is through Azure RBAC (Role-based Access Control), which lets you define who/what can access Azure resources. Azure RBAC is very granular as it has hundreds of built-in roles and lets you create custom roles if needed. Both RBAC and Azure Policy are tightly coupled to the Hierarchy, as they can be bound to each level of the Azure hierarchy, starting from the Root Management Group.The hierarchy reflects the structure of an organization, as well as all the scopes over which Azure policies and RBAC are applied. The hierarchy is composed of management groups, subscriptions, and resource groups. Each of these levels is an RBAC and policy scope. In practice, you might have hierarchies that are business-driven, as shown by Figure 2.22:

Hierarchies might also be more IT-driven, as shown in Figure 2.23:

You may combine both business and IT groups by using nested management groups. There is no one size fits all approach and each company defines a hierarchy that best reflects their own internal organization. In addition to Azure Policy for governing the platform and a structured hierarchy for organizing resources, you can leverage Microsoft Defender to evaluate overall security posture and Azure Resource Graph for querying resource-related information.To make sure your governance is based on solid foundations, you can rely on the CAF, introduced in the first chapter. The Well-Architected Framework (WAF) can be considered a governance tool focused on workloads, as it provides best practices and reusable patterns applicable across various solution types.At last, you can boost your compliance by using Pre-Configured Compliant Workloads, through Template Specs and Deployment Stacks, but these are mostly focused on ARM or Bicep. While it is possible to use them with Terraform, we would recommend you to stay away from it as it implies the use of the AzApi provider, which should generally be restricted to the bare minimum in favor of the AzureRm provider.While the design and definition of landing zones are primarily the responsibility of the infrastructure and security teams, Solution Architects must proactively consider all aspects of a solution. They should gather comprehensive information about the landing zones, as these will inevitably influence the solution's design. In an ideal world, Solution Architects should even be active contributors to the landing zone design to integrate application dimensions as well. Another key consideration—though not strictly architectural—is cost management, which typically falls under the broader umbrella of FinOps. While FinOps is generally aligned with platform governance, Solution Architects have a crucial role to play in designing cost-efficient solutions. Amazon CTO Dr. Werner Vogels outlines seven guiding principles for cost-conscious architecture (https://thefrugalarchitect.com/laws/), which are well worth exploring. Now, let's examine which Azure services from the first edition of the Azure Solution Architecture Map have been retired or are scheduled for retirement, as this also affects solution designs over time.

Use case scenario

Contoso needs a configurable workflow tool that allows them to orchestrate multiple resource-intensive tasks, based on blobs landing in a blob storage. Each task must launch large datasets to perform in-memory calculations. For some reason, the datasets cannot be chunked into smaller pieces, which means that memory contention could quickly become an issue under a high load. A single task may take between a few minutes to an hour to complete. Workflows are completely unattended (no human interaction) and are asynchronous. The business needs a way to check the workflow status and be notified upon completion. The solution must be portable but a minimal rework is acceptable in case of migration to another system. Contoso's manpower is a pool of .NET developers. They do not have data scientists and do not want to invest for such skills. They have a limited budget and want a solution in a timely fashion. Now, let's try to extact the most important keywords of this scenario.

Using keywords

As an Azure solution architect, you must capture the essential part of a story. Of course, in reality, you would have a few back-and-forth discussions with the business and be given an opportunity to ask questions and challenge their assumptions Nevertheless, here are a few keywords that can structure your train of thought before designing a solution. Let's review them one by one:

• Portability: Whenever portability comes as a requirement, containers represent a good candidate.
• .NET: They only have .NET skills in house and do not want to invest in data scientists/architects profiles. This discards data services such as Azure Databricks, which could have been the perfect candidate for such data calculations.
• Resource-intensive tasks: In the cloud, as in any environment, computing power comes at a cost. With our limited budget, high-memory and high-CPU virtual machines are not an option. Instead, we must consider more flexible compute solutions, such as serverless or auto-scaling systems. The scenario does not specify whether guaranteed capacity is required on a permanent basis.
• Task duration: This criterion is a structuring factor, as it eliminates some hosting options, such as Azure Functions hosted on the Consumption pricing tier (which cannot exceed 10 minutes of execution). One option could be Azure Functions on pre-paid pricing tiers.
• Workflow: A workflow is a sequence of steps that are executed in a coordinated way. This aspect is important because it reduces the field of possibilities.

Let's now see how to make use of the map to progress in our thinking process.

Using the Solution Architecture Map against the requirements

Now that we have highlighted the important keywords, let's take a look at our map to try and make sense of it. We'll build a reference architecture, which you could be reused by other projects later. We know that we must be able to handle orchestrations. Figure 2.24 is a subset of the Solution Architecture Map:

A workflow being an orchestration, we see two possibilities (under Orchestration in Figure 2.24): Durable Functions and Logic Apps. Logic Apps seem more appropriate for integration scenarios. Since our workflow is scoped to a single application and our team is made of .NET developers, Durable Functions might be a fit. At this stage, it is hard to make a choice based on this map only. By the end of the book, you'll have a much deeper understanding of the options but now, you're still required to do a bit of extra research before taking a decision. After a bit of extra reading, you managed to get a deeper comparison between Logic Apps and Durable Functions and end up with the following sub map:

The manpower you have at your disposal is one of the factors to consider. Logic Apps is fully declarative, and it does not require any programming skills. Durable Functions is mostly developed for the scope of a single application and requires development skills. We have .NET developers and we do not have to deal with a workflow that goes beyond the scope of our single solution. The power of Logic Apps that ships with hundreds of connectors towards first and third-parties is not required for our scenario, making Durable Functions the most suitable option.Because we know we will use a container-based solution to satisfy the portability requirement, we look at the Containerization branch of our map:

For our use case, orchestrations are triggered based on blobs landing in the blob storage. Given the limited budget, we should look at services that allow us to perform resource-intensive tasks at a reasonable cost. We can safely assume that each orchestration can be seen as a multi-step job that performs calculations. We see that both Azure Batch and Container Instances are a good use case for jobs. As we previously observed, Container Instances can be easily created and destroyed, offering substantial compute resources while being billed per second of execution. They check all the boxes, as they are cost-friendly, compute-intensive friendly and can run Windows/Linux containers. We have identified our two primary building blocks, namely Durable Functions and Container Instances.In the next section, we will see how to infer a reference architecture from these preliminary conclusions.

Building the target reference architecture

With this progress, you are ready to build your reference architecture. Of course, there is never a one-size-fits-all approach, but Figure 2.27 shows you a possible solution:

There are small numbers on the diagram that we explain as follows:

1. Azure Blob Storage, part of a Storage account, receives the incoming blobs to be treated by the workflow. These are the large files we referred to in our scenario.
2. A durable client, with blob storage trigger, is kicked off whenever a blob lands into the blob storage. The durable client starts a new orchestration, while passing some orchestration configuration (such as the number of steps, retries, timeouts, and so on).
3. The main orchestrator, which could have sub-orchestrators, in turn provisions one container instance per workflow step, and passes a callback URL that is used by ACI to report its status and to optionally return a pointer to the input data of the next task. An alternative to using a direct callback URL could be to put a message broker between the orchestrator and the ACIs. The orchestrator could queue commands in a Service Bus or Storage Account queue and ACIs could handle those commands and report their status using queuing as well.
4. ACI gets the input blob that it needs to handle.
5. ACI writes output to another Blob Storage.

The overall process contains one or more steps, and each step is allocated a dedicated ACI with the required compute, which could be decided dynamically based on the size of the input blob. Each task may execute in parallel or one after the other, depending on the orchestrator logic. Figure 2.28 is an example of a sequential workflow that could match our scenario:

The main orchestrator starts with one sub-orchestrator per workflow task. Each task creates a container instance and waits for its feedback through the WaitForExternalEvent operation (or using queue-based mechanisms). The Durable Functions framework allows you to define retries and timeouts. Whatever the workflow step status is (such as failed or timed out), the corresponding ACI is deleted, and the main orchestrator either retries, stops the orchestration, or goes to the next step according to the passed worklow configuration that is dynamically by the orchestrator client.Note that the exact same workflow logic could be defined with Logic Apps, which is also able to orchestrate the creation and deletion of ACIs, but considering a pure .NET team, they will likely prefer to use Durable Functions. Now that we have some sort of reference architecture, let's see what is still missing.

Understanding the gaps in our reference architecture

We may think we did a great job earlier when designing our reference architecture, but it suffers from important gaps. Look again at Figure 2.29:

We have not covered the cross-cutting concerns. We mostly focused on the building blocks and their interactions, but we did not cover anything about monitoring, security, resilience, and so on. Sometimes, it can be challenging to reflect everything in a single diagram, because it makes that diagram either too big or too complex to understand. To overcome this, a possibility is to work with different views, scoped to specific areas. Doing so will also help you engage with your peers, as well as with more specialized architects.The Solution Architecture Map cannot go too deep into each domain, because it would simply be too broad. Using this map only to cover all the NFRs is not possible. As a Solution Architect, you will also need to refer to other maps in this book to find your way in other fields and you'll perhaps also need to ask for extra help from infrastructure and security architects. The views that should be added to this architecture are as follows:

• Monitoring view: This is where you add Azure Monitor, Log Analytics, and dashboards into the mix. You might have to add Splunk or any other on-premises tool that your organization (or your customer) is using.
• Security view: This is where you indicate the different authentication mechanisms, such as Shared Access Signature (SAS) tokens, managed identities, OAuth flows, and so on to authenticate against Blob Storage as well as to create and destroy ACIs. You would add protocol-related information (TLS 1.xx, etc.). The security map in Chapter 9, Security Architecture, will help you here.
• High-availability and disaster recovery views: Here, you focus on the availability and resilience of your solution. The infrastructure map of the next chapter will help you here.

As mentioned earlier, we started with the basics, but the complexity will gradually increase as we progress in this book. Before wrapping up this chapter, let's examine some real-world insights into trends and practices that have emerged over the past few years..

Looking at the hybrid connectivity options

Many enterprise customers using Azure operate in hybrid environments, where some workloads remain on-premises while others run in Azure. In some cases, individual workloads span both environments, with components deployed both in the cloud and on-premises. As a result, it's essential to establish connectivity between on-premises data centers and Azure. The DC Connectivity node of Figure 3.3, illustrates various options for achieving this.

Microsoft positions ExpressRoute (ER) as a key network enabler for hosting mission-critical workloads in Azure. ER is considered the best choice primarily because it offers predictable latency, allows precise control over bandwidth consumption, and supports priority management through Quality of Service (QoS), all made possible by its foundation on the physical layer. ER is also globally accessible through Cloud Exchange Brokers, with whom organizations often already have established connections, making it easier to extend their network to Azure. Additionally, ER offers several resilience models to accommodate varying levels of redundancy and availability. The Single-Homed model connects to a single high-available ExpressRoute circuit in one peering location, providing minimal redundancy and making it suitable only for non-critical workloads. The Dual-Homed model improves fault tolerance by connecting to two independent circuits in different peering locations, ensuring continued connectivity even if one site experiences failure. The Dual-Homed Metro model strikes a balance by leveraging two circuits in separate facilities within the same metropolitan area (for example: Amsterdam), offering higher resilience than Single-Homed while maintaining lower latency and simplified management compared to full Dual-Homed deployments. Because these hybrid connectivity models are essential foundations, you should make sure to anticipate on your Cloud roadmap and the business pipeline to make the right decisions.On the other hand, Site-to-Site (S2S) VPN is mostly used in small-scale production workloads, in terms of hybrid traffic.Besides an S2S VPN, you can also use a point-to-site (P2S) VPN, but this is typically used to allow external collaborators to access resources hosted in your Azure environment. For example, you may use Azure Virtual Desktop (AVD) to give access to external collaborators who should setup a VPN client on their machine prior to accessing the AVD machines.Chosing between S2S VPN or Expressroute is not always easy but here is a use case table that should help you (Note that + means preferred option):

Table 3.1 – Comparison table between ExpressRoute and S2S VPNRegardless of whether you use ExpressRoute or a Site-to-Site VPN—and depending on your chosen resiliency model—it's important to plan for a break-glass access method to your Azure workloads. Azure Bastion provides a secure and reliable way to achieve this. Azure Bastion is accessible directly from the Azure Portal and enables secure connections to your virtual machines without requiring public IP addresses or exposing RDP/SSH ports. While it can be useful for routine access, it becomes especially valuable in adverse scenarios where traditional connectivity paths are unavailable.Once you have bridged the two worlds – on-premises and Azure – you must concentrate on how to route and organize traffic within Azure itself, which is what we will look at in the next two sections.

Looking at the most common architectures

Let's start exploring the most common architectures illustrated in Figure 3.5.

Let's start with the Hub and Spoke Architecture.

Hub and Spoke Topologies

As we briefly described in Chapter 1, Getting Started as an Azure Architect, the Hub and Spoke architecture, presented in Figure 3.6, is the most frequent hybrid setup:

At the bottom of Figure 3.6, we have the on-premises network that is connected to a single Azure Hub through either ExpressRoute or VPN or sometimes both at the same time, with a IPsec overlay. The Azure Hub is itself connected to the different spokes, in which assets are deployed.The Azure Hub is nothing but a regular Azure Virtual Network (VNET). Its role is to route traffic between spokes (east-west) and between the on-premises and cloud data centers (hybrid traffic north-south). Spokes, which are simply VNETs, are peered with the Hub to allow mutual awareness of each other's address space—enabling the Hub to recognize each Spoke's address range and vice versa. VNET peering is non-transitive in Azure, meaning that if spoke 1 is connected to spoke 2 and 2 is connected to 3, then 1 cannot talk directly to 3 as illustrated by Figure 3.7.

Consequently, the Hub and Spoke architecture is used to simplify the structure and to have a central VNET (the hub) that is connected to all the others as a way to bridge them all. Additionally, the hub might even deal with Internet Ingress and Internet Egress, also known as north-south type of traffic.Peering spokes directly is also technically possible, but goes against the purpose of the Hub and Spoke topology. VNET peering is global, meaning that you can peer a VNET that sits in the West US region with another one sitting in the West Europe region, but beware that cross-regional peering incurs extra outbound traffic costs. Each spoke usually hosts the services of one single asset, while the shared system services (DNS for instance, as highlighted in our previous section) are hosted in the hub.Besides the basic single hub architecture, you might want to split hubs further into a multi-hub architecture. As you may have understood by now, virtual network peering is a powerful way to bring network capabilities to a spoke. However, centralizing all network functions—including east/west and north/south traffic—into a single hub automatically extends these capabilities to connected spokes, making it unclear what type of traffic each spoke truly needs. A security breach could also have a larger and more difficult-to-contain blast radius, as changes to the central firewall may affect other spokes. Additionally, removing a spoke's peering immediately strips it of all capabilities—including operation channels leveraging on-premises connectivity—unless an out-of-band management process is in place. In security-driven organizations, working with a single hub might fall short. It is therefore interesting to look at multiple alternatives that enable a better segregation of duties between the hubs. One such example is the so called Double-Hub architecture, shown in Figure 3.8:

In the Double-Hub architecture represented in Figure 3.8, we have two hubs, namely the hybrid hub and the ingress hub. Each hub deals with its own duties. The ingress hub handles internet-facing traffic and includes services like web application firewalls and standard layer-4 firewalls. Internet facing assets hosted in online landing zones (Online Archetype), are peered with both the ingress hub and the hybrid hub, whereas corporate application (Corporate Archetype), are only connected to the hybrid hub. This Double-Hub architecture ensures that all inbound internet traffic flows through the ingress hub, preventing spokes from directly exposing public-facing components—a restriction that can be enforced using Azure Policy. This architecture simplifies the separation of internet-facing and internal workloads by allowing quick identification through peerings with the ingress hub. It also minimizes the blast radius in case of a firewall misconfiguration and enables swift isolation of any workload from the internet by simply removing its peering with the ingress hub.Yet, the hybrid hub still deals with multiple duties, such as managing east-west traffic across spokes, internet egress traffic as well as hybrid traffic (from on-premises to the Cloud and vice-versa). To take it a step further, you can leverage the Triple Hub architecture, as shown in Figure 3.9:

The Triple Hub architecture keeps using the ingress hub for internet-facing workloads but ensures that outbound internet traffic is routed through a dedicated egress hub. This egress hub is equipped with a firewall, which can optionally forward traffic to zero-trust and Cloud Access Security Broker (CASB) players like Netskope that can handle traffic filtering, enforce access policies, and ensure Data Leak Prevention (DLP). Yet, the hybrid hub still deals with multiple duties, such as managing east-west traffic across spokes as well as hybrid traffic.To take it a step further, you can leverage the Quadruple Hub architecture, as shown in Figure 3.10:

The Quadruple Hub architecture ensures that each hub is dedicated to a specific function: the ingress hub handles inbound internet traffic, the egress hub manages outbound internet traffic, the hybrid hub is reserved for hybrid connectivity, and the newest addition—the integration hub—is responsible for enabling spoke-to-spoke communication. The underlying objective remains unchanged: to minimize the blast radius of any security breach or misconfiguration, ensure clear visibility into the network capabilities assigned to each workload, and maintain the ability to selectively and precisely disable those capabilities when necessary. You might have noticed that in each of the four topologies we explored, all the spokes and the hub themselves were peered to the hybrid hub regardless of the landing zone archetype. This is required to be able to operate/manage/deploy workloads to the spokes and the hubs themselves. This makes the hybrid hub deal with both application-level and management-level hybrid traffic.Regardless of the topology you adopt, it's important to separate production from non-production environments—typically by replicating the chosen architecture in both. Some organizations take this a step further by using separate Entra ID tenants for production and non-production to enhance isolation. Here is a comparison table to help you choose the best topology (single hub versus multiple hubs) for your specific needs.

	Single-Hub	Multi-Hub
Scalability	-	+
Security	-	+
Blast Radius	-	+
Observability	-	+
Manageability	-	+
Multi-region	+	-
Costs	+	-

Table 3.1 – Single-Hub vs Multi-Hub ArchitectureMulti-hub architectures offer significant benefits for security-focused organizations. However, they come with substantial costs and can become increasingly expensive, especially when extending across multiple regions. This type of topologies mostly apply to financial institutions, insurance sector, etc. This would definitely not be suitable for smaller organizations with limited budgets. We wanted to demonstrate that the real world often extends well beyond what's covered in online documentation.Now that we've explored hub-and-spoke topologies, let's shift our focus to how you can implement them.

Looking at the routing options

Based on the previous section, the ability to route both east-west and north-south traffic between a source and a destination is a fundamental requirement. The routing node of Figure 3.12 highlights the routing options and mechanisms available in Azure to support this.

Azure creates system routes by default. This type of routes cannot be deleted but can be overridden. Let us first take a concrete example to understand how they work. Let's imagine we create the following virtual network with two subnets and one virtual machine in each subnet:

All virtual machines (and PaaS components) will use the default route shown in Figure 3.13 when targeting either of the subnets, because both subnet ranges belong to the default prefix that was advertised by Azure. By default, every component of a given virtual network will leverage the virtual network next hop type when connecting to any other component of that virtual network. Similarly, when we peer our VNET with another one, an additional route is propagated, as shown in Figure 3.14.

We see that this time, a new route leveraging the VNet peering next hop type is created to let both virtual networks know about each other's address space.Numerous other network-related events can trigger the creation of additional system routes. Additionally, other default system routes are created by default but we wanted to keep things simple and focus on basic examples. However, the main point to remember is that, unless explicitly overridden, system routes are always used by default and cannot be deleted. To override this default behavior, we must advertise either Border Gateway Protocol (BGP), or User-defined Routes (UDR) routes. Back to our initial example, we might choose to route intra-VNet traffic through a firewall. In other words, we may want to enforce firewall inspection or validation for communication between subnets. This requires us to modify Azure's default behavior by overriding system routes, as shown in Figure 3.15.

As shown in Figure 3.15, the addition of a new route of type User telling Azure to send traffic destined for 192.168.0.0/24 to 192.168.1.4 (our firewall), causes the system route to be marked as Invalid. This means that whenever A tries to connect to B, it would first go to the firewall, which should allow or deny this type of traffic. We'll cover BGP routes later in this section, but for now, we hope that these basic examples helped you understand how Azure's routing behavior works.UDRs are commonly used to override system routes but it can be tedious to manage them at scale, and that is where Azure Virtual Network Manager (AVNM) comes to the rescue. This versatile service allows you to define default routes that are propagated to virtual networks that match the routing rule policies. This is also a way to enforce a default standard, which can be controlled further using Azure Policy. When using Azure Virtual WAN, a common practice is to define routing intent, for public and/or private traffic and let VWAN advertise these routes automatically to every spoke connected to the virtual hub.At last, BGP is a well-known protocol used to exchange routing information between different autonomous systems and is aimed at determining the best possible data path to connect systems. Azure Route Server, acts as a BGP peer and allows to dynamically exchange BGP routes between Azure virtual networks and NVAs automatically. No matter how you manage routes, keep in mind that system routes are present by default, and only routes that are equally or more specific—whether from BGP or UDRs—can override them. Also keep in mind that UDRs always take precedence over the other route types.Now let's dive into DNS, a system capability just as crucial as connectivity and routing.

Looking at the DNS options

DNS in Azure is a critical topic and serves as a fundamental building block. Figure 3.16 illustrates the available options.

In Figure 3.16, public and private DNS are clearly differentiated. Public DNS management can be delegated to Azure through DNS zones, which are global, highly scalable, and support automation. This enables Azure to handle tasks like domain validation for public certificate management and ensures seamless integration with other Azure services. Private DNS Zones provide similar benefits but are designed for custom private domains like for example contoso.internal. They also enable the privatization of PaaS services by leveraging private endpoints via Azure Private Link (APL).It's worth taking some time to understand how APL works, as it's not entirely straightforward. To privatize a PaaS service, such as Azure Service Bus, you need to enable APL directly on the service. This action prompts Microsoft to create an alias that points to the associated private link domain. So for example, if you enable APL for contososb.servicebus.windows.net, Microsoft, as the authoritative party, will add this alias record contososb.privatelink.servicebus.windows.net into its public DNS. From that point forward, clients without access to the private DNS zones will resolve the service to its public IP, while those with access will receive the private endpoint in the DNS resolution. Figure 3.17 illustrates this.

In Figure 3.17, both clients—the VM within the VNet and the one outside—attempt to resolve the same FQDN: contososb.servicebus.windows.net. The VM outside the VNet receives the public IP address because it doesn't have visibility into the private DNS zone. In contrast, the VM inside the VNet first queries 168.63.129.16, a non-routable IP used by Azure DNS as the primary resolver within each VNet (unless specified otherwise as we'll see in the next section). Since Azure DNS is aware of the Private DNS Zone attached to the VNet, it returns the private IP that matches a A record. If the private DNS record is unavailable, the Private DNS Zone can be configured to return the public IP as a fallback, by enabling the NxDomainRedirect property.However, because conditional forwarding is not supported with private DNS zones, we need an additional service to resolve private Azure DNS from on-premises to Azure and vice-versa. This is where we can either use DNS Private Resolver or a third-party vendor such as Infoblox. The most common DNS architectures are centralized and distributed. In a centralized model, all DNS queries are directed to a central hub where the Private DNS Zones are attached. In a distributed model, each spoke has its own DNS zones attached locally. Since these two approaches are not mutually exclusive, a hybrid architecture is also possible—where zones are linked to the hub as well as to the spokes (or a few spokes only). Figure 3.18 is a very simplified view of what a centralized DNS architecture looks like.

All spokes route DNS queries to the inbound endpoint of the DNS Private Resolver. For Azure-specific domains, the resolver delegates to Azure DNS. Non-Azure queries are handled based on the DNS forwarding ruleset, which specifies where to forward the requests—for example, to on-premises DNS servers for corporate domains. When it comes to resolving Azure domains from the on-premises environment, the on-premises DNS servers must be configured with conditional forwarding to direct Azure-related queries back to the DNS Private Resolver's inbound endpoint. From a connectivity standpoint, the on-premises DNS servers must be able to reach the inbound endpoint, while the DNS Private Resolver's outbound endpoint must be able to access the on-premises DNS servers and any external (non-Azure) DNS infrastructure if required. Notably, Azure Firewall can function as a DNS proxy. In this setup, both spokes and on-premises DNS servers forward their DNS queries to Azure Firewall, which then relays them to the DNS Private Resolver's inbound endpoint. This approach represents the most optimal architecture when exclusively leveraging Azure-native services, as you have full control over DNS-related traffic and you can leverage Azure Firewall logging capabilities.Now, let's see how to monitor our workloads.

High Availability

Figure 3.28 is a zoom-in on HA in Azure:

Most Azure regions offer three Availability Zones—physically separate data centers, each with independent power, cooling, and networking. If one data center goes down, the remaining two maintain service continuity. Availability Zones support ACTIVE/ACTIVE scenarios natively, without requiring any manual failover or failback from the cloud consumer. However, this doesn't mean there will be zero impact. For instance, existing connections to data stores may be disrupted, and load balancers might take a moment to detect unhealthy backends. So, while no infrastructure-level action is needed, your application should still be designed to gracefully handle any exceptions that may arise from a zone failure.A roundtrip between two Availability Zones typically adds around 2 milliseconds of latency. While this is generally acceptable, it might not meet the needs for workloads requiring ultra-low latency. In such cases, alternative options like Availability Sets and Proximity Placement Groups should be considered. Availability Sets ensure that VMs are distributed across different racks to improve availability, whereas Proximity Placement Groups prioritize minimizing latency and may or may not span multiple racks. If low latency is more critical than high availability, Proximity Placement Groups is a better choice; otherwise, stick with Availability Sets.Most PaaS services support zone-redundancy. For some, it's an all-or-nothing approach—enabling zone-redundancy means at least one instance per zone, which can increase costs. Others offer more flexibility, allowing you to select specific zones (for example, just two), which can help reduce the financial impact. Another approach to achieving HA is through Auto Scaling—either by using Auto Scaling Plans for PaaS services or Virtual Machine Scale Sets (VMSS) for IaaS. VMSS allow you to define scaling boundaries, such as maintaining a minimum of two instances (one per zone) at all times, while dynamically adding more during peak loads. This helps strike a balance between availability and cost efficiency.Most data services in Azure support zone-redundancy at a minimum, and some even offer geo-replication for added resilience. When designing solutions, it's essential to align the compute and data layers—there's little value in deploying zone-redundant compute resources if they rely on a non-redundant data store. For instance, running three API instances on a zone-redundant App Service plan that all target a Storage account using Locally Redundant Storage (LRS) would be a clear design flaw. Ensuring consistency between tiers is key to achieving true high availability.Let us now explore the various features available to ensure Disaster Recovery.

Disaster Recovery

Figure 3.29 shows the available options to ensure Disaster Recovery.

To keep things concise, we'll focus on the key topics and critical decision factors you should be aware of as an Azure Infrastructure Architect. You can explore the rest of the Disaster Recovery group at your own pace.When it comes to Disaster Recovery, we must decide to deploy workloads to at least two regions. The following table outlines potential strategies for two-region deployments, along with their respective advantages and disadvantages:

Table 3.2 – Multi-region deployment strategiesNo matter which strategy is selected, implementing a multi-region solution introduces substantial complexity—particularly when it comes to data management. Most data services propose a geo-replication feature that allows you to select regions in which data should be replicated. You should always look at the replication model as it may vary from one service to another. Here are the key critera to consider with regards to replication:

• Does the service support write/write or read/write only?
• RTO and RPO?
• How do you failover?
• Is the failover process initiated by Microsoft or yourself?
• What is the risk of data loss?
• How long does it take to have the secondary region fully online and usable in read/write?
• Does the service perform a full or partial replication? For example, Azure Service Bus historically only replicated entities (such as queues, topics, and subscriptions) but not the actual messages themselves. At the time of writing this book, the service has a geo-replication feature in preview, that allows to choose whether to replicate data synchronously or asynchronously, balancing between performance and reliability.
• What are the available consistency models (strong, eventual, session)?

Many of these questions involve intricate dependencies and cannot be addressed without comprehensive upfront analysis and architectural planning. At last, because Azure isn't for the faint of heart, other types of replications exist, such as the ones proposed by Azure Storage:

Table 3.3 – Azure Storage replication options

Important note

GRS, G-ZRS, RA-GRS, and RA-GZRS are replication options that are only supported fully by historical regions such as West Europe and North Europe. Newer regions such as Sweden Central and Sweden South only partially support it and even newer regions do not support them at all anymore. This means that you should define a workload placement strategy that is aligned with the intrinsic region capabilities and with RTO/RPO requirements.

In addition to the compute and data replication, you must also foresee backup and restore processes to recover from a data corruption, accidental data loss, or randsomware attacks. Keep in mind that this is a fundamental aspect of disaster recovery that applies universally, regardless of the deployment model (single-region, multi-region, etc.). You must always ensure the ability to restore data under any circumstances! To keep things concise, we can say that PaaS data services mostly feature two types of backups: Continuous and Long Term Retention (LTR). Continuous backups are built into the data service itself. They typically support Point-in-Time Restore (PITR), enabling you to recover data from any moment between a defined start time – often below 40 days – and the present. Time windows vary from one service to another. In contrast, LTR backups, also built into the data service itself, support extended retention policies—up to 10 years in services like Azure SQL. These backups are stored in Azure Storage, which can also be geo-replicated using GRS, when available.Additionally, Backup Vault and Recovery Services Vault are distinct backup solutions that enable backups for various types of resources. Furthermore, some PaaS offerings—such as Azure API Management—provide API endpoints for backup/restore or import/export operations. These processes are often automated using Logic Apps.Sometimes, some workloads go beyond typical resource needs, and require much more power. HPC, our next topic, is a possible answer to this.

First analysis

For this use case, inspired from a real-world situation, we will only analyze and explain a solution diagram that should satisfy Contoso's requirements.Let's first extract the keywords in this scenario that demand our focus:

• RTO of <= 30 min: An RTO of 30 minutes is an aggressive target. Earlier in this chapter, we discussed the different disaster recovery strategies and we know that redeploying assets in case of outage is feasible but represents a risky strategy because resources might not be available at the time of re-deployment. Moreover, in this context, achieving a 30-minute RTO would imply the ability to redeploy the entire workload from scratch within that timeframe—an expectation that is largely unrealistic. Consequently, the focus should shift toward ensuring system resilience without requiring redeployment. Leveraging Availability Zones becomes essential to distribute workload components across at least two zones, thereby enhancing fault tolerance within a region. However, given that Contoso cannot tolerate prolonged downtime for all marketplaces in the event of a regional Azure outage, a multi-region deployment strategy must also be considered to ensure continuity at scale.
• Geo-proximity: Contoso wants to make sure marketplaces are served by the closest API. This implies an ACTIVE/ACTIVE multi-region setup.
• RPO of <= 15 minutes: The RPO is also an aggressive target, especially for an ACTIVE/ACTIVE multi-region setup. This potentially restricts our possibilities in terms of data stores we can use.
• North America and Europe: These are the first two regions considered by Contoso, which means that we are restricted to those geographies in Azure too.

After a deeper analysis and discussions with Contoso, we realized that the following services are in line with the requirements:

• Azure Front Door, a global service with hundreds of points of presence worldwide, is an ideal candidate to distribute traffic across the two geographies as well as the third one to come (Asia) in the near future.
• Azure API Management can be used to manage APIs exposed to both marketplaces and member organizations and is also able to span multiple regions.
• Azure App Service can be used to host the backend service code. It is a robust, mature, and cost-friendly option. It does not have any multi-region feature but app services could be deployed separately to multiple regions along with the application code. Additionally, Azure App Service also supports Availability Zones, which allows us to distribute regional instances across different zones.
• Cosmos DB's global distribution is a perfect fit for this scenario as it not only directly covers Europe and America but can easily be extended to other regions later on. Depending on the chosen consistency model, Cosmos DB's continuous backup allows us to restore containers and databases with an RPO of <=15 minutes, as expected by Contoso. Additionally, the Cosmos DB Client SDK is designed to automatically detect region unavailability and switch seamlessly between regions in case of regional outages. Contoso could also take advantage of Cosmos DB's change feed feature to react easily to new product information being pushed by member organizations, which opens doors for further application growth.

Drawing board and detailed explanations

Now that we have identified the different services that meet Contoso's requirements, we return to the drawing board and arrive at the following high-level diagram:

We'll begin by analyzing the high-level architecture diagram from left to right, which outlines the flow of an API call initiated by either marketplaces or member organizations. In the following sections, we'll break down this diagram into smaller parts to explore each segment in greater detail.In Figure 3.33, dotted arrows depict the API call flow from European marketplaces, while solid lines represent the flow from North America, following Contoso's geo-proximity-based design under normal operating conditions. In the event of a regional failure, traffic may be rerouted—EU to US or vice versa. Azure Front Door's latency-based routing algorithm facilitates this behavior by default, directing requests to the nearest available backend and automatically failing over to the alternate region if the primary is unavailable.Next component inline is a premium instance of Azure API Management with multi-region and zone-redundancy enabled. With both, zone-redundancy and multi-region, the solution is resistant to both, zone-level and region-level failures. Losing a single zone might not even cause any visible disruption. In Figure 3.33, APIM's primary region is West Europe with 3 gateway units (one per zone), while the secondary region is North Central US also with 3 gateway units. In case the master region is lost, the secondary region's gateway units will still be able to perform correctly but APIM's management plane will not be usable anymore. This means that deploying new APIs or changing anything in APIM's configuration won't be possible until the master region is back. Additionally, APIM is also used to manage API versions exposed to marketplaces and to enforce API policies such as JWT token coarse-grained validation, etc.Next component in line is the Azure App Service, which hosts the backend services, where the application code is deployed. The underlying App Service plan must also be made zone-redundant to have a consistent behavior. The application code should also re-validate JWT tokens and optionally perform additional fine-grained validations.Finally, a single Cosmos DB account configured with both West Europe and North Central US as active write regions (multi-master mode) and zone-redundancy, ensures best in class resilience. Combining multi-region writes with session consistency aligns well with the expected RPO requirements.Now that we analyzed the high-level flows and the role of each component in this architecture, let's zoom deeper into each part of the diagram and start with Front Door.

Front Door works with endpoints, which must be mapped to public domain names. In our case, products.contoso.com must be mapped to the endpoint <frondoor-prefix>.azurefd.net by defining as an alias DNS record in the Contoso domain. We can even use Azure DNS zones to manage our public domain. Note that this is usually never the case in the enterprise world but it is technically feasible. Next to each public Fully Qualified Domain Name (FQDN), there is a certificate, which can be entirely managed by Front Door. Azure Front Door-managed certificates are issued by DigiCert in a fully automated way, provided we use Azure DNS for your public DNS. When using our own domain provider, as the domain ower, we still have to validate ownership through defining a TXT record into our environment. Alternatively, we can bring our own certificate, store it in Azure Key Vault, and define a Front Door secret that points to the Key Vault. In this case, Front Door's managed identity must be granted the Key Vault Certificate User role to pull the certificate from Key Vault.Next, we must define an Origin Group, which is some sort of backend pool. In our case, the backend pool is made of the gateway units deployed to West Europe and North Central US. API Management exposes one load balancer per region. The three US gateway units are behind contoso-apim.northcentralus-01.regional.azure-api.net and the three EU units are behind contoso-apim-westeurope-01.regional.azure-api.net. APIM also provides a region-neutral DNS name, contoso-apim.azure-api.net, which uses Azure Traffic Manager behind the scenes to redirect traffic to the appropriate regional backend. This FQDN can be specified in the Origin Group instead of the regional ones. However, making such a choice causes APIM to take responsibility for ensuring that marketplace API requests are correctly routed to the corresponding region. Working with regional backends instead, causes Front Door to take responsibility, which gives us full control over the routing algorithm.In our diagram, we opted for the latency-based algorithm by setting a value of 0, which means that Front Door should always pick the fastest backend. Next, we defined a route by mapping products.contoso.com to the Origin Group. One tricky aspect to be aware of is health probing. APIM exposes a specific endpoint, /status-0123456789abcdef, to indicate its own health status. However, this endpoint does not reflect the health of our underlying APIs but rather the APIM gateway one—so APIM might report as healthy even when our APIs are not. Relying on this endpoint for Azure Front Door health checks can be misleading, as Front Door could continue routing requests to unhealthy backends. A better approach is to implement a custom status endpoint via an APIM policy that checks the actual API backend health, and have Front Door call it using an API key in the query string. We must make sure to always use the HEAD HTTP verb to minimize bandwidth consumption incured by the probing. At last, Front Door is not only used to route traffic to the closest backend but also to inspect incoming traffic, thanks to WAF policies that can be associated to the endpoints. This is necessary because, although APIM can enforce various security controls, it does not include a built-in Web Application Firewall (WAF).Let us now take a closer look at APIM and the backend services, the next components in our design.

Figure 3.35 only shows the primary region but the secondary region is configured the same way. At the time of writing this book, it is not yet possible to use the Private Link Service (PLS) between Azure Front Door and APIM premium, which means that APIM cannot be totally isolated from Internet. This is why our APIM instance is integrated with a virtual network in external mode, causing its exposure to the internet through a public IP (hence the warning sign in the design). It is nevertheless possible to restrict access to our Front Door instance by combining Network Security Group rules with the validation of the X-Azure-FDID HTTP header. Front Door systematically adds this HTTP header with its own unique instance identifier, making sure we know it is our Front Door calling. If you are ever confronted to such a design in the future, you should double-check if Front Door can take APIM as a full private backend through PLS, as it would be an even better option.As stated earlier, we enabled zone-redundancy as well as multi-region for our APIM premium instance and we enforced multiple security controls using policies. An important aspect to consider is that you must explicitly define the target backend (West Europe or North Central US) using the set-backend policy. This is due to APIM using a single configuration across both regions, which means we can't hard-code a backend service URL—doing so would cause all gateways (EU and US) to route traffic to the same backend, regardless of region.For the backend services, we use multi-tenant App Service plans to minimize costs and complexity. However, this forces us to integrate with the virtual network using private endpoint on the one hand, and virtual network integration on the other hand. Enabling private link for our app service allows us to deny public traffic and let APIM call the backend service through its private endpoint. We need outbound virtual network integration because, in turn, our backend must call Cosmos DB that is also isolated from the internet. This requires a dedicated subnet delegated to Microsoft.Web/serverFarms. Our single web app (but 1 instance per Availability Zone for a total of three instances) spans two subnets, one for the inbound traffic and one for outbound. Here again, we can enforce NSG rules to restrict access to APIM only.Lastly, let's have a closer look at our data layer, namely Cosmos DB.

First of all, we deny public access at Cosmos DB level, enable Private Link (as explained earlier in the DNS section), and deploy private endpoints into reach regional subnet. This allows the backend (App Service) to talk to the private endpoints, thanks to the virtual network integration. Interestingly, we end up with three private endpoints in each side. This is due to how Cosmos DB clients establish connections to Cosmo DB. The generic FQDN contosoproducts.privatelink.documents.azure.com is required by the client SDK. Additionally, the client code can indicate a preferred region, which in this case requires the presence of contosoproducts-westeurope.privatelink.documents.azure.com for the code running in West Europe and contosoproducts-northcentralus.privatelink.documents.azure.com for the code running in North Central US. In case of unavailability of the local region, the SDK is smart enough to automatically switch to the other region for both reads and writes, which in this case, causes a performance degradation incurred by the cross-region roundtrip. However, despite the performance impact, the solution is highly resilient at both the infrastructure and application levels. Regarding the RPO, we can leverage Cosmos DB's continuous backup feature, which supports an RPO of ≤15 minutes in a multi-region write setup with session consistency. However, additional effort is required at the Cosmos DB level to ensure the data model is designed to accommodate the read/write ratio and achieve an even distribution across logical partitions—this is essential for maintaining performance, scalability, and avoiding hot partitions.This use case demonstrated how to take advantage of built-in PaaS resilience by leveraging service-level features such as zone redundancy, multi-region support, and backup/restore capabilities. However, it's important to note that not all PaaS services offer the same level of resilience, and achieving a fully consistent, disaster recovery-compliant solution can be quite challenging when integrating multiple PaaS services within a single architecture. Let us now explore a pure IaaS use case.

First analysis

Let's review the keywords in this scenario that demand our focus:

• Security-driven: When security is embedded in a company's DNA, we naturally think of strong Identity and Access Management (IAM), comprehensive auditing, advanced encryption mechanisms, and a solid network security foundation. In this use case, however, we'll focus exclusively on the network aspects. We'll revisit this scenario in Chapter 9 to incorporate additional security elements into the architecture.
• Online and corporate archetypes: This clearly indicates that Contoso will deal with internet-facing assets as well as internal workloads.
• Segregation and quarantine: The initial keywords combined with these new ones, clearly point towards a multi-hub architecture.

In the networking section of this chapter, we explored various Hub & Spoke topologies and emphasized that assigning specific responsibilities to each hub, and peering spokes according to their needs, helps minimize the blast radius in case of misconfigurations or security breaches. While the Quadruple Hub model offers maximum separation of duties, Contoso has not explicitly required a dedicated egress hub or integration hub. Therefore, we'll go with the DualHub architecture—also keeping in mind cost-efficiency when you test this in your own tenant.

Drawing board and detailed explanations

After a few exchanges with Contoso, we agreed on building a small proof of concept with one online and one corporate archetype. We went to the drawing board and ended up with this diagram:

Let us decompose this diagram. There are a lot of NOT IMPLEMENTED mentions in the diagram because this is how we would typically design such an architecture but the provided code will not deploy these components for the sake of cost savings in your tenant. Let's dig into the details from left to right.The first component of the ingress hub is Application Gateway, which acts as a reverse proxy and WAF. The Application Gateway takes the web application sitting in the Online Archetype spoke as a backend pool. The traffic from Application Gateway is sent to the Azure Firewall of the ingress hub through the use of a route table. We see two destinations: 10.0.0.0/24 (intra vnet) and 10.10.0.0/26 (spoke). These routes are required to override the default system routes made available by the peering, and make sure traffic is routed to the firewall. The ingress firewall has an Application Rule defined to let the Application Gateway subnet talk to the inbound subnet of the web application in the online spoke. Note that application rules enforce Source Network Address Translation (SNAT) by default, which means that the destination will see the firewall IP instead of the actual source (Application Gateway in this case). Figure 3.38 is a focused view on the flow that we just described:

For sake of simplicity and demo purposes, communication is done over port 80. In the real world, this would of course be restricted to port 443 and TLS >=1.2 would be enforced. Additionally, we would order a public certificate or let Azure manage this for us. Next, a usual suspect in an ingress hub could be an instance of API Management for APIs that are exposed to external customers.Next hop is the Online Archetype, peered to our ingress hub, where we have a single web application that is behind a private endpoint and integrated with an outbound subnet to route traffic to the private perimeter. For a real application, the web app would probably talk to a database or any other data store for which the private endpoint would be in the data subnet. We make sure the inbound subnet is sensitive to NSG rules and custom user-defined routes by enabling specific network policies at the level of the subnet. We restrict traffic to the Azure Firewall by adding a specific allow rule and a deny all rule to block everything else. We apply a specific route table to the outbound subnet to send all traffic to the Main Hub's firewall through a 0.0.0.0/0 rule. Note that this rule does not override system routes brought by the peerings. We must define the target destinations of the webapp in the Main Hub's firewall if any.Next the Corporate Archetype is an empty shell but is there to show that we only peer it to the Main Hub, unlike the Online Archetype, which is peered to both hubs. Should we have a real application hosted there, we would also add the required route tables to make sure east-west and nort-sourth traffic is sent to the Azure Firewall of the Main Hub.Finally, we've enabled Private Link for the web application. The Private DNS Zone privatelink.azurewebsites.net contains the web app's record and is currently linked to all virtual networks. In a real-world setup, we would typically link this zone only to the Main Hub and configure the other virtual networks to forward DNS queries to the shared DNS service in the hub (for example, Infoblox, DNS Private Resolver, etc.). Let's now explore how you can deploy this architecture in your own tenant.

Deploying and testing the solution in your tenant

Important note

To simplify testing in your own tenant, all resources are deployed within a single resource group. This use case focuses on networking and firewalling—specifically, how to peer landing zone spokes based on the desired network capabilities and how to involve the corresponding firewall. In the real-world, you should also adhere to your company-specific governance.

To test this code in your own tenant, you must have the following:

• An Azure subscription with Owner permissions. If needed, folllow this link to start a new trial: https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account.
• Install Azure CLI. Follow the instructions available here: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli.
• Install Terraform. Follow this link https://developer.hashicorp.com/terraform/install where you can find binaries for all operating systems. This only takes a few minutes!
• Make sure the terraform command works and is known in your system. In other words, make sure the PATH environment variable points to the location where you downloaded the Terraform client.
• Clone the map book repo or download the code.
• Open the cloned/downloaded repository with Visual Studio Code.
• Navigate (cd) to this folder: Chapter 3\use-cases\IaC.

Before you can deploy the code, you must make sure the Microsoft.Network and Microsoft.Web resource providers are enabled in your subscription. To enable a resource provider, go to your subscription, look for the provider, and enable it, as illustrated in Figure 3.39:

Before deploying the code, let's have a quick look at it and focus on the important bits. The entire configuration is passed through the config.yaml file:

In this configuration file, you must make sure to replace both the backend-prefix and the destination-fqdns attributes. In the default provided file, values for those settings are constoso-mapbook and contoso-mapbook.azurewebsites.net, respectively. You must change these values to something unique because Azure enforces unique names worldwide for PaaS resources like Azure App Service. If I had to run this example myself, I would use my trigram - sey-contoso-mapbook - to guarantee uniqueness. Additionally, you can also change the location. We used swedencentral but feel free to chose a location that is closer to you.Here is the folder structure of the solution:

A few Terraform modules are provided. The main.tf file is where we parse the provided configuration file and call our Terraform modules accordingly to deploy the actual architecture. We invite you to read this demo code carefully and to deploy it using the following steps once ready:

1. Open a PowerShell command prompt and run az login using a subscription owner account. Just login as usual. This will ensure Terraform is able to reuse your cached credentials when deploying the code.
2. In Visual Studio Code, launch the terminal (View | Terminal).
3. Make sure you are in the right folder (cd '.\Chapter 3\use-cases\IaC\')
4. Modify line 13 of main.tf to add your own subscription ID.
5. Run terraform init
6. Run terraform apply --auto-approve

The last command performs the actual deployment. After about 10 minutes, you should be able to view all resources in your resource group as illustrated in Figure 3.42:

Now, you can click on the Application Gateway resource to grab its URL and browse it (make sure to use HTTP, not HTTPS). This should show the default page of the Online Archetype landing zone:

Feel free to explore the solution, by checking the different route tables, firewall rules, etc. and make sure to delete the resource group once done to prevent excessive costs.

Important note

This script has been deployed multiple times successfully but a transient error may always happen. In case of error, just make sure you chose a unique name for your web app and redeploy. Immediately after deployment, you may see a 502 – Bad Gateway error when accessing the web app via the Application Gateway. This happens because the gateway might have attempted to probe the web app before the ngress hub firewall's allow rule was fully in place. Wait a few minutes, and traffic should begin to flow as expected.

Let's now conclude this chapter.

Scenario and first analysis

Contoso is planning to launch an internet-facing B2B SaaS platform targeting upto one hundred customers, all located in Europe. To maintain strong isolation between tenants, Contoso has decided on a replication strategy where each tenant will have its own set of dedicated application components, while sharing a single AKS cluster. Within the cluster, a given tenant should not be able to interact with any other tenant.The solution includes a web portal, several backend services, and a separate data store for each tenant. Contoso aims to optimize infrastructure costs by pooling compute resources through AKS, while still ensuring data isolation and operational independence—for example, to enable tenant-specific backup and restore operations of the data layer. Contoso should also have an internal dedicated access to the admin portal of the SaaS solution that allows them to perform actions targeting all tenants, which should not be exposed to internet.You have been brought in to design the AKS architecture that supports these requirements.Let's review the keywords in this scenario that demand our focus:

• Replication strategy: Each tenant has its own set of components, including the database. In AKS terms, it means an ingress path, a few frontend and backend pods and an egress path to the tenant's database
• Cost optimization: Contoso aims to keep costs under control by sharing a single AKS cluster across all tenants, which rules out the use of dedicated node pools for each tenant.
• Strict boundaries: Although the tenants share the same cluster, they should not be able to connect with each other. A defense in depth would call for the use of network policies and potentially a service mesh.
• Internal access: Contoso operators need to access an admin UI and potentially other tenant-specific services. This private access cannot be exposed to the internet.

Earlier in this chapter, we examined various strategies for managing ingress, east-west, and egress traffic within AKS clusters. In the context of our scenario, a cloud-native approach that combines Istio for Layer 7 traffic management with Calico network policies for Layer 4 isolation appears to be the most suitable solution to enforce tenant separation.

Diagrams

After a few exchanges with Contoso, we went to the drawing board and ended up with this high-level end-to-end view diagram shown in Figure 4.16:

Although your responsibility is limited to AKS, you aimed to capture an end-to-end view that clearly illustrates the various tenant stacks. The shared infrastructure includes several core services such as Front Door, API Management, firewalls, and of course, AKS itself.Zooming in on the AKS virtual network, we can distinguish a few node pools:

• The ingress, workload, egress, and system node pools are each mapped to their own subnet. These node pools correspond to what we discussed earlier in the networking section. Needless to mention that all node pools are zone-redundant.
• The management node pool and its associated subnet are dedicated to internal-only access. Given Contoso's strong focus on security, a separate, purpose-built node pool is provided to reduce the risk of misconfigurations and conflicts with the broader ingress node pool—used to expose workloads to Front Door, API Management, and ultimately, to the internet.
• An additional subnet, not part of AKS, that holds all private endpoints for the data stores. Each tenant has its own database.
• NSGs attached to their respective subnet, restricting access.

NSGs will enforce Azure-level network controls. Here is a detail explanation of the rules we can define per NSG to restrict lateral movements at node level:

• For all AKS-related subnets, a rule that allows communication over Kubernetes system ports is required to let core components such as the kubelet API function. Each NSG will also explicitly declare a DenyAll rule that has a lower priority than the default system rules.
• The ingress NSG will restrict access to Front Door, API Management, and the Azure Load Balancer and/or Azure Firewall, depending on whether SNAT is performed at the ingress firewall level.
• The workload and egress NSGs allow the entire pod CIDR range. Because pod-to-pod traffic with Azure CNI Overlay isn't encapsulated, the NSGs will see the pod IPs. Not allowing such traffic would break it. We can be even more restrictive but things must remain manageable and we'll rely on logical isolation (next section) to rule internal traffic further.
• The private endpoint NSG will only accept traffic from the egress subnet.

From an Azure standpoint, a certain degree of segregation has already been implemented. Now, let's explore how to enforce tenant-level isolation within the shared AKS cluster itself.Figure 4.17 shows how to achieve this using Istio and Calico.

Important Note

Given the size of this diagram, do not hesitate to open the corresponding PNG or Visio available here: https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapook-Second-Edition/tree/master/Chapter04.

Everything defined in the istio-system namespace has cluster-wide scope. To enforce strict security, we configure outboundTrafficPolicy as REGISTRY_ONLY and apply a PeerAuthentication resource set to STRICT.

• REGISTRY_ONLY ensures that pod egress traffic is limited to services registered with Istio—typically, default Kubernetes services.
• STRICT enforces mutual TLS (mTLS), preventing communication from non-Istio pods to Istio-injected ones.

Additionally, we define two default Calico GlobalNetworkPolicy resources to deny all traffic by default, except for DNS resolution. It's important to exclude system namespaces from these policies, as shown in the accompanying code sample.Other cluster-wide resources—such as ServiceEntry (Istio)—can also be defined when all tenants require access to the same external service, such as Microsoft Entra ID.These default settings establish strong security boundaries by default because, as is, a pod could not send nor receive traffic from anything other than performing DNS resolution. The goal is to open up little by little to meet the actual needs of each tenant.Each tenant landing zone is composed of an ingress namespace, one or more workload namespaces, and one egress namespace. All namespaces will be labeled with the tenant identifier. For example, one workload namespace belonging to tenant 1 could look like this:

apiVersion: v1
kind: Namespace
metadata:
  name: tenant1-ns1
  labels:
    landing-zone: tenant1
    istio-injection: enabled
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Equal", "value": "workload", "effect": "NoSchedule", "key": "usage"}]'
---

The landing-zone label is used to identify the landing zone. The istio-injection label enforces workloads deployed to this namespace to be injected with Istio. Additionally, all pods deployed to that namespace will be scheduled to the workload node pool thanks to the appropriate toleration.In the ingress layer, a dedicated ingress controller will be deployed for each tenant. Each ingress LoadBalancer service will be assigned a tenant-specific IP and automatically scheduled to the ingress node pool. To ensure high availability, each ingress controller will run with at least three replicas, distributed across the three availability zones. This distribution can be explicitly enforced using topologySpreadConstraints.In the workload layer, we define namespace-scoped Calico NetworkPolicy resources to ensure that each tenant can communicate with its own components. For finer-grained control, we can enforce stricter access rules using Istio's AuthorizationPolicy resource. For instance, we might allow component 1 of tenant 1 to communicate with component 2, while denying access to component 3. Additionally, regular workload pods are scheduled onto the dedicated workload node pool using appropriate tolerations.In the egress layer, each tenant is assigned a dedicated egress controller that only accepts traffic originating from its own landing zone. Using the Istio Sidecar resource, we restrict the controller's visibility to just the egress namespace and the istio-system namespace.

Note:

To maintain strict control, Kubernetes RBAC permissions should ensure that only the platform team can manage the SideCar resources—application teams must not have modification rights.

As with the ingress and workload layers, egress controller pods are scheduled onto the dedicated egress node pool using appropriate toleration. Each tenant-specific egress controller is restricted to accessing only the tenant's database and other PaaS resources. This is enforced through ServiceEntry resources defined within the tenant's dedicated egress namespace. In addition, local Calico network policies are applied to allow traffic solely to the private endpoints of the tenant's PaaS services, ensuring tight control over outbound connectivity.Finally, we have the management node pool (not shown in Figure 4.18), which is decoupled from tenant landing zones. It hosts an ingress controller that is not exposed to Front Door or API Management, but is reserved exclusively for internal access.With this setup, we can be confident that traffic is tightly controlled—Istio, Calico, and NSGs work together to govern both Layer 4 and Layer 7 traffic across the environment.Before we explore some code samples, let's take a closer look at how Istio resources should be deployed—and more importantly, who should be responsible for managing them. Figure 4.18 illustrates where Istio resources belong and who is responsible:

Since Contoso developers are responsible for building the SaaS product, they require a certain level of flexibility—particularly given Contoso's decision to fully isolate tenants. This approach opens the possibility for some tenants to become early adopters or move ahead of others in terms of features and updates. That is why application teams should be able to deploy ingress, workload, and egress resources, being Istio or Calico related, except for the SideCar resource type. The platform team is full responsible for managing cluster-wide resources, as well as the initial landing zone setup, consisting of creating namespaces, defining quotas, assigning private IPs, deploying ingress and egress controllers, etc. For greater control, it is always possible to enforce a pull request as part of the lifecycle of a landing zone.Similarly, roles and responsibilities must be defined for Calico network policies, as shown in Figure 4.19:

In a flexible organization, global network policies are governed by the platform team, while namespace-scoped policies can be managed by application teams. However, the landing zone should provide default network policies to ensure internal communication within each tenant.Before diving into the code, it's important to emphasize that, in addition to using tools like Istio and Calico, we must also enforce best practices—such as adopting workload identities, integrating the Key Vault Secret Provider, and other security measures covered in previous sections.

Code samples

We've included some code snippets (https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapook-Second-Edition/tree/master/Chapter04) and a sample folder structure to help you get started with Istio and Calico in the context of tenant landing zones. To keep things concise, we'll focus on the most critical aspects and leave the deeper exploration to you. The folder structure is shown in Figure 4.20:

The folder structure reflects our landing zone setup, with one folder per tenant, each containing the ingress, egress, and workload subfolders. Let's outline the responsibilities for each team, starting with the platform team.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-ingress-traffic
  namespace: tenant1-ingress
spec: 
  selector: all()
  order: 10
  types:
  - Ingress  
  - Egress
  ingress:
  - action: Allow   
    source:
      nets:
        - <IP range from the ingress hub>
  egress:
  - action: Allow   
    destination:     
      namespaceSelector: tenant == 'tenant1' 

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-intra-lz-traffic
  namespace: tenant1-workload-ns1
spec: 
  selector: all()
  order: 10
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    source:
      namespaceSelector: tenant == 'tenant1'     
  egress:
  - action: Allow
    destination:     
      namespaceSelector: tenant == 'tenant1' 

egress:
  - action: Allow
    destination:     
      nets:
      - 0.0.0.0/0
      notNets:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: restrictSideCarVisibility
  namespace: tenant1-workload-ns1
spec:
  egress:
  - hosts:     
    - "istio-system/*"
    - "tenant1-egress/*"
    - "*/*.svc.cluster.local"

apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: tenant1-ingress 
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: ingress   
spec:
  type: LoadBalancer 
  loadBalancerIP: <IP from the ingress subnet>
  externalTrafficPolicy: Local
  selector:
    istio: tenant1-ingress-gateway
  ports:
  # you might want to remove port 80 but it's good for testing
    - name: http
      port: 80
      targetPort: 8080
    - name: https
      port: 443
      targetPort: 8443
    - name: status-port
      port: 15021
      targetPort: 15021

apiVersion: v1
kind: Service
metadata: 
  labels:
    app: tenant1-egressgateway   
    istio: tenant1-egressgateway   
  name: tenant1-egressgateway
  namespace: tenant1-egress   
spec:
  ports:
  - name: sql
    port: 1433
    protocol: TCP
    targetPort: 1433
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: tenant1-egressgateway
    istio: tenant1-egressgateway
  sessionAffinity: None
  type: ClusterIP

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: tenant1-sql-egress
  namespace: tenant1-egress
spec:   
  selector: "app == 'tenant1-egressgateway'"
  order: 10
  types:  
  - Egress 
  egress:   
    - action: Allow     
      protocol: TCP
      destination:       
        nets:
          - <SQL DB private endpoint>/32         
        ports:         
          - 1433

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-sql-db
  namespace: tenant1-egress
spec:
  hosts:
  - <tenant1>.database.windows.net
  location: MESH_EXTERNAL
  ports:
  - number: 1433   
    protocol: TLS
    name: sql
  resolution: DNS

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: sql-gateway
  namespace: tenant1-egress
spec:
  selector:
    istio: tenant1-egressgateway
  servers:
  - port:
      number: 1433
      name: tls
      protocol: TLS
    hosts:
    - <tenant1>.database.windows.net
    tls:
      mode: PASSTHROUGH

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: sql-virtual-service
  namespace: tenant1-egress
spec:
  hosts:
  - <tenant1>.database.windows.net
  gateways:
  - mesh
  - sql-gateway
  tls:
  - match:
    - sniHosts:
      - <tenant1>.database.windows.net
      gateways:
      - mesh
      port: 1433
    route:
    - destination:
        host: "tenant1-egressgateway.tenant1-egress.svc.cluster.local"
        port:
          number: 1433
  - match:
    - sniHosts:
      - <tenant1>.database.windows.net
      gateways:
      - sql-gateway
      port: 1433
    route:
    - destination:
        host: <tenant1>.database.windows.net
        port:
          number: 1433
      weight: 100

Scenario and first analysis

Contoso is a newly formed logistics startup aiming to disrupt the same-day delivery market with a fully cloud-based, microservice-driven backend. With no existing infrastructure—on-premises or in the cloud—they're starting from scratch and want to quickly build a proof-of-concept (PoC) to validate their architecture and business idea without incurring high upfront costs. Their PoC's objectives and constraints are:

• Prove out a scalable event-driven microservice architecture and only focus on the order and shipping services first.
• Keep operational overhead and cost to a minimum.
• Avoid managing complex infrastructure (for example, Kubernetes clusters).
• Enable fast iteration and developer productivity.

Let's first extract the keywords in this scenario that demand our focus:

• Microservices: We should focus on a service that helps deal with distributed architectures and service discovery.
• Minimal overhead and low costs: We should look at a serverless offering, especially for the PoC. We may always transition for something else later on.

After a bit of digging, you realized that ACA could be a good fit as there is a serverless offering and they include both Dapr and KEDA, which may help boost the development productivity. You went to the drawing board and ended up with Figure 5.14.

Diagrams

Figure 5.14 illustrates a possible solution.

You foresee a single Container App Environment into which you will deploy the Order, Shipping, and OrderQuery service. All the services communicate asynchronously through Azure Service Bus using a Dapr Pub/Sub component.The namespace has the following topics:

• order.placed: The order service subcribes to this topic to handle any incoming order, which could be placed by an external API call or by an external component pushing a new order placement request to the topic.
• order.paid: The shipping service subscribes to this topic since shipping can start as soon an order is paid.
• order.shipped: The shipping service publishes a message to this topic once the shipping process completes.

Before starting the shipping process, the service calls the orderquery service synchronously to fetch order details using Dapr's invoke API. Components leverage Azure Managed Identity to interact with the Service Bus entities. Let's see a bit more concretely what the code looks like.

Code samples

A full .NET application, focusing only on the usage of Dapr in the simplest expression, is made available on the GitHub repo but let's focus on the essential parts. The first thing any Dapr-enabled API has to do is to enable Dapr and enable Cloud Events:

public void ConfigureServices(IServiceCollection services){
    services.AddControllers().AddDapr();
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env){
    app.UseCloudEvents();
}

Dapr makes use of the CloudEvents message format for its pub/sub API building block. Once Dapr is enabled for a given service, we can simply leverage the pub/sub channel very easily:

[Topic("daprsb", "order.placed")] //this route subscribes to the order topic
[HttpPost]
[Route("dapr")]
public async Task<IActionResult> ProcessOrder([FromBody] Order order){
    _logger.LogInformation($"Order with id {order.Id} processed!");
    //we'll pretend it is already paid
    _logger.LogInformation($"Order with id {order.Id} paid!");
    await PublishOrderPaidEvent(order.Id, OrderEvent.EventType.Paid);
    return StatusCode(StatusCodes.Status201Created);
}

This code subscribes to the order.placed topic, pretends to handle the order, and publishes a message to the order.paid topic, also pretending that the order has been paid. For direct service invocation, we can simply use Dapr's invoke API as used from within the shipping service to fetch order details:

var request = _dapr.CreateInvokeMethodRequest<object>(
    HttpMethod.Get, "orderquery", id.ToString(), null);
var response = await _dapr.InvokeMethodWithResponseAsync(request);

The call is made towards the orderquery service (Dapr application identifier) and the method being consumed is the actual order identifier. We'll let you discover the provided code on your own.From an infrastructure perspective, we must provision a Container App Environment and a Dapr component of type pub/sub.

name: daprsb
componentType: pubsub.azure.servicebus
version: v1
metadata:
- name: namespaceName
  value: <namespace>
- name: azureClientId
  value: <identity>

We must specify the service bus namespace <namespace> and the identity <identity> to be used dynamically after having provisioned them (not shown here). Once the component's YAML file is updated, we must deploy it:

az containerapp env dapr-component set `
  --name $envName `
  --dapr-component-name daprsb `
  --resource-group $resourceGroupName `
  --yaml ./daprsb.yaml

Both the order and shipping apps will consume that component. Our apps must be Dapr-enabled and be identified with a unique application identifier. Here is an example for the shipping service:

az containerapp create `
--name shipping `
--resource-group $resourceGroupName `
--environment $envName `
--image $shippingImage `
--enable-dapr true `
--dapr-app-port 8080 `
--dapr-app-id shipping `
--min-replicas 1  `
--user-assigned mapbookidentity `

We also have to define the port number the application container listens to (8080) and we link the app to the identity to which we have already granted access to the Service Bus (not shown here). Now that you should have a better idea of how the solution works, let's see how to test it.

Testing the solution

You can use the provided Docker images or decide to rebuild the application code yourself and use your own images. Since this step is optional and not directly linked to Azure, we'll leave it to you. To test this solution in you own tenant, you must:

• Have an Azure subscription with owner permissions. Folllow this link to start a new trial if required https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account.
• Install Azure CLI. Follow the instructions available here https://learn.microsoft.com/en-us/cli/azure/install-azure-cli.
• Clone the map book repo or download the code.
• Have Visual Studio Code with the PowerShell Extension (Linux)
• Open the cloned/downloaded folder with Visual Studio Code. Make sure to run az login before any other activity.
• Navigate (cd) to this folder: Chapter 5\code\use-case\IaC.

Once in the correct folder, open deploy.ps1 and adjust the following variables to your needs:

$resourceGroupName = "mapbook-aca-rg"
$envName = "mapbook-aca-env"
$location = "swedencentral"
$orderImage ="stephaneey/order-aca:dev"
$orderQueryImage ="stephaneey/orderquery-aca:dev"
$shippingImage ="stephaneey/shipping-aca:dev"
$serviceBusNamespace = "seymapbookacans"

Stick to the provided container images and only modify if you decided to rebuild and repackage the application yourself. The only parameter that you should change is the $serviceBusNamespace as it should be unique worldwide. Just use something like <your trigram>mapbookns.From there on, you can run the script ./deploy.ps1 if you are on Windows or have the PowerShell extension, else feel free to extract the Azure CLI commands and run them yourself. The only dependency on PowerShell is the following code block:

$yamlPath = "./daprsb.yaml"
$yamlContent = Get-Content $yamlPath -Raw
$updatedYamlContent = $yamlContent -replace '<namespace>', "`"$serviceBusNamespace.servicebus.windows.net`""
$updatedYamlContent = $updatedYamlContent -replace '<identity>', "`"$clientId`""
$updatedYamlContent | Set-Content $yamlPath

This code replaces the <namespace> and <identity> tokens in the daprsb.yaml file with the corresponding clientId and service bus namespace's FQDN. Feel free to replace those values manually if needed.The execution of the .ps1 file takes only a few minutes. Once deployed, you should find the following resources in the resource group:

From there on, you should be able to click on any Container App and check that everything is running fine in the revisions and replicas section:

In the overview tab of the order service, you should be able to grab the Application URL which looks like https://order.<random>.<location>.azurecontainerapps.io.With the URL in hand, you can perform a call to the order service by placing a command using the following raw HTTP payload (provided as well in the code):

POST https://order.<random>.<location>.azurecontainerapps.io/order
Content-Type: application/json
{
        "id": "4aadc0f8-eeda-4ee7-9c26-a6d39cbfbc28",
        "products": [
            {
                "id": "5678f982-2ae4-408c-92ff-6af45118d159",
                "name": null
            },
            {
                "id": "6678f982-2ae4-408c-92ff-6af45118d159",
                "name": null
            }
        ]
}

Make sure not to forget to add /order at the end of your endpoint since this is the API entry point of the order service. Repeat the request a few times. The flow should be as follows:Order placed to order service through API | order service pushing to the order.placement topic | order service to process the order | order service pushing an event to the order.paid topic | shipping service starting the shipping process, fetching order details through an API call to orderquery, and pushing a message to order.shipped topic upong succesful completion.In a real-world scenario, there would typically be an additional payment service, but we simplified the setup to focus solely on synchronous and asynchronous communication using ACA and Dapr. For your convenience, we added the extra subscription named foryourtocheck on the order.shipped service as shown in Figure 5.17.

Important note

You could do the extra mile yourself by adjusting the solution and add KEDA scaling rules that would scale the shipping app based on the number of messages landing to the shipping subscription. Figures 5.18 and 5.19 give you a hint on how to get there.

With this scaling configuration, the shipping service would scale to 0 if no activity takes place and would scale out to maximum 10 replicas should we receive a lot of order.paid events.Let's now summarize this chapter.

Diagrams

Figure 6.9 shows a high level diagram of our invoice processing pipeline:

We assume that customers will submit their invoices through Contoso's existing Managed File Transfer (MFT) solution—such as GoAnywhere, a widely used platform. The MFT solution will handle antivirus scanning and, once the files are cleared, upload the invoices to the application's storage account. In the unlikely event that Contoso, a financial organization, would not have any MFT solution, you could suggest to leverage the built-in storage account SFTP features as well as Defender for Storage as the anti-virus. The latter could be used as well as a second-line anti-virus scanning tool. You might as well suggest an API layer that customers use to send their invoices instead of relying on SFTP. However, most financial organizations still rely on good old file transfer services as ingestion channels. Regardless on how files land into our storage account, it is interesting to see how to handle them.We know that files should be relatively small so we can decide to use Azure Functions Elastic Premium to parse and validate the files and get our code triggered thanks to the Blob Trigger. The validation layer will send messages to the invoices topic with some promoted properties that are used by the subscriptions. Our back office components will have three subscriptions on the invoices topic:

• The invoices.auto-approved subscription that filters all valid invoices for which the amount is below or equal to 10000 euros.
• The invoices.approval-required susbscription for which the amount is greater than 10000 euro.
• The invoices.invalid subscription.

We used a single topic because we know we are not dealing with large amount of messages so we're far from hitting any of the entity-level limits. An alternative could have been to split further the topics.We basically delegate the filtering and appropriate routing to Azure Service Bus itself using subscription filters. You might have noticed that we also filter based on the message version as it is a best practice. Using message versions ensure no breaking change takes place should the message format change, providing the publisher updates the version number accordingly. This allows subscribers to gradually adapt and adopt the new version.All our subscriptions have a dead-letter queue that our back office must monitor. Messages are dead-lettered by Azure Service Bus itself whenever messages cannot be delivered for some reason (the max delivery attempt is reached, the max retention time has occurred, and so on). To make sure we do not lose a single message, we must monitor the dead-letter queues and decide what do to with them. Back-office processing may or may not utilize Azure Functions to consume messages from the Service Bus subscriptions.Beyond making sure messages are published with the correct properties, we also leverage the Claim Check pattern as we will encapsulate the blob location as part of the message body instead of including the entire invoice body into our payload. This part will be more visible in the provided .NET code.In the provided code sample, the focus is limited to message validation and Service Bus configuration, allowing back-office components the flexibility to implement their own preferred message handling mechanisms.For sake of simplicity and cost control, we have not hardened the provide example from a network perspective but beware that the corresponding physical view could look like Figure 6.10.

The MFT solution should be able to talk to our storage account that is isolated from Internet as any other component of our application. The MFT infrastructure might be hosted in Azure or anywhere else but connectivity should be in place. It might use its own dedicated firewall or reuse the Hub's one. In any case, this is beyond the control of the Application Architect, hence why we did not include this as part of the provided sample solution, which is entirely public facing. The focus here is on how to link Azure Functions to Azure Service Bus and leverage built-in features such as subscription filters. Let's look closer at some code.

Code samples

The Azure Functions runtime can be quite complex and isn't exactly beginner-friendly, as it comes with a steep learning curve. First of all, we must use the so-called isolated workder mode, which is gradually replacing the older in-process mode. This must be defined explicitly when creating the Azure Functions project.In our scenario, we're using the runtime in a straightforward manner—to trigger code execution when a blob is added to a storage container and to enqueue a message to a Service Bus topic. At first glance, this should be simple, thanks to the built-in Blob Storage trigger and Service Bus output binding. However, as is often the case, the devil is in the details. Our design requires promoting custom metadata properties so that subscribers can filter messages and receive only the invoices relevant to them. Unfortunately, the Service Bus output binding doesn't currently support promoting such properties. To meet this requirement, we must instead use the native Service Bus SDK directly.Secondly, while we haven't yet applied strict network hardening to our solution, we aim to follow best practices for authentication by leveraging Managed Identities to access both our business storage account and Service Bus. This approach, though more secure, can be challenging to implement—especially since most online examples rely on basic connection strings rather than identity-based access. Figure 6.11 shows our needs in terms of identity-based resource access.

We create a separate User-Assigned Identity to which we want the Storage Blob Data Contributor and Storage Queue Data Contributor roles to the storage account that contains the invoices. Next, we grant the Azure Service Bus Data Sender role to the same identity over the Service Bus where we'll publish messages. For the sake of simplicity, we continued using key-based authentication for our technical storage account, as it does not hold any business-critical data. The technical storage account is used by the function app to log some information as well as keep track of the different triggers. It typically doesn't contain sensitive data, especially when not using Durable Functions. However, it's important to note that in enterprise environments, Azure policies may enforce restrictions that completely block key-based authentication by default. In such cases, you'll need to either switch to managed identity or formally request a policy exception.The creation of the managed identity as well as role assignment is done at infrastructure level but as an Application Architect, you must know your exact needs and should be able to document them properly. You must also understand which implications such a configuration has on the application code.In our example, we use the default Blob Trigger, which is shown in the following function signature:

[Function(nameof(InvoiceFunctions))]      
public async Task InvoiceLanded([BlobTrigger("invoices/{name}", Connection = "AzureWebJobsBusinessStorage")] BlobClient blobClient,
string name,
FunctionContext context)

While this looks simple enough, the default behavior is that the AzureWebJobsBusinessStorage setting is supposed to be the plain connection string using key-based authentication and not identity-based authentication. The convention to make the runtime "understand" that it should switch to identity-based authentication, consists in defining a few extra environment variables:

• AzureWebJobsBusinessStorage__blobServiceUri: this setting indicates the full blob URL of the storage account, such as https://mapbook.blob.core.windows.net/.
• AzureWebJobsBusinessStorage__queueServiceUri: this setting indicates the full queue URL of the storage account, such as https://mapbook.queue.core.windows.net/. At this stage, you might wonder why you need to pass the queue service URL although you're only dealing with a blob trigger. This is required by the runtime as it pushes poisoned messages into a queue. In our use case, it means that when the function fails to handle a blob, a correspondoing poison message will be added to a storage account queue.
• AzureWebJobsBusinessStorage__credential: this setting is required to indicate that we want to use identity-based authentication.
• AzureWebJobsBusinessStorage__clientId: this setting is only required when using user-assigned identities instead of system-assigned. The Client ID of the user-assigned identity must be specified.

Transitioning from key-based to identity-based authentication introduces its own layer of complexity.Once our function is triggered by the arrival of a blob, it is supposed to handle it and queue a message to the invoices topic. As explained earier, we must use the plain Service Bus SDK to do so because the default provided outbound binding doesn't allow us to publish messages with custom properties. Therefore, we need to perform a bit of dependency injection plumbing to get things done:

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureAppConfiguration((hostingContext, config) =>
    {
        config.AddEnvironmentVariables();
    })
    .ConfigureServices((context, services) =>
    {
        var configuration = context.Configuration;      
        var serviceBusFQDN = configuration["ServiceBusConnectionFQDN"];
        var managedIdentityId = configuration["ServiceBusConnectionclientId"];
     
        services.AddSingleton(serviceProvider =>
        {          
            var credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
            {
                ManagedIdentityClientId = managedIdentityId
            });
            return new ServiceBusClient(serviceBusFQDN, credential);
        });
        services.AddScoped<InvoicePublisher>();
    })  
    .Build();

We basically add a singleton for our Service Bus client and we leverage the DefaultAzureCredential class (from the Azure.Identity package) to switch to identity-based authentication. The settings defined at the level of the Function App are used here. We also inject a custom InvoicePublisher that we can use from within the functions. The core of our function is the following code:

string blobUrl = blobClient.Uri.ToString();
_logger.LogInformation($"Pretend to handle blob \n Name:{name} \n");
var payload = new{
    BlobUrl = blobUrl              
};
var json = JsonSerializer.Serialize(payload);
var message = new ServiceBusMessage(BinaryData.FromString(json))            {              
    Subject = "CustomerInvoice",
    ContentType = "application/json"
};
await _publisher.PublishInvoiceAsync(
    blobUrl,
    (new Random().Next(10) < 5) ? true : false,
    new Random().Next(15000),"v1");

We pretend to handle the blog (the point here is not to teach you how to parse a JSON file), then we add the link to the blob into the message (Claim Check pattern) and we publish a message to the invoices topic with our custom properties. We randomly set them to make sure our different subscriptions will receive something. Our publisher object is just a wrapper of the Service Bus client. Note that this code does not include any custom exception handling—exceptions will bubble up by default. If you choose to implement your own exception handling, it is crucial to re-throw the exception afterward. Failing to do so may cause the Azure Functions runtime to treat a failed execution as successful, which directly affects how poison and non-poison messages are handled. This can lead to undetected issues in your processing pipeline. In fact, it's safer to avoid custom exception handling altogether than to implement it incorrectly and risk suppressing genuine errors. Now, let's see how to test this code.

Testing the solution

To test this solution in you own tenant, you must:

• Have an Azure subscription with owner permissions. Folllow this link to start a new trial if required https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account.
• Install Azure CLI. Follow the instructions available here https://learn.microsoft.com/en-us/cli/azure/install-azure-cli.
• Clone the map book repo or download the code.
• Have Visual Studio Code with the PowerShell Extension (Linux)
• Open the cloned/downloaded folder with Visual Studio Code. Make sure to run az login before any other activity.
• Navigate (cd) to this folder: Chapter 6\ use-case\IaC.

Once in the correct folder, open deploy.ps1 and adjust the following variables to your needs:

$resourceGroupName = "mapbook-chapter6"
$location = "swedencentral"

All the resources will be created using a unique name by default. You may still come up with your own names if you want, in which case, feel free to adjust the other variables as well. If both, the default resource group and location are ok, just leave them untouched.Once done, you can run the script ./deploy.ps1 from the Visual Studio Code terminal. The script takes only a few minutes to complete and deploys the resources showin in Figure 6.12.

The script also deploys the invoices container as well as a dummy invoice to faciliate the testing.

The script also assigns the required roles to the managed identity assigned to the Function App and deploys the environment variables that are picked by the function code.

With the infrastructure totally deployed, you still need to publish the code.In a real-world situation, this step would be ensured by CI/CD pipelines. The code would be first built and then deployed using Azure DevOps tasks or GitHub Actions. To keep things simple enough, we will deploy the code manually using the Publishing Profile of the Function App. Here are the steps required to publish the code:

1. In the Azure Portal, navigate to the Function App and click on Get publish profile:

   

2. Download it somewhere on your disk.
3. Open Visual Studio 2022 or later by double-clicking on Chapter 6\use case\code\InvoiceFunctions\InvoiceFunctions.sln.

4. Right click on the project and select Publish:

   

5. Next, click on Import Profile and select the download file. Accept all the default options.

6. Next, click on the Publish button:

   

7. Once the publish process is complete, you should see the function appear in green:

   

8. Since we provided a default dummy invoice, you should see an invocation (it might take a few minutes before you see it). You must click on the link labeled Invocations and more, shown in Figure 6.18.

You will be redirected to the function invocation page and should see one successful execution:

If everything went fine, the function should have published a message to our Service Bus topic and this should land in one of the subscriptions:

You can upload a few extra files (it doesn't need to be real invoices as we do not parse them anyway) to see how messages are distributed across subscriptions. Feel free to click on the different subscriptions and double-check their filter settings, and so on.This seemingly simple use case underscores the importance of close collaboration with infrastructure teams, as they often carry out substantial configuration work behind the scenes to ensure your code runs properly. At the same time, it's equally critical for developers to understand the infrastructure requirements and constraints involved. Making this work is a shared responsibility—it requires coordinated effort from both sides.Let's summarize this chapter!

Data ingestion

IoT Hub and Event Hubs are both highly scalable ingestion layers. As its name indicates, IoT Hub is the Azure service for any IoT scenario. The service is able to establish bi-directional communications with IoT devices and can be supplemented with IoT Edge and IoT Edge Modules to accommodate entreprise-grade scenarios matching industry standards where industrial networks typically do not directly connect to Internet. Event Hubs is a general-purpose ingestion service, for high-throughput data streaming. Event Hubs is commonly used for application telemetry and real-time data collection. For example, Azure API Management has a built-in log-to-eventhub policy that allows us to track any API operation call in near real-time while not compromising performance. Event Hubs can also be handy in any Business Activity Monitoring (BAM). Events landing in both IoT Hub and Event Hubs can be persisted in other data services, such as Azure Data Explorer, Cosmos DB, or ADLS Gen2, among others, using Stream Analytics or other processing services to process and transfer the data to downstream stores.

Data processing

Data processing can take various forms—batch processing, stream processing, or event-driven processing of discrete data events. For scenarios that don't require Massively Parallel Processing (MPP), Azure Functions and Fabric Dataflow Gen2 are viable options. Azure Functions, already introduced in previous chapters, offer a code-based approach. In contrast, Fabric Dataflow Gen2 enables users to build ingestion and transformation pipelines using Power Query, without writing any code. This service is designed for power users and citizen developers who prefer a low-code experience. When it comes to batch processing, both Azure Databricks and Synapse Analytics with Spark runtime are very good options. One of the key decision factors about choosing Databricks or Synapse for batch processing is whether you need to lookup reference data from external relational stores. At this stage, only Databricks provides this capability. Databricks is also the only one to propose an auto-scaling feature, which can be particularly useful when processing in bursts. Data Factory, being an ETL/ELT tool, is particulary suited for processing batches too, especially when the data sources are located on-premises as we can rely on its Self-Hosted Integration Runtime (SHIR) to bridge the two worlds. Microsoft Fabric pipelines share many familiar concepts with Azure Data Factory and can also be used for batch processing.Finally, for stream processing, Azure's established service is Stream Analytics, which integrates seamlessly with the broader Azure ecosystem. It supports various input sources such as IoT Hub, Azure Event Hubs, Blob Storage, and Data Lake Storage Gen2, and offers no fewer than fourteen output options. Stream Analytics is particularly well-suited for bridging the ingestion layer with downstream data stores. Stream Analytics is available in two forms: jobs and clusters. Clusters provide dedicated resources (single tenant) and can scale to process up to 400 MB per second in real time. Jobs leverage Azure's underlying multi-tenant infrastructure to run your stream processing logic and cannot digest as much data as clusters. Choosing between jobs and clusters depends on your specific needs, but if you are looking for guaranteed throughput, you should go for clusters.For more advanced complex streaming scenarios, both Synapse and Databricks rely on Spark Structured Streaming, which can be customized further. When output downstream data services are part of the Fabric world, you should look at Fabric Real Time Intelligence.

Data storage (raw)

Unlike operational databases such as Azure SQL or PostgreSQL—which are optimized for structured, transactional workloads—raw storage solutions like Azure Blob Storage, Azure Data Lake Storage (ADLS), or Microsoft OneLake are designed to store large volumes of unstructured or semi-structured data efficiently. These storage systems serve as cost-effective repositories for data that may later be transformed, analyzed, or processed in downstream analytics pipelines. Azure Files and Azure Netapp Files can be used as recipient of data transformations (for example, reports) which can be shared across applications through mounted volumes. Azure Netapp Files is particularly suited for very high-throughput and ultra-low latency workloads. Blob Storage is widely used across data and non-data applications for storing raw binary objects. ADLS builds on the same underlying service but introduces a true hierarchical namespace and is therefore optimized for data operations.

Serving and data visualization

The data serving and visualization layers are distinct yet closely related components. The serving layer exposes processed, analyzed, or transformed data to applications, services, and users. The visualization layer builds on this by presenting the data through dashboards, reports, charts, and other graphical formats. Power BI—now integrated into Microsoft Fabric—is the flagship service for data visualization, designed to empower business users with self-service analytics. Power BI enables the creation of reports and dashboards, which can also be easily added to external applications using Power BI Embedded. Alternatively, Azure Data Explorer Dashboards offer lightweight visualization capabilities, which are primarily geared toward data engineers and developers.

Other data capabilities

Azure AI Search is a general-purpose search service increasingly used as a vector database and a hybrid search engine, combining the strengths of both vector and keyword-based search. While Cosmos DB and Azure SQL also offer capabilities for full-text and vector search, Azure AI Search remains the most versatile for search-centric scenarios.For time series data, Azure Data Explorer stands out as the most suitable service. It can ingest billions of rows and respond to queries within milliseconds, making it ideal for high-throughput, low-latency analytics.When it comes to sharing data across internal teams or platforms, Synapse Workspace Federation and Databricks Delta Sharing are effective solutions. For external data sharing with third parties, Azure Data Share offers a more appropriate option. Now that we have identified a few capabilities, let's see how we could combine them to match usual data patterns.

Patterns to services

It is nearly impossible to list all the possible service combinations we can use to achieve typical data patterns, but we can at least try to identify a few. The Medallion pattern is best achieved with ADLS combined to Azure Databricks, thanks to its native support of Delta Lake making it easy to apply data transformation and enrichment across the bronze, silver, and gold layers.When it comes to Lambda and Kappa, there are many possibilities. An example of Lambda pattern could be achieved using services shown in Figure 7.3.

We use Kafka-enabled Azure Event Hubs for data ingestion, combined with Databricks Structured Streaming to process the data in real time and store it in Delta Tables. For the batch layer, data lands in ADLS via an ETL process orchestrated by Azure Data Factory. Databricks pulls data from ADLS, applies the required transformations, and stores the results in Delta Tables. Power BI serves as the consumption layer, enabling end users to explore and visualize the prepared data. Alternatively, a traditional SQL database can be used as the final output destination—particularly when reporting needs or scalability requirements call for it.An alternative for building a Lambda architecture could be as shown in Figure 7.4.

In this scenario, we continue to use Azure Event Hubs as the ingestion layer, with or without Kafka protocol support. Optionally, Azure Stream Analytics can sit between Event Hubs and Azure Data Explorer to apply filtering or support multiple output targets. However, Data Explorer is also capable of ingesting data directly from Event Hubs.For the batch layer, Azure Data Factory is used to land raw data in ADLS. Data Explorer then pulls the data from ADLS and applies the necessary transformations. As in the previous architecture, Power BI is used as the serving layer to deliver insights to end users.For a Kappa architecture, you might do the same as Lambda with a focus on the speed and serving layers only. Synapse and Fabric could also be used to realize both Lambda and Kappa. Let's now zoom in on HTAP.

Infrastructure enablers

Today, most data sources are isolated from the public Internet, requiring the use of infrastructure components to establish secure connectivity between data services and those sources. Historically, the On-premises Data Gateway (ODG) was the primary solution for enabling cloud-based services like Power BI to access on-premises data sources. It remains widely used today for the exact same purpose but is not the only possibility anymore. To use it, the gateway must be installed on one or more on-premises servers with connectivity to the target systems. Beyond data access, ODG can also integrate with systems like IBM MQ. One of its key advantages is support for authentication protocols such as NTLM and Kerberos—something that is difficult to achieve with PaaS or SaaS components. Figure 7.7 illustrates how we can take advantage of ODG:

ODG initiates an outbound connection to the Azure Relay service, which bridges ODB and the target cloud services such as Power BI and Logic Apps. The outbound connection is bi-directional and ODG can receive commands to execute from the cloud components. Connection strings and configuration settings are defined in the cloud and executed on-premises.The Self-Hosted Integration Runtime (SHIR) introduced earlier, works more or less the same way but is specific to Data Factory and Synapse Pipelines (or under the Fabric umbrella) as the target cloud services. Any ETL/ELT flow between on-premises and the Cloud involves the SHIR. Of course, the SHIR can be installed in other clouds or even on Azure IaaS. For example, two different Azure-hosted solutions running self-hosted SQL servers might leverage a cloud-based SHIR to exchange data.The Managed Virtual Network (MVN) is particularly useful for enabling services like Data Factory or Microsoft Purview to connect to PaaS data sources that are not exposed to the public Internet. MVN acts as a secure tunnel between the calling service and the target data source. Within the MVN, the service can deploy Managed Private Endpoints, which must be explicitly approved by the target data service. Once approved, the calling service gains access to the data source through the private endpoint it created, ensuring secure and controlled connectivity.Last but not least, the Virtual Network Data Gateway (VNDG) is specific to Azure and requires Virtual Network integration. Its primary purpose is to enable Power BI and Fabric to access Azure data stores that are not exposed to the public internet. For instance, if the Power BI service needs to retrieve data from a Synapse Workspace secured behind private endpoints, VNDG serves as the secure bridge between the two worlds. Figure 7.8 illustrates an end-to-end integration between Power BI and Synapse through VNDG.

Figure 7.8 illustrates that your primary concern is deciding where to deploy VNDG. Configuration is handled directly within the Power BI service, and a single gateway can be shared across multiple Power BI workspaces. You can choose between a shared or dedicated VNDG, depending on your architecture. In the scenario shown in Figure 7.8, a dedicated VNDG is assumed, as it resides in the same Virtual Network as the Synapse Workspace.The most critical requirement is ensuring that the VNDG has network connectivity to the target data sources and the firewall rules allow outbound traffic to Entra ID, which is essential for acquiring tokens required by Power BI connectors. A common misconfiguration by infrastructure and data teams is overlooking Entra ID traffic, which prevents the gateway from completing authentication and establishing a successful connection. This configuration error frequently results in support requests to Microsoft, so it's important to keep it in mind.In conclusion, all these infrastructure enablers allow you to bridge cloud services with the data center where they are installed. Let's now look at the OLTP.

Operational Database Systems

Azure offers a variety of OLTP systems, including relational databases like Azure SQL and PostgreSQL. However, the flagship OLTP service is undoubtedly Cosmos DB. As of 2025, it remains the only Azure service that supports multi-master writes across multiple regions at global scale, while also delivering sub-2 millisecond latency for both reads and writes. Cosmos DB is packed with features that make it a uniquely powerful offering.That said, as is often the case with feature-rich platforms, teams sometimes adopt Cosmos DB too quickly without fully understanding its design principles. This can lead to suboptimal performance, escalating costs, and ultimately, a need to revisit the design. Let's take a closer look at this powerful yet complex service to better understand how to use it effectively through a mini use case scenario.Let's imagine that you are developing a mobile app to manage wine cellars. The app is made available through the different app stores and you expect potentially many users so you have to make it scalable and accessible worldwide. A high-level solution could be something like we explained in Chapter 3, Infrasctructure Design in our Global API Platform Use Case, where you proxy your backend services with a multi-region API Management instance, have backends services in corresponding regions, each talking to their own regional Cosmos DB. Figure 7.9 shows a simplified version of it to refresh your memory.

As a global service, Azure Front Door is inherently multi-region aware. Our API layer builds on this by leveraging Azure API Management's native multi-region capabilities. On the backend, services are deployed across multiple regions, and Cosmos DB is configured with multi-master writes in all enabled regions. Together, these elements ensure that our architecture consistently delivers the fastest and most responsive user experience—regardless of the user's location worldwide.However, global distribution alone is not enough—performance also depends heavily on how your Cosmos DB is designed. Without following a few key design principles, even the most elegant and appealing mobile app can quickly become sluggish and less engaging for end users. Here are a few essential guidelines to consider when using Cosmos DB:

• Avoid hot partitions: Cosmos DB scales horizontally by distributing data across multiple logical partitions, which are then mapped to physical partitions. If data is not evenly distributed—often due to a poorly chosen partition key—some partitions may receive a disproportionate volume of requests or data. This results in hot partitions, which can degrade performance and eventually lead to throttling or full partitions.
• Avoid cross-partition queries: Cosmos DB cross-partition queries occur when a query needs to access data from multiple logical partitions, typically because the query lacks a partition key filter or spans multiple partition key values. These queries will increase latency and RU (Resource Unit) consumption, leading to slower performance and increased costs.
• Evaluate read/write ratio: This aspect is often overlooked by application and data teams, yet it plays a critical role in performance tuning. By default, Cosmos DB indexes all attributes, which benefits read-heavy workloads but can negatively impact write-heavy ones. In write-intensive scenarios, it is recommended to define a custom indexing policy that limits indexing to only the fields required for queries. This reduces write latency and optimizes resource consumption.
• Mind hard limits: You must always pay attention to hard limits such as the maximum document size, maximum partition size, and so on.

Many of these considerations can be addressed by choosing an appropriate partition key strategy. However, some best practices may conflict with one another. For example, selecting a GUID as the partition key can ensure even data distribution and help avoid hot partitions—but it may not align with your query patterns. This misalignment can result in frequent cross-partition queries, which may increase latency and RU consumption.Back to our wine cellar mobile app scenario, let's review these considerations against our use case.We can safely assume the following:

• Avoid hot partitions: Overall, data should be reasonably evenly distributed, as it is unlikely we'll encounter extreme imbalances, such as some cellars containing millions of bottles while others have only a few.
• Avoid cross-partition queries: Each user will only access their own collection of wines, meaning that the majority of queries will target a single cellar. While some back-office reporting scenarios may require cross-cellar queries, these are expected to represent a small fraction of the overall query workload.
• Evaluate read/write ratio: Users will most likely generate much more reads then writes as they will be searching for wines, looking at their KPIs, and so on. Writes should be limited to adding/removing bottles from the cellear. We can safely consider this scenario as read-heavy.
• Mind hard limits: A single cellar should not exceed the current hard limit of 20 GB per logical partition. Given typical usage patterns, it is unlikely that a single cellar would contain enough wine documents (wine references) to reach this limit. Likewise, a single wine reference should not exceed the current limit of 2 MB per document, provided we store bottle pictures (if any) outside of Cosmos.

From a functional perspective, we can expect the mobile app to offer a dashboard view as the home screen to help users quickly get aggregates such as the total number of wines in the cellar, average price, quantity per color, and similar metrics.The app should also facilitate the addition of a new bottle by reusing reference data such as wineries, appelations, merchants, and more.With all of that in mind, we may consider the design illustrated by Figure 7.10:

We have two containers, the WineContainer and the RefDataContainer one. Each container has multiple document types. The WineContainer is using the tenantId as the partition key, which would be the userId extracted from an access token obtained by the mobile app and uniquely identifying the user (owner of the cellar). This means that we'll have as many logical partitions as users (even distribution). Our WineContainer has two document types, both sharing the same partition key:

• The Wine document type represents individual bottles, with each document corresponding to a single bottle. To optimize search capabilities within the app and avoid cross-partition queries, a few reference metadata attributes, such as winery name, are embedded directly within the document. In Cosmos DB, redundancy and denormalization is the norm.
• A critical point is that every query should always include the tenantId partition key, which ensures that queries are scoped to a single partition. Additional filters (for example, wineryName) can be applied without negatively impacting performance, as long as the query remains within the same partition. In this regard, the design is sound and efficient.
• The WineAggregates is a separate document type with its identifier (ID) set to the tenantId, enabling efficient point reads for the mobile app's home screen. As noted earlier, point reads and writes in Cosmos DB provide sub-2 millisecond latency, ensuring a fast and responsive user experience, while being at the same time, the most cost-friendly.

To compute aggregates, we can rely on Azure Functions with a Cosmos DB trigger that uses the Change Feed to capture changes made to wine documents. It's important to note that the Change Feed does not capture delete operations. Therefore, a soft delete strategy—such as marking a wine as deleted with a flag—should be used to ensure the function gets those deletions and updates aggregates accordingly. We can also optionally leverage the Change Feed to capture reference data changes and update wines accordingly. Because reference metadata updates are typically not so frequent, this shouldn't impact too much the overall performance.For reference data, we use a dedicated container with the type attribute as the partition key. This approach allows us to easily distinguish between different document types within the same container. As a result, we will have only three logical partitions—one each for merchants, wineries, and appellations. Given the relatively small size of reference data, we are confident that none of these partitions will approach the 20 GB limit. Furthermore, every query against the RefDataContainer should include the type attribute, ensuring that operations target a single partition for optimal performance and cost efficiency.For more advanced scenarios, consider using hierarchical partition keys and/or further separating containers and document types to better align with access patterns and scalability needs. We hope this example has helped illustrate just how critical thoughtful design is when working with Cosmos DB. Let's now look at some governance aspects.

Governance

In our governance branch, we can find Databricks Unity Catalog and Microsoft Purview. Both aim to provide centralized data governance; however, Unity Catalog is specific to Databricks environments, whereas Microsoft Purview is designed to manage data across a wide range of environments. Purview excels at metadata management, data cataloging, and lineage across a broad set of data services, while Unity Catalog is best for fine-grained data access control and governance within Databricks environments.Purview relies on some infrastructure enablers (SHIR, MVN) described earlier to gain access to a variety of data sources. Let's now bring some of the learned concepts to life by applying them to our use case.

Diagrams

While there are often multiple ways to achieve the same goal, the Data Architecture Map guides us toward suitable services. For time series storage, Azure Data Explorer is a strong fit. Similarly, since sensors are IoT devices, they should communicate with an IoT-compliant service—namely Azure IoT Hub, which appears under the ingestion capability in our architecture map. We have identified the input and the output channels and we still need a service to bridge the two worlds. Although this isn't explicitly shown on the map, we learned that Stream Analytics can ingest data from various sources and supports multiple output options—including Azure Data Explorer, our Time Series Database (TSDB). Since it processes data in motion, Stream Analytics also enables us to compute aggregates and detect temperature anomalies in near real time, with the possibility of forwarding anomalies to a dedicated alerting system.Figure 7.11 is our high-level diagram.

Here are the services we use:

• IoT Hub as the entry point for the ingestion layer. IoT Hub is known to be scalable.
• Event Hubs as the default IoT Hub backend that stores the events.
• Stream Analytics as the message processing layer. Stream Analytics Jobs or Clusters are highly scalable and have been designed from the ground up to analyze, transform and route data streams to many different destinations. In our design, Stream Analytics pulls data from Event Hubs and stores everything into Azure Data Explorer, our TSDB. It also fires alerts to a custom Azure Function whenever temperature anomalies are detected for a few minutes in a row. The purpose is to avoid having a noisy system that raises too many alerts. Stream Analytics serves as the processing layer that bridges raw data ingestion with downstream output channels.
• Note that Azure Data Explorer is able to ingest data from both IoT Hub and Event Hubs directly, but we still put Stream Analytics in the middle as we want to route our alerts directly to Azure Functions. Additionally, while Figure 7.11 is a workable design, an enterprise grade solution would rather call for VNet-integrated components with only IoT Hub exposed to Internet.

However, for sake of simplicity and cost control, the code sample makes use of public-only services and does not provision the IoT Hub since the real ingestion layer from our processing pipeline perspective is Event Hubs. For the same reason, we did not use Power BI as it requires specific licenses but this would be a valid option for our serving layer. The provided example provisions exactly what is shown in Figure 7.12.

Our Infrastructure as Code provides the services illustrated in Figure 7.12. It also grants the required permissions to Stream Analytics to get input data and push it to Data Explorer. We also provide two .NET applications, namely, a device emulator and the function app's code to handle alerts raised by our Stream Analytics job. Let's look at the application code.

Code samples

The device emulator is a console program, which you can run to send events to Event Hubs.

private const string eventHubName = "temperatures";
private static readonly string[] deviceIds = { "store01-fridgeA", "store01-fridgeB", "store02-freezerA" };
private static readonly Random random = new();
static async Task Main(string[] args){
    string connectionString = "";
    if (args.Length == 0 || string.IsNullOrEmpty(args[0]))
        throw new ApplicationException("Usage: ./DeviceEmulator <event hub connection string>");
    connectionString = args[0];
    var producerClient = new EventHubProducerClient(connectionString, eventHubName);
    while (true){
        using EventDataBatch eventBatch = await producerClient.CreateBatchAsync();
        foreach (var deviceId in deviceIds){
            var payload = new{
                deviceId,
                storeId = deviceId.Split('-')[0],
                temperature = Math.Round(5 + 5 * random.NextDouble(), 2), // e.g., 5–10 °C
                humidity = random.Next(60, 90),
                timestamp = DateTime.UtcNow
            };
            string json = JsonSerializer.Serialize(payload);
            var eventData = new EventData(json);
            if (!eventBatch.TryAdd(eventData)){
                Console.WriteLine("Event too large, skipping.");
                continue;
            }
            Console.WriteLine($"Sending: {json}");
        }
        await producerClient.SendAsync(eventBatch);
        await Task.Delay(TimeSpan.FromSeconds(5));
    }
}

The program expects to receive the connection string of the Event Hubs as an argument. It then generates and sends a series of random events every five seconds.As stated earlier, anomalies should be detected by Stream Analytics and sent to a function. Here is the code of that function:

[Function("TemperatureFailureAlert")]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req){
    try{
        string body = await new StreamReader(req.Body).ReadToEndAsync();
        var events = JsonSerializer.Deserialize<List<SensorData>>(body, new JsonSerializerOptions{
            PropertyNameCaseInsensitive = true
        });
        foreach (var e in events){
            _logger.LogWarning(
                "Abnormal temperature {0} detected for Device {1} from store {2} alert: {3}.",
                e.AvgTemp, e.DeviceId, e.StoreId, e.AlertMessage);
        }
        return new OkResult();
    }
    catch (Exception ex){
        _logger.LogError(ex, "Exception occurred during function execution.");
        throw;
    }
}

This code is an HTTP-triggered Azure Function (POST) that receives a batch of events from our Stream Analytics job. Its current role is limited to logging the incoming events. In a real-world scenario, it would naturally process them further, but our objective here is simply to demonstrate the communication flow. As previously mentioned, Power BI Real-Time Dashboards could be a suitable alternative, enabling a monitoring team to detect anomalies almost immediately.Paradoxically, the hardest and heaviest part of the code is dedicated to the Infrastructure as Code setup. For the sake of brevity, we'll focus only the Stream Analyties queries but you can explore the full code further on your own. Here are the queries performed by Stream Analytics:

SELECT deviceId, storeId, temperature, humidity, timestamp INTO adx FROM temperatures TIMESTAMP BY timestamp;
SELECT deviceId, storeId, System.Timestamp AS alertGeneratedAt, AVG(temperature) AS avgTemp, 'ALERT: Avg temp > 3°C over 5 minutes' AS alertMessage INTO alert FROM temperatures TIMESTAMP BY timestamp GROUP BY deviceId, storeId, TumblingWindow(minute, 5) HAVING AVG(temperature) > 3;

The first query ingests all events from the Event Hub source (temperatures) and writes them to Azure Data Explorer (adx). The second query filters events and sends them to our function (alert) only when the average temperature exceeds 3 degrees over a rolling 5-minute window. We intentionally set this low threshold to trigger alerts frequently, purely for demonstration purposes. In the real world, you would probably set the threshold to 6 degrees. The remaining parts of the code are more complex and offer valuable insights, particularly in terms of automation—which proved to be far from straightforward. Let's now see how to test the solution.

Testing the solution

To test this solution in your own tenant, you must:

• Have an Azure subscription with owner permissions. Folllow this link to start a new trial if required https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account.
• Install Azure CLI. Follow the instructions available here https://learn.microsoft.com/en-us/cli/azure/install-azure-cli.
• Install Terraform. Follow this link https://developer.hashicorp.com/terraform/install where you can find binaries for all operating systems. This only takes a few minutes!
• Clone the map book repo or download the code.
• Have Visual Studio Code.
• Open the cloned/downloaded folder with Visual Studio Code. Make sure to run az login before any other activity.
• Navigate (cd) to this folder: Chapter 07\use-case\IaC.

Once in the correct folder, open config.yaml file and adjust the following variables to your needs:

location: "swedencentral"
resourceGroup: "mapbook-chapter07"
tenantId: "<tenantId>"

Note that the deployment script has only been tested against the swedencentral region so you'd better stick to this region as not all regions have the same pricing tiers available, especially for Data Explorer. If you use another region and encounter a failure, either adjust the service SKUs that we defined, either switch back to Sweden Central. The only variable that you must adjust is the tenantId one. You can get your tenant ID with the following Azure CLI command:

az account show --query tenantId --output tsv

Once done, from the Visual Studio Code terminal, you can run the following commands:

terraform init
terraform apply --auto-approve

The script takes about 15 minutes to complete and deploys the resources shown in Figure 7.13.

All the resources of our diagram are deployed. Note that the names are unique and will not be exactly the same in your environment. The first thing to do is to get the connection string of our Event Hubs (highlighted in Figure 7.13) that we will pass to our device emulator at a later stage. Follow these steps:

• Click on the Event Hubs
• Then, click on Shared access policies under the Settings blade.
• At last, click on RootManageSharedAccessKey and get the primary connection string as show in Figure 7.14:

Keep the value somewhere as we will reuse it later. For now, you should start the Stream Analytics Job. To do so, just click on the Stream Analytics resource available in your resource group and click on Start job. Take a moment to explore inputs and outputs, as well as the query, all shown in Figure 7.15.

Now that you started the job, you can send events to Event Hubs. Our job should pick them up, analyze them, and send everything to Data Explorer and anomalies to our Azure function. Note that our function's code was also deployed automatically by the Terraform script.To start the emulator, you can either open the provided .sln file with Visual Studio and rebuild the application, which will generate an executable file, either unzip the provided zip file named DeviceEmulator.zip. Once you have the executable file, open a PowerShell command line and execture the program:

./DeviceEmulator.exe <event hub primary connection string>

This should start sending events as shown in Figure 7.16.

Note:

The event hubs key was removed from Figure 7.16 but should be passed as a parameter. Additionally, the screenshot has been truncated because of size constraints.

It may take some time before data appears in Azure Data Explorer and before our Azure Function gets called. This delay is typically due to the startup time of the Stream Analytics job and the use of free or lower-tier pricing plans. So, don't worry if the data doesn't show up right away—this behavior is expected. After a few minutes, go to your Azure Data Explorer instance and check if you have data as illustrated in Figure 7.17 and 7.18.

Figure 7.18 shows how to view the entire dataset:

The last step to check is whether our function got fired by Azure Data Explorer. Go to the Azure Function App and click on link labelled Invocations and more. You should land on this page:

Clicking on any row will open a window detailing the execution of the function.

Note that Stream Analytics invokes the Azure Function at each query evaluation interval, results in function executions receiving an empty array ([]). This behavior is expected. You can see what is sent by Stream Analytics by testing the query in the Azure Portal and check the function output.Feel free to explore the end to end solution and do not forget to delete the resource group afterwards to avoid unexpected costs.Let's summarize this chapter!