Disclaimers: What I propose here, is not the 1 proposal to rule them all. Each project is unique and each client has their own needs. With that said, let’s see how many subscriptions we need.
I have seen quite many approaches, when it comes to Azure Landing Zones and Cloud Architecture. I have seen architects putting everything in a single subscription (named after their client) and telling apart Production from Test by naming their resource groups accordingly. I have also seen projects where each product! had its own subscription (when asked, the guy responsible for that responded that it would be easier to kill a product). Personally, I prefer a different approach, one that was somehow presented in an my previous blog post Azure-as-a-Restaurant.
My idea is based on Microsoft’s recommendation (as seen in the featured image), combined with what I have tried and seen to work well.
Seems pretty straight forward, right? It does and it is, but it also seems to describe a large-scale project, run by a big client with various departments, with different needs and with good organizational structures. This is not always the case when working with small, medium or even sometimes large clients, so I have come up with a model that at least in my experience, works decently for small & medium sized clients.
Why only one Tenant?
Because I never needed more than one and having more than one would only cause me problems. In 100% of the projects that I have been involved, all the budget came from the same pocket and most importantly, because that’s where Azure AD lives. I want to administrate Identity issues as easily as possible and it is much easier to restrain access from a Subscription (using RBAC and scopes) than to bring in users from other tenants.
The only scenario where I would end up having multiple tenants, is if were to migrate a solution.
Why only one Management Group?
Again this is more of a budget overview question and I never had the need of breaking down the budgets on that level.
Why 4 (or 3) subscriptions?
Actually, the most important question is why not only 1 subscription? Besides being able to administrate the budgets based on needs, this division is based on common sense and business logic. We need to be able to kill the whole environment without having to worry if we kill something in Production. Separation of concerns is of crucial importance in Cloud Architecture (as well as in Software Architecture). By creating one subscription for each environment we can:
- have a better overview of the costs.
- be sure that we don’t experiment in prod environment.
- have all groups working without disrupting each other.
Starting from the right wing, obviously, inside the Prod subscription, we create resource groups, where we have all our resources. This is the most important environment as this is where all the real work happens. This is what our clients use and what has to be best protected and managed. All data in this subscription is real, up-to-date and official data. All resources in this subscription, are configured so that they cover the client’s performance needs which means that expensive tiers will be used.
The RC (release candidate) subscription is in this scenario used by the client, to test a new Release Candidate. The engineers have made some changes, either in the applications, or in the infrastructure, and the client has been notified that the team now feels confident with this release candidate. The data inside this subscription have been copied from the Prod-subscription, anonymized and maybe even cropped (we might not need all 20 years of data outside of Production). Thus, the client can perform test in “real life conditions”, without disrupting production. All resources have the minimum required configuration so that we can mirror Production, without paying for performance we don’t need. Practically this means that we only select higher tiers, if we need a feature that’s unavailable in the lowest tiers.
The Test subscription, is where the developers perform integration tests. It is the same as RC but it can contain mistakes, it can be ruined at any time and it is clearly used for testing purposes. This subscription can be skipped if the client does not mind having and unstable RC-environment. I never recommend it, but if budget is a big issue then skipping this environment is an easy target. Data here come from the RC-environment and all resources have the cheapest tier possible, unless a specific feature demands a higher tier.
Last but not least, the (Dev)elopment subscription is kind of a developer’s playground. It is a place for experimentation and a place that can be deleted and re-created at any time. Then why do we even need it? one could wonder. After all, who has the luxury of wasting money on playground-subscriptions. We need it, simply, because most Azure resources cannot be emulated, like the Azure Functions and the Storage accounts can.
How do we make sure that the subscriptions remain identical?
Long story, and sometimes we don’t. As described above, going from right to left, the environments become more flexible and dynamic. How we re-generate X number of identical environments is a subject worth it’s own blog post, tldr: IaC.
