Readying your cloud migration: operating models and Azure landing zones

Prefer to read our insights? Here’s the full transcript of our video:  

Gina: Hi everyone and welcome back to another episode of the Azure 101 series.  

Last time, we were looking at the Cloud Adoption Framework, specifically, the Plan phase. We showed the key considerations in this phase and some helpful resources that you could use. 

For this episode, we are going to be exploring how your organisation can get ready for Cloud migration.   

Sam:  Yep, that’s right Gina, and we will then take a sneak peek at where this leads, which is to Azure landing zones, and why we need them to get ready for an Azure cloud migration. In our next video we will dig into each type of Landing Zone in a little bit more detail.  

So, lets jump straight in. 

In previous videos, we talked about creating the Strategy and Plan, so we know the why and the what behind our migration. 

The Ready phase is all about the how, and to get the details of our how, we need to consider our cloud operating model. 

You may be thinking “what does this guy mean by operating model – can't I just buy Azure ‘out of the box’”? 

The issue here is that if you don’t know how you intend your teams to use Azure, you might end up with a configuration that isn’t fit for purpose and is quickly outgrown. The worst-case scenario is that you end up spending a lot more money on resolving problems, compared to if you had adopted the cloud with best practise in mind. 

Gina, do you want to cover the operating models and what we mean? 

Gina: Sure. 

The operating model you use in Azure will outline your team engagement and there are three options to choose from: two are traditional deployment methods and one is Microsoft-recommended best practice. Your organisation may already use one of these models. 

First up we have Decentralised. This is all about increasing innovation by putting the development team in charge of its own destiny. 

This is still a popular way of working for many organisations, even now.   

However, the danger here is that this operating model lacks standardisation of resources and could possibly become more expensive.  

Secondly, we have the Centralised model. This model involves IT infrastructure being managed by a central IT team. This is great for allowing regulation and control, which is important for any organisation.  

However, it may overly standardise all workloads, hindering any specific requirements for development teams and even stopping quick wins and innovation.  

The old saying is very true here! Developers develop and Architects architect.  

Sam: That is the dilemma that we have seen with many organisations, so how do we get an operating model that works without limiting one or both teams?  The Enterprise Operating Model is just the ticket.  

It combines the flexibility of the decentralised model and the standardised control of the centralised model.   

What will happen is central IT will be responsible with managing shared workloads such as Networking, Identity, Baseline security.   

Then the application teams can be responsible for managing their specific application workloads using services and tools. And implement the granular security that they need without blocking innovation.  

Gina: That’s right Sam and this is the very reason we need a landing zone. It will help us to deploy that enterprise operating model through the use of platform and application zones.  

Interestingly, the type of landing zone you deploy will impact the phases that follow. So, let’s have a look at what a Landing Zone is.  

Sam: In a nutshell a Landing Zone is the building block for setting up an Azure environment and our operating model.   

Platform zones are for shared resources so these may be things like identity, baseline security or management resources. This is normally where central IT may have more control.  

They would be able to deploy these zones with all the controls and governance that is needed by the organisation to operate. The baseline configurations that they set can also flow down to the application zones as well so that governance is consistent. Central IT can then monitor and manage it centrally.   

Next, we have application zones which are for application specific resources. Now this could include more granular security resources beyond that of the baseline or may be resources like VMs, databases, storage networking or even dev tools.   

This is normally where the development teams would spend their time, and they would have the flexibility to set roles and permissions on these zones as required – as long as it didn’t conflict with baselines set by central IT. Meaning that if they wanted to create a new resource, they could do without needing Central IT to get involved.   

Gina: That makes sense and it’s worth noting that within each of these zones there are native tools for setting up your Azure environment.   

These are:  

• Azure Blueprints which provide you with the mechanism to repeatedly deploy your policies, roles, and templates. 

• Azure Policies which apply the guardrails to your Azure estate, for example, only allowing resources in certain geographical locations. 

• Azure Role Based Action control, or RBAC, which provide the authentication mechanism to access, monitor and manage your Azure resources and data on those resources. 

• Azure Resource Manager or ARM templates which is a JSON file for deploying an environment. 

The best way to explain this is Landing Zones are similar to how you would find the foundations of a house or even a sky scraper, the same is true with Azure Landing zones.  

Sam: That’s a great point Gina and once again just like we saw with the Operating model there are three types of landing zone which are:  

• Azure Migrate Landing zone – this is normally a single resource group in an Azure subscription.  
   
  It will separate networking and share resources such as Key Vault or Log Analytics. As well as have a separate resource group for the Azure Migrate data that is collected prior to migration. 

• Start Small and Expand Landing Zone AND Enterprise Landing Zone – these are where you will possibly migrate your Azure Migrate workload to after adopting Azure.   

Gina, can you take us through the differences between the last two?  

Gina: Happy to.  

The Start Small and Expand landing zone gives an organisation the option to deploy their platform and application zones into a single or maybe a few subscriptions.  

They start with a baseline and then add security, governance, and compliance over time.  

The unit of measure in this instance is the resource group.  

The Enterprise landing zone approach however involves deploying into multiple subscriptions with pre-configured resources and controls. The Platform and the application zones would be separate making it easier to scale and monitor as well as manage.  

The unit of measure this time are subscriptions.   

You don’t have to be an Enterprise to use this landing zone, it just references having an enterprise mindset which is a good thing to follow.  

The enterprise approach requires everything to be ready before migration, making it more complex. While improvements to the Enterprise landing zone will still happen, they will be less frequent than the start small and expand approach.  

The good news is that there is no right or wrong choice for Landing Zones. The key is to ensure the Landing Zone fits your motivations and the business outcomes you defined in the strategy.  

Organisations can start using Azure immediately and optimise over time using start small and expand, but the goal should be to implement Enterprise landing zones.   

These zones combine centralized control with the freedom to innovate from a decentralised model.  

Sam: So, that’s it once again, in our next video we will take a closer look at the landing zones since they will also impact the follow-on phases like management and governing.  

Until next time its goodbye from us.