In the world of Azure within enterprise environments, governance of Azure components is one of the main topics. Everyone who has worked with Azure within a big organization knows maintaining the structure of these resources can be challenging. It is definitely easier to create and delete new components in a public cloud environment compared with a traditional datacenter. Therefore, these public cloud environments tend to become chaotic and unstructured. In this post, I’ll provide some guidelines Sentia uses to maintain a structured environment in Azure that is easier to manage while maintaining the flexibility a DevOps-minded organization desires.
Sentia developed a subscription model that helps you maintain easy control over different workloads inside an enterprise Azure environment. This model has the following advantages:
- An easy overview in the Azure portal of what does and does not belong to an application, making added and removing workloads easier.
- The deployment of one team can never impact another team.
- Permissions such as “reader” or “contributor” can be easily added at subscription level for the different teams within one organization.
- Azure limitations such as API calls or VM cores are often on a subscription basis and therefore the chance of hitting these limits is reduced.
- The delivered service proposition provided by Sentia to different teams can be easily applied and changed over time. For example a managed workload changing in a model where the customer manages everything themselves.
- Tags are great but require a lot of manual labor. The Sentia subscription model uses three identifiers in a naming convention which would otherwise have to be defined in tags.
What is an Azure subscription?
If you look up the definition of an Azure subscription you will find “An Azure subscription is a logical container used to provision resources in Azure”. An Azure subscription is an administrative container in which resources can be grouped that belong together but also on which the Azure bill will be charged. The subscriptions are connected to a billing account which will be used by Microsoft to generate the invoice. The invoice itself uses the subscriptions for segregation.
Subscriptions do not cost any money, but some resources can only work together when they are deployed in the same subscription. For example Virtual Networks are bound to a subscription and cannot span multiple subscriptions. There is no limit to the number of subscriptions that can created under a single tenant.
The Sentia subscription model
The Microsoft Cloud Adoption Framework (CAF) provides some guidelines on which model to use in which case. However, for many organizations it can be difficult to select the proper one. At Sentia, we use the following subscription model. This is the way Sentia uses subscriptions and why this method is considered a logical approach.
When an organization starts with Azure either via Office 365 or by consuming Azure resources, a tenant is setup. This tenant can best be seen as the company identifier in Azure. In big organizations, development teams are often split up based on the application clusters in the landscape. These teams regulary operate autonomously and have little to no dependencies with each other.
In this scenario there is mostly a difference in technical cloud maturity. Some teams wil be independent and wish to deploy all resources including the actual application fully themselves. Meanwhile, others require more help. In order to facilitate these different maturity levels, Sentia offers a range of different service propositions aiming to provide the value an application team (no matter the maturity) requires.
With this approach however, there is a need to ensure that one team’s deployment cannot influence the work of another team, especially when new features are released using CI/CD. CI/CD tools always work with a certain deployment scope which needs to be established at the subscription level. Thus, requiring high level segmentation on the subscription layer.
In the Sentia subscription model every workload (a logical group of applications facilitating a business process) and every environment (Development, Test, Acceptance and Production) are isolated in their own subscription. This concept is visualised in the diagram below.
Every application or workload is contained in its own subscription. This is also segmented per environment to clearly separate the different environments in the development lifecycle. Inside the subscriptions, the resource groups can be used to segment the different application functions such as the webserver, application server, database server, and backup. The Sentia subscription model ensures a well structured, flexible, secure, and cost optimised Azure landscape.
Structure your subscription together?
Please contact us to help you with setting up the subscription structure in your own Azure tenant.