Deciding on the right number of Azure Subscriptions for your ISV solution
I work with a number of independent software vendors (ISVs) that are building solutions for or moving existing solutions to Azure. After they see our enterprise portal, I commonly get a question on if they need to separate their workload across multiple subscriptions. The answer to this question is complicated and depends a lot on how the solution is architected and the business needs of the organization.
Capacity Limits:
The first thing to consider is if you have to separate your workload for technical reasons. Each Azure subscription has default and maximum capacity limits. When reviewing your capacity needs ensure that you have enough headroom as getting a limit increased above the defaults requires opening a ticket with support and while they have a quick turnaround it is not immediate. That said if you anticipate needing more capacity then the maximum limit you will need to partition your workload across multiple subscriptions.
Separation of Concerns:
ISVs have a number of non-technical reasons they might want to separate workloads. In Azure we have two ways to separate workloads, by subscription and by resource group.
A few examples of ways to group assets that I commonly see are:
- Dev/Test vs. Production
- Different end customers
- Different departments/business units
- Different projects
- etc.
NOTE: these groups are not mutually exclusive, you might create a Dev/Test subscription, and then create a subscription for each end customer.
If, for example, the ISV create a subscription for Dev/Test and another for Production, they can ensure that developers don’t have access to production services or data. Or if they create separate subscriptions for each customer they can ensure that personnel in their organization cannot accidently access services or see data for customers beyond their desired scope.
Additionally, consumption can be summarized down to the subscription level in the Enterprise Portal. This allows an ISV that has placed each customer into a separate subscription to understand how much each customer is consuming. On the flip side, if the ISV placed all their production customers in the same subscription, the ISV would need to add logic to the application to meter how much each customer is using to gain that same level of detail.
You can also use the tagging feature of ARM to, well tag, resources. The nice thing about this technique is that it allows for multiple tags. So perhaps I tag all my database VMs with a SQL tag, and all my DEV assets with a DEV tag. I can now slice and dice the consumption reports to see all databases across all environments, or all my dev assets (DB, Web, etc.).
Along the same line as tags, I can use Role Based Access Control on my resources in Azure to have fine control of who can do what to which services.
Multi-Tenant Solutions:
Commonly I see customers looking to deploy a single instance of the application to service their entire customer base. These types of muti-tenant solutions if architected well can provide great scalability for many ISVs. Commonly we see these types of solutions in a single subscription, however depending on your scale requirements, see the above section on capacity limits, or your business requirements, see the above section on separation of concerns, you might want to carve your solution across subscriptions.
A great example of this is the customers that I work with that require solutions that require multi petabytes of storage. An Azure subscription can hold up to 100 storage accounts, and each storage account can hold up to 500 TB. Depending on your needs you might want to put each customer in a separate storage account. Additionally, you might want to take the extra step to create separate subscriptions for each customer. This would allow each customer to grow up to the 50 petabyte limit of a subscription. However, to take advantage of the virtually limitless capacity of Azure a bit of planning in application architecture is a must.
Azure Enterprise Enrollment Structure
If/when you decide what subscriptions you need to segregate your workload, we provide two different levels of hierarchy underneath your enterprise enrollment to allow you to group your subscriptions: Department and Account.
At a minimum for our Gov ISV customers we usually recommend to create two departments one for internal consumption and another for external consumption. Beyond that we recommend to create a separate department for each external customer and tag each with the customer information. This allows Microsoft to provide internal incentives to our sales teams to help drive customer usage of the ISV’s solution.
Conclusion:
As you can see there is no one size fits all solution to this problem. Each ISV will have a different set of needs and spending a few minutes thinking about this prior to deploying a bunch of assets will set your ISV up for long term success.
Two final tips:
1) Create a good naming convention for your subscriptions. Take a look at this article that talks about conventions for IaaS deployments, many of the same concepts can be helpful for subscription naming https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-infrastructure-services-implementation-guidelines/
2) Setup your Account, Subscription and Administrative roles appropriately to ensure that the right people have access to your subscription, more details in MSDN here: https://msdn.microsoft.com/en-us/library/azure/hh531793.aspx
Not Azure Gov Specific but a good read “Azure Enterprise Enrollment – Hierarchy” by Marc Kean
Light
Dark
0 comments