Azure Landing Zones - Handling Dev/Test/Prod for Application Workloads
HTML-код
- Опубликовано: 21 июл 2024
- Ever wondered how to handle dev/test/prod environments in Azure Landing Zones?
Then this is the video for you! Join Jack Tracey, Matt White & Kevin Rowlandson from the Microsoft Customer Architecture & Engineering team (the team that are responsible for Azure Landing Zones) as they talk through how to handle dev/test/prod application workloads in the Azure Landing Zone architecture.
Useful Links:
- Azure Landing Zones - aka.ms/ALZ
- Azure Landing Zones - Canary Guidance - aka.ms/ALZ/Canary
- Azure Landing Zones -FAQ - Application Dev/Test/Prod - aka.ms/ALZ/DTP
Chapters:
0:00 Introduction
0:15 Azure Landing Zone Platform Testing "Canary"
0:48 Application Dev/Test/Prod Handling Intro & Decision Points
2:48 Sandbox Recommendations & Usage
5:27 Making It Real
7:00 Handling Non-Compliance for Applications
9:40 Key Takeaways
12:14 Closing & Stay Tuned 
Наука
Good video, the linked FAQ are really handy!
Loving the content chaps!
Good videos, I like it! Would love to see a discussion about Platform subscriptions.
Dream team at work!
Great discussion, really insightful, helpful and useful. Having tried to the prod/test/dev MGs under a Corp/Online hierarchy, I would love to hear more about why "it just doesn't scale" @10:25 some tales from the field would be awesome to hear, policy can be a very tricky discussion to have with customers for sure! cheers and thanks for the videos.
Thanks Matt. Stay tuned we have another video planned for just this.
@@MicrosoftCAE awesome, that would be amazing, looking forward to it 😎
Would be really great with some practical examples of the scaling issues. Are about to decide on MG structure and tend to go for MGs on prod and dev.
I know it is an old video, but Kevin and Matt don't seem to be on the same page. At 5:30 (ruclips.net/video/8ECcvTxkrJA/видео.html), Kevin recommends App A to have all three stages under Corp. But 10:15 (ruclips.net/video/8ECcvTxkrJA/видео.html) Matt recommends not exactly that. What am I missing here?
I believe the difference is the additional management group level that is crossed out in section discussed by Matt. The dev, test, and prod subscriptions can be under Corp but they can't be under dev, test, and prod management groups under the Corp management group. This discussion is about management groups, not subscriptions. Kevin's did not have the dev, test, and prod management groups.
Great video, but as someone getting started with the "proper" way to structure my Azure layout, one thing I'd like to see clarified is what exactly is meant by "corp" vs. "online"? What would go in a corp management group vs online? Is Corp meant just for internal applications that should never be customer facing? And therefore is "online" meant to be your actual deployed products that are released into the world for customers to use? I haven't found in any of the documentation what exactly the differences are besides a very complex all-encompassing enterprise-level diagram of how to 100% layout an organization from scratch. Thanks!
Hey, thanks!
The TLDR on Corp & Online are as follows:
Corp == Corporate connected applications, that require hybrid connectivity back to on-premises or other VNet spokes via traditional Layer 3 Routing (think VNet Peering to a Hub etc.)
Online == Workloads that don't need traditional Layer 3 routing to on-premise or other VNet spokes. And if they do require connectivity to them they would either interact via each applications API exposure "publicly" (over the MSFT backbone if all in Azure) or use service like Private Link to connect between each other without the need for VNet Peering.
We are actually creating a document in CAF for just this topic in terms of how Corp & Online Networking should be done in more detail and some common scenarios. Stay tuned.
Great discussion. If an Azure Kubernetes Service (AKS) cluster is operational within a subscription that necessitates on-premises connectivity via ExpressRoute, while simultaneously utilizing a public Load Balancer (LB) to make an application accessible over the internet, the question arises as to whether this subscription will fall under the Corporate (Corp) management group or the Online management group?
Thanks @bangash830. If it requires private corp connectivity it would be corp. We recently documented this a bit more here: learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity#design-area-overview
Corp only applies policies to prevent public IPs from being attached to NICs, which means app GWs etc all can still exist in corp, if requried
@@MicrosoftCAE Thank you for your reply, and yes the recent document regarding network topology and connectivity is much clear.
Would be nice to see something on how you govern the change of policy. If you have multiple subs for multiple envs under a single branch of the hierarchy a single change to policy with unintended consequences has a larger blast radius. I wonder if having a management group for policy changes would be beneficial where it mirrors "online" or "corp" but you can move a subscription like dev into it, to test that the policy is the expected change for a trial period before moving it back and applying the policy for real.
Azure Policy can be applied at the Management Group, Subscription, Resource Group or individual resource level. If you apply a policy at a higher level, it gets inherited down. If there is a more restrictive policy it will always win, regardless of the level it has been applied. Meaning, it does not matter if the policy is applied on management group or individual resource level, the deny will win for the resources the policy is assigned to. If policies are not conflicting, they will be complementary.
In your example if I felt I was going to apply a more restrictive policy, I would consider applying it at a lower level for testing. Also, we should strive to have production and non-production versions of our applications, so ideally, we would be able to apply the more restrictive policy to the non-production side first, test and validate, then roll into production once we felt comfortable.
As mentioned in the video you can deploy Policy in Audit mode, so following the above feedback with this, you should be able to accomplish what you are asking:
learn.microsoft.com/en-us/azure/governance/policy/concepts/effects
@@tharagz08 audit mode with some validation process makes most sense. Your example works but I was specific about testing policy applied at the root, or more specifically corporation subroot which are intended to be inherited by all, like a change nist or something.
@@evolagenda I think audit mode would make the most sense in that scenario then.
Great video for Ops Nazis - doesn't address the central concept of how to handle "application environments" despite the enthusiastic belief of the presenters.