Back to Handbook

02 - Organization of resources

Second architecture decision that we should do on route to deployment in cloud is decision about structure of our cloud. We can be often limited by what we can do and often we are unable to change higher layers of organization, like management groups, but we still need to record how we will organize our resources and why we could not or didn´t want to use different approach.

Organization structure

In organization structure we have 4 elements that we can use.

Azure tenant that is usually bind to company for which we work for, but in some cases it can be shared between multiple companies. For instance if Ciklum would completely manage cloud for our customers.

Management groups are only element that can have hierarchy and have another management group as their parent. Root management group is enforced group that always exists.

Subscriptions plays important part in terms of billing and limitations, but they are also often used to separate resources logically.

Resource groups are the most used structure element, unfortunately it is not possible to create hierarchy of resource groups so they all have Subscription as their parent.

For small companies

For small companies it is often enough to have something like this, single subscription and environment separation is happening on resource group level. Unfortunately this leaves a space for cross-environment dependencies.

For larger companies

In larger companies ideal schema can look like this. Environment separation is happening on subscription layer, protecting is against cross-environment communication, etc.

Best solution

Unfortunately in enterprise solutions even split on subscription layer is not enough and we need to start looking for split in management group layer like you see on image above. This provide us way how to define different policies for testing and production environments, etc.