Hello, and welcome to this Azure Governance for ISVs session.
My name is 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 Azure Active Directory - Azure AD - and how Azure does Role-Based Access Control
or RBAC for short. If you don’t have that knowledge right now, a little of what I'm
going to talk about won’t necessarily make sense to you yet, but that’s okay;
you’ll still be able to understand most of what I’m presenting,
and you can learn about Azure AD at your leisure.
That said, this is the first of a number of ISV-oriented Azure Governance sessions.
This one is going to cover options for organizing resources in an Azure deployment,
with a look at how those concepts apply to an ISV use case.
Future sessions in this series will be around policies, initiatives, and blueprints, and an ISV summary of the topics.
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, let’s start. The first term I’m going to define is “Subscription.” Subscriptions are the basic billing unit for Azure deployments.
Every Azure resource will be deployed in the context of a subscription;
this could be your subscription, or a customer’s subscription,
depending on the deployment model selected for your application.
SaaS offers will generally be in your subscription, while Virtual Machines
Solution Template, and Managed App offers will be in the customer's subscription.
Let's examine subscriptions in the Azure Portal. On the Azure Home page,
there's a subscriptions link available. I can select that, and that will give me
the list of subscriptions that I have access to, that I've chosen to make visible in this view.
I'm going to select one of those, and that's going to give me an overview of the subscription
This is going to include things like the billing period and if it's an active subscription
as well as the subscription ID, or GUID.
Underneath the items on the left-hand side, I have "Cost analysis" and "Budgets",
I have "Invoices". I have "Resource groups" and "Resources."
And we're going to talk more about "Resource groups" in a little bit.
I also have "Usage + Quotas." We're going to talk about "quotas" in a little bit.
This gives me my "big picture" view of what's happening in my Azure subscription
with my resources.
There’s more about the concept of subscriptions at our self-paced microlearning site, Microsoft Learn.
As mentioned earlier, one thing managed at the subscription level are quotas.
Quotas are limits to the number of a particular type of resource,
such as the number of storage accounts allowed;
they can be across a subscription, or can be per-region, depending on the type of resource.
Quotas come in two forms. Soft limits are limits which can be increased upon request,
while hard limits are limits which cannot be increased.
Quotas can be programmatically queried, as well as seen in the portal.
Microsoft Docs includes a limits page with a section for each Azure offering,
documenting the limits for that offering.
A single organization can have many subscriptions associated with its
Azure Active Directory tenant, depending on what the organization's needs are.
When it comes to deciding when you should create a new subscription,
versus using an existing subscription, we have published an enterprise-focused
decision guide around making that decision in the Cloud Adoption Framework
documentation. That documentation, however, is specifically enterprise-focused,
not ISV-focused, so your decision process as an ISV is going to potentially be different.
Another governance session talks more about how to decide in the ISV context,
so I'm not going to go into great detail on that right now.
As you might guess from what I've said to this point, it's pretty common for an organization
to have multiple subscriptions. "Management Groups" are Azure's way to manage
multiple subscriptions in an organization. A management group is a hierarchical collection
of subscriptions that allows delegation, cost analysis, and policy assignment.
We're going to explain more about policy assignment in a later session.
The hierarchy is a tree structure, starting with a Root Management Group.
All subscriptions are leaf nodes in the tree, underneath whatever management group
they are a part of.
Each of these levels can have security and compliance configuration assigned,
so if you're managing multiple subscriptions, it's a way to enforce consistency across them.
A later governance session will cover this in more detail.
Here are two references where you can find out more about Management Groups.
The first is our Microsoft Learn self-paced training module about them…
And the second is our documentation on the Management Groups feature…
By the way, I should mention that in the case of subscriptions that are part of an
Enterprise Agreement, there is an organization structure around subscriptions that is
exposed in the Enterprise Portal, a web site independent of the Azure Portal.
I'm not going to deep dive into that here both for time reasons
and because many ISVs don't have to be concerned with it;
I mention it only for the sake of completeness.
If you are responsible for multiple subscriptions in an Enterprise Agreement,
you can refer to our documentation for more information on the Enterprise Portal.
Moving on, within a subscription, all resources that are deployed in Azure
are deployed into "resource groups."
A resource group is a single-layer, one-to-many mapping of resources
that allows delegation and lifecycle management.
An entire resource group can be deployed at once,
and can be deleted at once.
Permissions to resources in the resource group can be delegated at the group level;
permissions will also be inherited from the management group and the subscription.
When you create a resource group, you specify a region.
This region is where the administrative data for the resource group is stored,
and it is where change requests to the resource group will be targeted.
It’s also used by the Portal as the default region for resources created in the resource group.
However, resources in the group can be created in any region you have access to;
in other words, a resource group's resources can be in multiple regions.
In the unlikely event of a regional outage for the resource group's region,
resources will continue to run in other regions,
but you will not be able to make changes to the resource group.
When you create resources, you must specify the resource group that will host the resource.
For example, I'll begin creating a storage account, and one of the first questions I'm asked
after what subscription should host the storage account - is the resource group.
If I choose different resource groups, the Location field for the storage account
changes to match the selected resource group.
I'm going to choose a resource group I created for this demo,
and I'm going to finish creating the storage account, leaving most of the options
at their defaults, because I'm not concerned with those details for this demo.
By the way, the reason I chose a storage account is because
they create very quickly on Azure.
And there is my newly created storage account.
When talking about resource groups, an important thing for me to mention
is that when you deploy a resource group using an ARM template,
your deployment can either be an incremental deployment or a complete deployment.
Incremental deployments only change existing resources
and create new ones in the target resource group.
A complete deployment, however, will delete resources not specified in the template.
The default is an incremental deployment.
Another important thing for me to mention
is that deciding on a resource group is not necessarily a permanent decision;
most resource types can be moved between resource groups or subscriptions.
Microsoft Docs gives the rules and restrictions around this capability.
In fact, Azure has the ability to even move resources between regions,
in some specific cases. This gives a customer a lot of flexibility
in redesigning a deployment without having to tear it down and redeploy it from scratch.
When you no longer need a resource group's resources, you can delete the group.
Azure will delete the resources in the group automatically.
For example, I will now delete the resource group that has my new storage account;
Azure will then delete the new storage account because it is in the resource group.
This is a permanent operation, so I receive a confirmation prompt
warning me about the permanence of the deletion.
Once the deletion is complete, I can refresh my view of the storage account,
and the storage account will show "Not found".
My deletion is complete, refresh the view, and there is my "Not found" on the storage account.
From an ISV viewpoint, managed app deployments will typically deploy
to two resource groups. The first resource group will be one where
your customer has full control,
and you as the publisher have no access.
This resource group will host the managed application resource -
the representation of the application in their environment.
The second resource group will be one where the customer has limited, read-only access,
and you as the publisher have defined access, based on your application definition.
This second resource group actually has the deployed resources
for the application's implementation. The control is done automatically
through delegation. The delegation is done through an Azure AD principal
that represents your publisher's identity in the customer's Azure AD tenant.
There's more about this in our documentation;
FastTrack Engineer Arsen Vladimirskiy also has produced a series of public videos
around this topic that are helpful in seeing this at work and understanding it.
If you're doing a Virtual Machine Marketplace offering, the VM is deployed
in the customer's environment in whatever resource group they choose.
You won't have Azure management access to that resource group or to the VM,
because it's all in the customer's subscription
with no delegated access for the publisher.
If you're offering a SaaS Marketplace offering,
the resources are deployed in your Azure environment,
and you can decide how you'd like to structure your resource groups and your subscriptions.
You'll typically decide based on your security needs and your deployment model,
because remember that resource groups allow for both delegation and lifecycle management.
The customer will not have Azure management access to the resources,
although of course you may grant them application access.
Microsoft Learn has more information on resource groups in a self-paced learning format.
Subscriptions, management groups, and resource groups are all
fundamental Azure deployment functionality that are key to use of the platform.
The next topic is different.
"Tags" exist solely for the purpose of helping an administrator organize resources in
their environment. They are a way to add arbitrary name/value pairs to your
resources, resource groups, and subscriptions. For example,
if you are publishing a managed app to the Marketplace,
you can have tags in your templates that indicate you are the source of the resources,
and perhaps other information like support info.
If you are publishing a SaaS app to the Marketplace,
you can mark per-customer resources with information about the related customer,
allowing you to use resource groups and subscriptions
in different combinations as appropriate.
Let's take a look at some example tags.
On the "TagDemo" resource group, I've currently assigned four tags.
"Environment", "Cost Center", "Owner", and "Company".
And those are listed for me on the "Overview" blade.
If I move to the "Tags" blade, I can actually make changes to those tag values.
So I can add new names and values to go with those names,
Or I can edit and delete existing values.
Let's go ahead and add a new value here. I'm going to add as an example of how this is
completely arbitrary, an entry for "Favorite Star Trek Series"
and underneath "Value", I'm going to put in "Deep Space Nine."
Again, completely arbitrary information that I'm choosing to add to the tag information here.
Because Azure doesn't care what I put in here, it's for my use,
so I'll apply that, and now "Favorite Star Trek Series" is listed here.
Tags will show up on the billing information as well as
exported from the Billing API, so this can help you
narrow down billing information based on arbitrary information
in your environment as well as can act as arbitrary documentation
based on what your needs are.
There’s documentation about the general idea of tags in our documentation.
By the way, now that I've presented tags, resource groups, and subscriptions,
all of which need names, I should point out that we have naming and use recommendations
for all of those and more - really anything in Azure - as part of the
Cloud Adoption Framework documentation.
And with that, I’ve reached the end of this governance session about the concepts
of organizing resources in Azure, from an ISV point of view.
Other sessions include one on policies, initiatives, and blueprints,
and all-up ISV summary session on governance topics.
I hope you found this helpful.
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!