Feature Request - IaaS Workloads Landing Zone

[SteveBurkettNZ]

Describe the solution you'd like

We're starting to migrate the 3.5k on-premises servers to Azure using Azure Migrate, and the first question is where are these going to live?

It feels like the current CAF could be extended with a IaaS Workloads Landing Zone defined that's built to be the target for Azure Migrate but also any IaaS VM based workloads where there's just the one or two servers. Going the whole hog of creating separate Application Landing Zones for a single virtual server to sit in is overkill, we want a common Application Landing Zone built to house many virtual servers. We're looking for guidance on the best way to prep this specific-case Application Landing Zone, and it would be nice if it could be rolled out as part of the various IaC offerings (we used the Azure landing zones Terraform module to prep our CAF).

Discussion points

• Should this sit under the Landing Zones management group, and inherit the various Azure Policies from there? Or should it sit out to the side, so that specific Azure Policies applicable to IaaS workloads can be assigned, to limit the risk of breaking applications once migrated in?
• Should we be using a VNet for each VM tier, requiring multiple VNet peering's back to the hub, or just separate the front-end, application, and data tiers using subnets and NSGs?
• Migrated applications often have a SQL database included; can we get a common database service created as part of this IaaS Workloads Landing Zone to be used as the target for the migrated application databases? We're primarily looking at a shared Azure SQL Managed Instance (or pool of instances) for this but might well find we also need a shared SQL Server on VM service due to compatibility issues with some older apps. Again, it'd be nice to have guidance (and indeed code) to help get a robust data layer created designed for IaaS VM workloads.
• And how should the Azure Migrate services be included into this?

Whether this is a job for the CAF/Enterprise-Scale team, or whether it's an off-shoot project for the Azure Migrate/IaaS team I don't know. But seems like this would be a fairly common requirement for most businesses looking to move in to Azure?

[jtracey93]

Hey @SteveBurkettNZ,

Thanks for the feature request.

Firstly, id really value your inputs on this video we created here: https://www.youtube.com/watch?v=R-5oeguxFpo about how many subscriptions you need etc. We have a section on scenarios (about 6 mins in) and we cover a DC exit scenario.

To me the ask feels like more a cloud adoption scenario we could add for DC exit's, agree?

To your discussion points:

• Should this sit under the Landing Zones management group, and inherit the various Azure Policies from there? Or should it sit out to the side, so that specific Azure Policies applicable to IaaS workloads can be assigned, to limit the risk of breaking applications once migrated in? - Yes beneath corp typically. If concerned about policies you could set their enforcement mode to disabled to turn them all to audit only mode as per: https://learn.microsoft.com/azure/cloud-adoption-framework/ready/enterprise-scale/dine-guidance
• Should we be using a VNet for each VM tier, requiring multiple VNet peering's back to the hub, or just separate the front-end, application, and data tiers using subnets and NSGs? - If inside a single application workload landing zone subscription then a single VNET and using subnets, NSGs, ASGs to create micro-segmentation would be what we see most commonly. But placing things like ADDS DCs in the identity subscription and starting to break obvious pieces out like the platform resources.
• Migrated applications often have a SQL database included; can we get a common database service created as part of this IaaS Workloads Landing Zone to be used as the target for the migrated application databases? We're primarily looking at a shared Azure SQL Managed Instance (or pool of instances) for this but might well find we also need a shared SQL Server on VM service due to compatibility issues with some older apps. Again, it'd be nice to have guidance (and indeed code) to help get a robust data layer created designed for IaaS VM workloads. - This would very much depend on the assessment of the source DBs and apps as to whether they will support modernisation. Using tools like Azure Migrate https://learn.microsoft.com/azure/migrate/concepts-azure-sql-assessment-calculation or SQL DMA https://learn.microsoft.com/sql/dma/dma-assesssqlonprem?view=sql-server-ver16
• And how should the Azure Migrate services be included into this? - As above. The target would be the new application workload landing zone subscription

Looking forward to discussing further :)

[SteveBurkettNZ]

Thanks for the reply @jtracey93!

To me the ask feels like more a cloud adoption scenario we could add for DC exit's, agree?

Yes absolutely. We've already gone through and done the basic CAF/Platform setup with Connectivity, Identity, Management subscriptions, containing ADDS DC's, ExpressRoute, central Log Analytics Workspaces etc etc. That's deployed and ready to go.

We're now looking to prep a blank area that'll provide all the foundations for those IaaS-based workloads that will be being lift-and-shifted out of the on-premises DC"s and into Azure. It'll have separate subscriptions for Dev, Test, Prod VMs. It'll need a common SQL in there to be used as a destination for the databases used by the various migrated workloads. We'll want Azure Policy to enable Diagnostic Settings and install the various Azure extensions on any VM's that turn up there, logging back to our central Log Analytics workspace. It'll have peering in place back to the central hub network.

It should almost be a bolt-on to the current ALZ modules that preps an area specifically suited for the standard lift-and-shift of application VM + database workload scenarios. You could choose to opt in to deploy it as part of the main ES LZ deployment, making use of all the standard ES LZ Platform components, slotting into the right place in the Management Group structure, getting the Vnets peered to the central hub, and giving the customer the basic setup that they'll need to proceed with their Azure Migrate project. My guess is very few customers getting established in Azure aren't looking to lift-and-shift a bunch of VMs as one of their first projects for their new Azure platform?

At some point in the future, it's expected we'll enter that Enhance phase and revisit those lift-and-shifted solutions, modernizing out in to separate application landing zones as appropriate with PaaS replacements, but for now it's just a DC exit exercise as you say.

The assessment of the workloads/database compatibility would be outside of this conversation.

But there must be a standard application landing zone deployment that the Fasttrack teams recommend when they have a customer come to them with a couple of thousand Windows servers that they're looking to bulk get out of their on-premises DC and in to Azure?

[jtracey93]

Hey @SteveBurkettNZ,

Do they recent Landing Zone Vending modules meet your requirement here as creating the platform components ready to host your workloads?

HTTPS://aka.ms/LZ-vending/TF & HTTPS://aka.ms/LZ-vending/bicep

Let us know

[SteveBurkettNZ]

Yeah, I think the LZ-vending module is part of the solution. Maybe it just needs to be extended with a pre-canned configuration for the above 'special-case' migration target environment?

[jtracey93]

Hey @SteveBurkettNZ,

Just been mulling this over some more and am thinking that with ALZ and the LZ-Vending (sub vending) modules you should have everything you need to complete the migrations for typical lift and shifts.

If you place the subs in the corp management group then policies will sort things like monitoring agents etc. as we explain here in this video we created here: https://www.youtube.com/watch?v=R-5oeguxFpo about how many subscriptions you need etc. We have a section on scenarios (about 6 mins in) and we cover a DC exit scenario.

What additional things do you think are missing from whats available today? As from my perspective I think everything is there to enable this scenario, and we have seen many DC migrations using ALZ already today 👍

Really keen to get a list of things that you believe may be missing so we can start adding this to a feature on the backlog for triage in the new year.

Thanks

Jack

[jtracey93]

For completeness internal only tracking of this request AB#26366