Cloud Adoption Framework: The First Stage in Launching a Landing Zone

In a recent post, we looked at the essential foundations for building a cloud digital factory. To recap, here are some of the technical components you need in addition to organization. 

These are the technical building blocks. The cloud is, by nature, constantly evolving. More features are added every day. The sheer scope makes it tough to keep up with all the changes and make sure nothing is overlooked. 

Delivering and operating this infrastructure requires a systematic approach (and technology). At Microsoft, this takes the form of the Cloud Adoption Framework. Its purpose is to provide: 

• A systematic approach that includes business and organizational aspects, implementation options, and recommendations 
• Examples of implementations to use as a starting point. 

This methodology is more comprehensive since it includes the following: 

• Defining the strategy 
• Devising a plan to go with the strategy 
• Implementing that strategy on a technical level (implementation of landing zones) 
• A system for migrating our applications to Azure 
• Promoting innovation 

• Providing a framework to ensure long-term governance 
• Ensuring you can operate the infrastructure from day one 
• Aligning organization and technology 

Consider the Cloud Adoption Framework an accelerator for your cloud adoption. You could build without it, but why make things more complicated? 

In this post, we will concentrate on the implementation. We are familiar with the various technical building blocks. Now, we need to put them together to create a landing zone. 

What is a landing zone? 

The name is inspired by space exploration. When a rocket is built to fly to the moon, it sends a valuable load (a satellite, a lunar lander, etc.). The purpose of the landing zone in Azure is not to send our digital product/application into space but to provide it with the services it needs to complete its mission. The issue is that every digital product/application has unique requirements. This can make it challenging to think up a tailor-made solution that goes against the industrial approach promoted by the cloud. You need to think of the landing zone as an industrialized product delivered through a production line that needs to respond to as many needs as possible. Therefore, a factory can have multiple production lines to offer various landing zones to consumers. 

Typically, a landing zone is delivered within a dedicated Azure subscription because: 

• Isolating digital products/applications into separate subscriptions helps to separate roles and responsibilities better 
• A subscription is a billing unit that simplifies re-invoicing for services rendered 
• A subscription is a straightforward security limit to isolate in the event of a real security risk. 

The Cloud Adoption Framework: A factory with multiple production lines 

Note: the industrial landing zone approach allows you to deliver quickly while ensuring that previously delivered landing zones are updated. Not keeping previously delivered landing zones up to date is not an option. As the team in charge of the landing zones, we remain responsible for them. 

Like space exploration, going to the moon takes teamwork. The one-man-band approach used in Azure will not work. We need a multidisciplinary team to address issues as diverse as: 

• Identity 
• Security 
• Costs (controlling budgets is inevitable) 
• DevOps culture 
• The network (also known as “cloud plumbing”) 
• Governance 

How to Build a Landing Zone 

You can start from scratch or use the Cloud Adoption Framework (CAF) as a starting point. Since there is no blanket solution for all business cases, the CAF provides: 

• Two landing zone types depending on the size of the company (small and enterprise-scale) 
• Two deployment modes (Blueprints/Terraform module) 

In terms of Azure, a landing zone should have a set number of services, whether these are included in the subscription (the case with small landing zones) or considered shared services available to all landing zones (the case with enterprise landing zones). 

Small landing zone illustration – Source: Microsoft documentation 

The intriguing aspect of landing zones provided through the Cloud Adoption Framework is their modular deployment. The modular structure in the diagram below lets you gradually roll out: 

• Shared services (placed in one or more hub subscriptions) 
• The various landing zones 

This modularity allows you to respond to the need for scalability to host more digital products/applications within an existing infrastructure (scale up) or to host them closer to your new markets (scale out). 

Click the image to start the animation. 

Illustration: Modular deployment based on company size (Source: GitHub public Cloud Adoption Framework) 

Implementation details for these landing zones can be found here. Let’s take a closer look at that. 

An In-Depth Look at Blueprint Landing Zones 

As stated earlier, there are several ways to deploy a landing zone. Firstly, we have blueprints. Think of blueprints like tracing paper. Applying it to a subscription lets you ensure that various components are implemented in your landing zone. The first advantage of this deployment method is that it is already included in your subscriptions. You simply need to request the creation of a blueprint from an existing template. 

Illustration: How to create a cloud adoption framework blueprint 

This template can be customized as required with: 

• Role-based access control (RBAC) 
• An Azure policy assignment 
• The creation of resource groups 
• Deployment of an Azure Resource Manager (ARM) template

Illustration: Content of the cloud adoption framework blueprint 

We create a new version of the blueprint every time we add an element. We can keep previously delivered landing zones up to date using this versioning system. An Azure DevOps pipeline is used to deploy it. That pipeline is responsible for publishing the blueprint (and creating a new version if necessary) and assigning it to the chosen Azure subscription.  The blueprint approach is ideal for smaller structures. The Terraform template is better suited to larger organizations. 

An In-Depth Look at Terraform Landing Zones 

