Building Azure landing zones means to leverage a scalable, modular approach to building out your environment based on a common set of design areas. Consequently, knowing and understanding the type of the application and workload (consequently called archetype) is important, as some of the Azure services do have specific requirements and platform dependencies.
The importance of the archetype also called out in the critical design areas, for example Red Hat OpenShift with regards to the DNS infrastructure. Furthermore, this is also one of the reasons why you see different management groups below the landing zone management group. In this specific case, which basically is the Contoso reference implementation, there are three specific landing zones: SAP, Corp and Online.
From the Contoso reference implementation:
How to build archetype landing zones?
In order to build a landing zone for an used archetype, you need to understand all the specific requirements and dependencies. Unfortunately, there is no single place where you can find this information, but you need to gather this information for every Azure service used with this archetype.
However, a general recommendation is to leverage the Azure Architecture Center where you can find many useful information. One specific example I would like to mention is Azure Kubernetes Service (AKS) within the Architecture Center.
In the AKS production baseline (reference architecture), you will find a baseline infrastructure that deploys an AKS cluster, with focus on security. The baseline includes recommendations for networking, security, identity, management, and monitoring of the cluster. Consequently, it’s aligned with the critical design areas in Enterprise-Scale.
Let’s look at one of the covered topics, which is networking security. The documented ingress and egress traffic flow are aligned with the recommendation you will find in Enterprise-Scale. To be specific, using an Application Gateway and Web Application Firewall (WAF) to protect ingress traffic and use a Firewall, deployed in the (managed) hub, to protect egress traffic. But something that you will not find mentioned specifically in Enterprise-Scale are the recommended Azure Policy add-on for AKS. Although policy-driven governance is one design principles in Enterprise-Scale, at this juncture you may have to build an AKS landing zone including all the required policy and also role configurations specifically addressing AKS. This may include network, storage, RBAC, and others.
Thus, in a nutshell, and also my personal approach (now independent of AKS):
The role of Well-Architected Framework
The AKS production baseline mentioned above also follows the Azure Well-Architected Framework. Though this is an AKS specific use case, all the deployed applications should follow the Well-Architected Framework, and therefore should address:
Or in other words: Enterprise-Scale provides the all important recommendations for the platform engineering, the Well-Architected Framework all important recommendations for applications and workloads.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.