Hello, and welcome to this Azure Governance for ISVs recording
summarizing basic governance topics from an ISV point of view.
I’m Mike Bazarewsky, and I’m going to be your presenter for this session.
Coming in to this session, I’m assuming you’re an ISV that has some basic knowledge of
organizing resources across Azure - subscriptions, resource groups, and so on.
I’m also assuming you have basic knowledge around policies, initiatives, and blueprints
for compliance purposes. If you don’t, you’ll want to review those sessions first.
Because this is a summary session, it’s going to be shorter in duration than the first two.
You can find all of the reference links from this session
at https://aka.ms/GovernanceReference; that will include all of the documentation and
learning links that I present in this session.
So, time to get into it. In previous sessions, I’ve talked about several features that are related to
governance in Azure. However, I haven’t talked fully about when you would use
what feature yet, although I’ve talked about it some as I presented information.
For this presentation, I’m going to finish the governance topic by going back to discussions
about when you might choose to use different features.
I’ll start with the SaaS deployment model. When you’re trying to decide between
managing multiple subscriptions and multiple resource groups in a SaaS deployment model,
it makes sense to compare and contrast the two.
Subscriptions and resource groups can both be programmatically managed,
but the subscription management is a much newer capability
and is more complicated than resource group management,
although we recently released ARM template support for deploying subscriptions.
Subscriptions directly relate to billing and payment, while resource groups do not.
You can report on billing against resource groups, and tags for that matter,
but subscriptions are the fundamental billing unit.
Data in subscriptions stays around for a while after being cancelled, and the subscriptions
themselves are generally visible, even after being cancelled,
forever in the Portal and the APIs. Compare that to resource groups, which are deleted
immediately when the resource group deletion occurs, assuming the data has not been
protected from deletion. If there is protection in place, such as a lock,
then the resource group deletion will fail.
There’s information about the cancellation process and impact of the cancellation
process in the documentation.
There’s an unlimited number of subscriptions per Azure AD tenant, but there is a limit of
900 resource groups per subscription. This means if you have a SaaS offering
and decide one resource group per customer is your design,
once you reach enough customers, you’ll need to roll over to another subscription.
Although sometimes ISVs believe “well if I have to do that anyway, I should just make
one subscription per customer,” the billing implications and long-term management
implications such as never truly deleting a subscription make that a poor choice in the
long term. Instead, it makes sense to use resource groups and track the subscription ID
and resource group for each customer; this gives you a lot more flexibility and a lot less
to ultimately manage; you’ll need to do a resource group for each customer anyway,
but limiting the number of subscriptions reduces the number
of unique items you’re managing.
Next, within resource groups there is generally a limit of 800 resources per resource provider
(as in, type of resource, such as a Virtual Machine). This does not apply to all
resource providers, but it does apply to most of them. This means that putting many customers
into a single resource group, while possible, also has a limit you’d have to manage,
and it doesn’t really buy you that much ultimately.
The documentation has a very comprehensive service limits document that
covers this information.
Policies and RBAC can be enforced at either level, so that shouldn’t be part
of your decision process here.
All of that information is generally important for SaaS offerings.
For Managed App or Virtual Machine offers, the deployments are in the customer’s
environment, not yours, so they control the choice of subscription and resource group.
However, even in those cases, understanding the concepts and limits will be helpful when
supporting your customer.
That covers subscriptions and resource groups. But what about tags?
Well, that is fully covered in the first session, so I don’t need to repeat that here.
I will spend a little more time on Azure Policy, however.
For an ISV, Policy is likely to come up in two contexts.
The first is at the customer side. As mentioned in the earlier session,
you should be aware of how Policy can change or block deployments
in the customer’s environment. For example, if you have a virtual machine offer,
and you only support specific machine sizes, or SKUs,
such as dedicated GPU options, and the customer does not allow
deployment of those SKUs, their deployment will fail.
You should document any such restrictions not just in your Marketplace listing,
but in your support documentation.
Similarly, for a managed application or solution template offering,
resources are being deployed in the customer’s environment, so again their
policy could prevent successful deployment. You should document what
your expectations are for a successful deployment.
For a SaaS deployment, where you’re offering services to customers,
deployed in your subscription, you can use Policy and Initiatives
to control your SaaS deployments and your developer deployments,
to ensure regional compliance and cost controls. It’s not unusual for an ISV
to have deployments managed by developers,
either directly through delegation or indirectly through DevOps deployment pipelines.
Ensuring developers are deploying those resources where you want
and the way you want falls into the “trust but verify” category.
You’re trusting the developers, but you’re going to use that “guardrails for Azure” concept
to ensure they don’t accidentally deploy resources incorrectly.
So that’s the ISV view of Policies, and by extension, Initiatives.
That session also described Azure Blueprints, however.
How do they fit in to the ISV picture?
One way is to take advantage of the ability to import and export blueprints;
for an ISV, this means that you can treat Blueprints as another form of
Infrastructure as Code, managing them in your source code control system.
You can also share them with your customers as part of example deployment scenarios.
The documentation covers the lifecycle of Blueprints…
…as well as how to import and export them.
One thing to remember is that if you’re going to use Azure Blueprints to deploy your
SaaS environment as a collection of templates, permissions, etc.,
you’ll want to include your resource group vs. subscription decision as part of that.
This is because although Blueprints can deploy multiple resource groups,
they are deployed - or assigned - at the subscription level.
If the names of target resource groups are hard-coded in your blueprint,
rather than being parameterized, you won’t be able to deploy the template
multiple times in the same subscription (for example, for parallel environments).
By parameterizing the resource group name, you can deploy parallel instances
of the blueprint in a single subscription.
The alternative is to have unique subscriptions for each environment;
some customers choose to do this, but it’s going to be a substantial amount
of extra overhead compared to using separate resource groups.
Furthermore, for other marketplace offering types, parameterizing the resource group name
lets you send customers reference deployment blueprints without making assumptions
about resource group names in their environments.
And with that, I’ve reached the end of this governance session about all-up governance,
from an ISV point of view. This is the last of three sessions,
after one on organizing resources in Azure, and on one compliance using policies, initiatives,
and blueprints. I hope you found this helpful.
Remember, you can find the reference links at https://aka.ms/GovernanceReference.
Thank you for watching, and I hope this helps you invent with purpose on Microsoft Azure!