The second deployment method is based on Terraform, specifically, on the Terraform modules available in the Terraform Registry. To make things easier, everything is provided in the form of a Docker container named “Rover,” which you can run locally and then via Azure DevOps later on. There are several advantages to this approach: 

• You always work with identical versions of Terraform and the associated modules. This ensures that our deployments are reproducible locally and throughout our Continuous Integration/Continuous Delivery (CI/CD) chain. 
• You are not dependent on your execution environment. There is no danger of getting a different outcome when deploying the same configuration from your CI/CD chain. 
• You have a working framework from the outset. 
• The model is scalable to take into account your organization’s specific needs from the landing zones. 

Using Terraform modules offers a host of benefits: 

• Guaranteed uniformity in the naming charter 
• Guaranteed uniformity when propagating tags 
• A framework for easier scaling 

It is more complicated to apply, but you can quickly implement the local environment once you have the Visual Studio (VS) code, Remote Development extension, and Docker. If you would like to learn more, I highly recommend this post by Arnaud Lheureux: Cloud Adoption Framework landing zones with Terraform, which talks about the Rover. 

Cloud Adoption Framework Rover – Image source 

The Rover’s Terraform module library is growing by the day. As you can see, it goes far beyond the basics we need to create our landing zone. This approach allows you to standardize your deployment of most Azure resources. It is more than enough. Watch the following videos to explore this subject in more depth: 

• Cloud Adoption Framework for Azure landing zones on Terraform – Episode 1 – Introduction 
• [Video] Cloud Adoption Framework for Azure landing zones on Terraform – Episode 2 – Demo installation 

Azure Landing Zone Accelerator 

The Cloud Adoption Framework is evolving at lightning speed. The fact that we can now deploy complex landing zones directly from the Azure portal, as shown below, demonstrates this: 

Azure Landing zone accelerator 

The deployment in this configuration uses an ARM template. This is an interesting way of quickly testing your solution. The drawback is that you cannot customize it as much as the Rover with its Terraform modules. Visit this website if you like the sound of this approach: https://aka.ms/caf/ready/accelerator 

What is the Second Stage of the Launch? 

Once you have deployed your landing zone and industrialized its deployment via an Azure DevOps pipeline, the temptation is to quickly develop new services that can bring value to your customers. Eventually, maybe, but you need to get your first customers on board before you do that. This onboarding phase is often underestimated. It can even be a major factor in the failure of landing zone projects. Onboarding means that your product (the landing zone) is attractive enough to consumers that they subscribe. You therefore need: 

• Consumers, or better still, early adopters, who are willing to test and provide feedback on your landing zone. These consumers and their input will help you decide which services to offer later. 
• Documentation for your consumers explaining the purpose of their landing zone and how they can get the most out of it. If you do not demonstrate how you have made life easier for your consumers, they will most likely waste time dealing with the same issues. 
• To provide training and support to your consumers. Never assume that your consumers know as much about Azure as you. Often, they will need some help initially before they get the hang of things. Consider training a long-term investment. If they lack independence, consumers will turn to the experts – that’s you! That means you’ll spend more time supporting your consumers than developing your landing zone product. 

Once you have successfully onboarded some consumers and they can deploy their digital product/application through to production, it is time to start thinking about new services. This is the second stage of your launch. The Cloud Adoption Framework does not cover this aspect. Your landing zone is a product that must persuade the consumer. There are a few things to consider before we start: 

• You are accountable and responsible for the products you develop for your consumers. This quality/reliability criterion is not met overnight. You don’t become Site Reliability Engineering (SRE) just by renaming a team. It is a culture that must be developed over time, and, unfortunately, many of its failures are taught. 
• Your service must address a stated need. Put yourself in the shoes of someone using your landing zone by asking yourself:  
  • What is my primary need for this digital product as a landing zone consumer? 
  • What is the most complex issue I have to deal with to get to production as a landing zone consumer? 
  • What is the biggest obstacle facing the product as a landing zone consumer? 
  • How much would I be willing to pay for this service as a landing zone consumer? 

Before you begin, think about what the Cloud Adoption Framework has to offer as a starting point. There are already bases available for the following scenarios: 

• Cloud-native apps using an Azure Kubernetes Service reference implementation 
• Data analysis and artificial intelligence: Introduction to enterprise-scale for analytics and AI in Azure 

The Cloud Adoption Framework gives us the best practices to follow (patterns) and pitfalls to avoid (antipatterns) when building our landing zone product. Keep these antipatterns in mind. They will help you avoid numerous problems. 

From Theory to Practice 

To summarize, the Cloud Adoption Framework is a framework and working basis for accelerating the transition to Cloud Azure.  It is an accelerator for implementing the necessary “technical plumbing,” but remember that it is a tool to support a strategy and involves teamwork. 

The first step is to have a defined strategy in place. Cellenza can help you devise and implement your strategy. 

I recommend Microsoft’s Learning Path if you want to learn more about the Cloud Adoption Framework.