Editor’s note: This post continues our series about Getting Started with Azure. Previous posts in the series include:
In our previous post, we discussed the challenges that surface when you do not retrain or restructure existing employees before starting your Azure implementation journey. Now that you have your team on board and organized correctly, the next step is to create an effective structure in the Azure environment. There are many badly designed structures out there—be sure not to fall in that pit. Let’s walk through two prime examples:
- Less effective structure number one: consolidating everything under one subscription. There are a few problems with this approach. The first: there are subscription barriers and limits. You can’t function at this level, especially when you get to scaled organizations. Subscriptions need to scale out and this environment complicates things. The second problem: if it’s all under only one subscription, you can’t effectively test Prod, Dev or QA – it breaks down to a level where all other business units are dependent on these functions, but they can’t effectively test. Also, business units are right inside the same subscription, so your Corp IT person has too many rights over the business units’ functions. This leads to a lot of crossover where there shouldn’t be crossover, particularly in the security space.
How to do it right
- Less effective structure number two: dozens, if not hundreds, of subscriptions. While this may have been the intuitive way to do things when Azure first came out—and before Azure Resource Manager (ARM) was developed—this is not conducive whatsoever to efficient management.
A best-practice Azure structure is one organized by management groups (which are flexible and easy to implement). This layer on top of subscriptions provides organizational structure and security as well as policy applications. Your subscriptions act as buckets and can go six deep, in addition to the root, and you can have up to 10,000 of them.
So, a basic Azure structure might look something like this:
- First, the root management group.
- Next, a Corporate IT (“Corp IT”) management group. At this level, you will perform support functions, such as centralized Express Route, Active Directory and networking configurations. Note you should not include Corp IT applications in this group; centralized apps, if you have them, should have their own management group.
- Beneath the Corp IT group, create groups for software development: both “Dev” and “QA” management groups. In this way, you can create a testing environment that’s an exact copy of your product environment.
As you’re testing the Corp IT configuration, deploy a whole new one into each subscription to fully test the environment. Test one stream at a time to ensure it’s all fully working properly.
In the Azure management tools, you’ll see the business unit management groups and application teams displayed beneath them. These might be groups of teams; however, probably not every app will have its own management group because doing so might cause you to run out of your allotted 10,000 subscriptions. Also within the management tool interface, you can attach policy up at the management group level that cascades. So, if you add a new subscription, you can ensure it is up to par with the others.
You can fine-tune this a little bit if you don’t have too many employees—fewer than 500 or so. In that case, you can remove one of the management group layers and go straight from the Corp IT management group and the Business Unit management group down to a subscription level.
If you have questions about how to get started with planning for your organization, we welcome you to contact us