The Cloud Adoption Framework has lots of information on landing zones. (https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) The guidance here is quite comprehensive and you should take a read through it. However, what we’re going to do here is give you a simplified analogy for landing zones that will help you remember how things fit together.
Getting your landing zones right is essential for the security, governance and operation of your whole business. Hopefully this article will make things a bit clearer.
Imagine you run a farm. All the central admin of the farm is done from the farmhouse, that’s where you decide what’s going to be grown in each of the fields. This is where you govern things. This is where you decide how you’re going to keep things secure. Think of this as your platform landing zone. You’ll sometimes hear about a “hub and spoke” model, well this is the hub.
Now, on the farm you have fields where you grow crops. Generally, in a field, you’ll have a single type of crop. This means before planting, you’ll prepare the field for the crop that’s going in there – the way you plough and fertilize it will be targeted at this. You’ll have secure fences around the field so that you can protect what’s inside. Think of fields as your application landing zones. In a hub and spoke model these are the spokes.
In the field you then have your crops. Think of your applications as crops. You have your crops (applications) in fields (application landing zones) while still managing them from the farmhouse (platform landing zone). Ultimately it’s the crops (applications) that have the value, but all this other infrastructure is built around them to keep them safe and make them manageable.
Finally, you need to move around. You have tracks and gates to get from the farmhouse to the fields. This is the connectivity. Think of this as your network connections, or your network peering as we might say. To get from one field to another, you have to go on a track and through a gate. When you set up the farm, you decided where the tracks were and where the gates are. Similarly, in a cloud application you’ll decide which application landing zones can connect to others, and whether these connections are inbound-only, outbound-only or inbound-outbound.
Platform landing zone
Don’t host applications in here or it will get messy
Application landing zone
The infrastructure your applications need
Virtual network and connectivity to hub
Further policy over what’s inside the spoke
You can only do what’s allowed by the policy set in the hub
Runs part of your business
Conform to policies
Emit instrumentation events
Must confirm to the spoke’s infrastructure
Must conform to hub policy and spoke policy
Can only connect via networks links you control
345 AIR is the most secure Azure platform for integration and data projects. At its heart is an application landing zone for integration projects. When you deploy 345 AIR you have all the core services upon which integration apps are built.
In Azure, these are known as Azure Integration Services (AIS):
This is all great stuff, but it doesn’t tell you the best way to deploy these services in a secure way that fits with a landing zone model. There’s an AIS landing zone accelerator (https://github.com/Azure/Integration-Services-Landing-Zone-Accelerator) available from Microsoft – which is great for a demo or a proof-of-concept – but for a production-strength implementation you’ll need a lot more.
That’s why we created 345 AIR. The foundational application landing zone components, the virtual networks, private link security, DevOps, ability to roll out multiple environments such as Development and Test. All this is built-in.
The thing is, landing zones are really easy to think of conceptually but they need to be done right. Get it right and building and running apps is a pleasure. Get it wrong and you’ll constantly be fighting to have a secure and easily-managed cloud estate.