Understanding the operational model for organizing AzOps Repos at Enterprise-scale

[matthewponzio]

Hi team, I'm senior cloud and DevOps consultant for a Va-based consulting company. We are currently engaged in evaluating the concept and use of Azure Landing Zones and AzOps for our client base. We are impressed with both initiatives and appreciate all your efforts into making cloud adoption easier for everyone!

So my question, as the title indicates, is around gaining an understanding of how you all (and potentially the Landing Zones teams) are thinking about how clients should think about organizing their AzOps repositories at Enterprise-scale. Specifically, we are curious about this in the context of 'scope'.

I think the easiest way to ask the question is by way of example:
Say I'm the central Cloud Engineering team for my organization and I've used the Landing Zone Accelerator to deploy an Enterpise-scale Azure foundation. This of course yields my AzOps GitHub repository. (We've done all of this and works very well!).

Continuing as the central Cloud Engineering team, I begin to stamp out the Landing Zone Management Groups and Subscriptions for my many App teams. Additionally, we would of course implement some foundational infrastructure, such as networking, in those Landing Zone Subscriptions and also apply RBAC and Policies as needed to provide the necessary "guard rails". At this stage, we would "turn over" the Subscriptions to the App teams, allowing them to self-service create their own Resource Groups, Resources, etc as needed to deploy and run their Apps.

Hopefully I'm stating that reasonably correctly--still learning the Azure concepts, coming from AWS.

So considering that, probably very common, scenario...my question is how would you then organize the AzOps repos to manage the infrastructure? Well, maybe that's not exactly the question. The answer to that question seems relatively straight forward–You would have the main "Foundation" repo that was created by the Enterprise-scale Landing Zone deployment and is controlled by the central Cloud Eng team, and then each App team would stand up it's own AzOps Repo to deploy and maintain it's RG's and Resources within the Subscription(s) they were granted.

The question is about this main "Foundation" Repo and its 'scope'. It controls everything from the "top-level" Management Group down through the Landing Zone Subscriptions and some of the "foundational resources" therein. But at that point, it's the App team Repos that should control all other RG's and Resources in each LZ Subscription. However, at present, the "Pull" pipeline in the main "Foundational" Repo will continue to discover ALL the Resources, including everything in the LZ Subs that are created by the App teams. Of course, we know you can set AzOps.Core.SkipChildResource=false...but then we wouldn't have the templates for the child resources in the Subscriptions that we do "control", such those under Connectivity, Identity, and Management.

So you might be reading this and saying..."Yeah...so? Your Foundation Repo SHOULD be a master copy of EVERYTHING under the 'top-level' Management Group". And I couldn't disagree with that. I guess I'm want to know/discuss if there SHOULD at all be any delineation between the main "Foundation" repo and the Repos that deploy to the LZ Subs? Should the main "Foundation" repo STOP discovery at the "delegation point"? And if so, how?

I do see that you have just merged Pull #609 but I'm not certain that feature is quite meant to say - Hey, I would like to STOP discovering resources "BELOW" a certain point.

Hopefully my verbosity has captured the essence of what I'm trying to understand! :)

[daltondhcp]

Thank you for reaching out and for the feedback!
Our recommendation and what we see most customers do, is to use the 'Foundation' repo to discover and manage the platform resources such as Management Group Hierarchy, Policies, Roles and depending on operating model/team structure, also the central networking resources etc.
The application owners are responsible for deploying resources in their landing zones with their preferred tooling.

If you only want to discover resources/resource groups from your 'platform' subscriptions, you can control this by configuring the Core.SubscriptionsToIncludeResourceGroups, replacing * with an array of the subscriptionids you want to include.

We recently added some of these scenarios to our FAQ https://github.com/azure/azops/wiki/frequently-asked-questions#discovery-scenarios-and-settings.

Hope this helps!

[matthewponzio]

@daltondhcp Thanks so much for speedy reply; greatly appreciated!! That's great information, especially what y'all have added to the FAQ. That must have been VERY recently added, cause I could swear I looked there yesterday morning! :) Anyway, great stuff; we will try those scenarios out as we work with this more. Cheers!