Before adoption can begin, you must create a landing zone to host the workloads that you plan to build in the cloud or migrate to the cloud. The ready phase ensures that the environment is prepared for the Microsoft cloud adoption plan. Before you start building and deploying solutions using Azure services, you need to prepare the environment. To organize one’s resources, management hierarchies within the Azure platform, well-thought-out naming conventions, and resource tagging can be used. Azure provides four levels of management scope: management groups, subscriptions, resource groups, and resources. The following image shows the relationship of these levels.
At any of the management levels, one can apply management settings, like policies and role-based access controls. The level selected determines how widely the setting is applied. Lower levels inherit settings from higher levels. A good naming standard helps to identify resources in the Azure portal, on a bill, and in scripts. Tags are useful to quickly identify your resources and resource groups. You apply tags to your Azure resources to logically organize them by categories. Each tag consists of a name and a value. For example, you can apply the name “Environment” and the value “Production” to all the resources in production. After you apply tags, you can retrieve all the resources in your subscription with that tag name and value.
Managing who can access your Azure resources and subscriptions is an important part of your Azure governance strategy and assigning group-based access rights and privileges is a good practice. Azure role-based access control (RBAC) is the primary method of managing access in Azure. It helps you manage who has access to Azure resources, what they can do with those resources, and what scopes they can access.
Another important consideration is to manage costs and billing for your Azure resources. Cost management is the process of effectively planning and controlling costs involved in your business. Azure Cost Management provides a few ways to help you predict and manage costs. As you establish corporate policy and plan your governance strategies, you can use tools and services like Azure Policy, Azure Blueprints, and Azure Security Center to enforce and automate your organization’s governance decisions. Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. Azure Policy is a service that you use to create, assign, and manage policies. These policies enforce rules on your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Security Center plays an important part in one’s governance strategy. It helps to stay on top of security because it provides a unified view of security across your workloads. Azure offers many services that together provide a comprehensive solution for collecting, analyzing, and acting on telemetry from your applications and the Azure resources that support them. Azure Monitor provides a single unified hub for all monitoring and diagnostics data in Azure. You can use it to get visibility across your resources. Azure Service Health provides a personalized view of the health of the Azure services and regions you use. Information about active issues is posted to Service Health to help you understand the impact to your resources. Azure Advisor is a free, personalized cloud consultant that helps you follow and implement best practices for Azure deployments. It analyzes your resource configuration and usage telemetry and recommends solutions that can help optimize your environment. Azure Security Center also plays an important part in your monitoring strategy. It can help you monitor the security of your machines, networks, storage, data services, and applications. Security Center provides advanced threat detection by using machine learning and behavioral analytics to help identify active threats targeting your Azure resources. Cloud platforms like Microsoft Azure change faster than many organizations are accustomed to. This pace of change means that organizations have to adapt people and processes to a new cadence. Resources like Azure Service Health, Azure Updates, Azure Blog or Azure Info Hub can help you stay up to date.
As mentioned above, before adoption can begin, you must create a landing zone to host the workloads that you plan to build in the cloud or migrate to the cloud. A landing zone is the basic building block of any cloud adoption environment. The term landing zone refers to a logical construct capturing everything that must be true to enable the desired cloud adoption. A fully functional landing zone considers all platform resources that are required to support the customer’s adoption needs. The goal of the landing zone approach is to create a common set of consistent platform implementations. Those consistent implementations must be in place to ensure that your applications have access to requisite components when deployed. Landing zones do not necessarily differentiate between IaaS or PaaS adoption. However, landing zones are purpose built to support the adoption plan by fulfilling the subscription strategy. Supporting the adoption plan may require multiple landing zones with a mixture of required components.
Infrastructure as code is a natural transition during most Microsoft cloud adoption efforts. Deployment of your first landing zones in the cloud is a common starting point in moving to a code-driven environment. The following image shows a variety of options for landing zones.
A. Start with code to produce consistent, repeatable landing zones. If you’re comfortable with refactoring (or refining the code and infrastructure) as you learn, start with a lightweight code base, like the Cloud Adoption Framework’s Migrate landing zone blueprint. This approach accelerates adoption success and creates hands-on learning opportunities. However, this type of initial landing zone is not designed for sensitive data or mission-critical workloads, without additional refactoring.
B. As adoption grows and requirements become more clearly identified, the adoption and platform teams will refactor landing zones based on what they learn. The process of expanding your landing zones prepares environments for more complex compliance or architecture requirements.
D. When a partner provides ongoing managed services or is contracted to deliver on the adoption plan, they will typically provide their own landing zone. Using a partner landing zone could accelerate adoption efforts and ensure consistent operational management requirements. Migration landing zone is a term used to describe an environment that has been provisioned and prepared to host workloads being migrated from an on-premises environment into Azure. But before you use the migration landing zone blueprint in the Cloud Adoption Framework, some decisions, implementation guidance and assumptions like subscription limits, compliance or architectural complexity has to be reviewed.
Azure provides native services for deploying your landing zones. Other third-party tools can also help with this effort. One such tool that customers and partners often use to deploy landing zones is HashiCorp’s Terraform.
About the Author:
I am Matthias Gessenay, and I am a Microsoft MVP for Azure, Microsoft Certified Trainer and Azure Architect for Corporate Software. I am in IT for about 20 years, and dealing with Azure since about six years. I am passionate about community and run four Meetup groups.
Gessenay, M. (2020). Microsoft Cloud Adoption Framework for Azure – Ready (Part III). Available at: https://cloudspeed.ch/post/azure-cloud-adoption-framework-part3/ [Accessed: 19th May 2020].
Check out more great Azure content here