Azure Stack Validation Environment – Part 4: Services and Resource Manager
Azure Stack
Building an end-to-end validation environment
Part 4: Services and Resource Manager
By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.
Azure Customer Advisory Team (AzureCAT)
This article is Part 4 in the Azure Stack Validation Environment series:
- Part 1: Overview
- Part 2: Quotas, Plans, and Offers
- Part 3: Subscriptions
- Part 4: Services and Resource Manager (this article)
- Part 5: Putting it all together
E-Book - This series of blog posts is available as an e-book on Azure.com:
Services
The key value of Azure Stack is the ability to run Azure services in your datacenter. This ability allows you to transform your on-premises datacenter resources and services into cloud services and cloud-native applications within your organization.
Understanding solutions and services
Azure is comprised of a series of discrete infrastructure and platform services deployed across global datacenters. Think of these as the discrete capabilities that, by themselves, provide a type of service such as storage, websites, or virtual machines. You can combine one or more of these services to support various solutions, which are tangible outcomes used to enable a range of aspects of a business. Using an infrastructure example, services such as Virtual Machines, Virtual Network, and Blob/Table Storage would enable traditional server-based application services like SQL Server or SharePoint Server. Alternatively, these services allow customers to run cloud-first applications as solutions using on-premises deployments of platform services Azure App Service (Web Apps) and Docker-integrated containers. That is a key difference between what most customers can achieve today with traditional server virtualization since Azure platform services allow your developers to describe, deploy, and control their applications and solutions using standard Azure APIs and using familiar Azure services that expand beyond traditional virtual machine-based solutions. 
Figure 21: Example Azure services differences on Azure Stack differences
Azure Stack provides an Azure-consistent experience for developers and consumers of these services in your environments that go beyond the user interface. Having a consistent experience means that the Resource Manager API can be used to compose services to build your solutions and host your organization’s applications on Azure stack in a consistent way, using a consistent set of tools by your developers. However, Azure services on Azure Stack can sometimes contain some differences due to API version, scale, and dependencies, as illustrated in Figure 21.
- API version: The version of the API on Azure Stack may be different than the current version in Azure, specifically when using traditional infrastructure services as outlined above.
- Scale : In many cases, the scale of an Azure service is hardware dependent. In Azure datacenters, the smallest scale unit spans hundreds of servers while the smallest scale unit in Azure Stack for on-premises infrastructures is much smaller (under ten servers). This scale difference is critical to the planning process for any solution you wish to provide to your users.
- Dependencies : To enable familiar solutions and capabilities within Azure Stack, each service may have a dependency on another resource provider, a specified agent version, or dependent hardware capabilities to support an expected set of functionalities.
On an Azure Stack instance you can list the installed resource providers along with their API versions using the following PowerShell cmdlet:
Get-AzureRmResourceProvider | `
Select ProviderNamespace -Expand ResourceTypes | `
Select * -Expand ApiVersions | `
Select ProviderNamespace, ResourceTypeName, @{Name="ApiVersion"; Expression={$_}}
Read more about the considerations for Azure services on Azure Stack here:
- Key considerations: Using services or building apps for Azure Stack
- Considerations for Virtual Machines in Azure Stack
- Azure Stack Storage: Differences and considerations
- Considerations for Azure Stack networking
Envisioning your solution in Azure Stack
When building your organization’s solutions on Azure Stack, it’s important not to follow the same models you may have used with your existing virtualization platform. In these cases, most applications leverage only IaaS virtual machines for their solutions. In addition to traditional infrastructure services, Azure Stack brings the power of Azure platform-based services to your organization’s datacenter. You should review both existing and new solutions with this in mind, and consider the possibilities when running these systems on Azure services. For example, if you have a traditional tiered web application running within a virtualized infrastructure using Windows Server web server (IIS) as the front end and a database running MySQL on the back end, you could review these solutions and determine if the features being used by the web server front end are compatible with the version of Azure App Services that exists in Azure Stack. The same could be said for the data in MySQL, which you could evaluate to see if the versions are compatible and will support porting this solution from a single virtual machine to a shared instance of MySQL Server. In doing this analysis, you may find that many of your existing applications or solutions, which currently require isolated virtual machines, could be transitioned to using native Azure cloud-based services. Not only would your organization find potential savings in the operating system and associated third-party management licenses, but you would also likely see operational benefits, given the differences between management, configuration, and maintenance of individual virtual machines and Azure Stack.
NOTE: To offer PaaS services in your Azure Stack environment, you will need to add the following resources providers:
|
Important points
The following core resource providers are visible in the portal in the Resource Providers blade. You will break core functionality in Azure Stack if you remove any of these resource providers.
| Resource Provider | NameSpace |
| Compute | Microsoft.Compute.Admin |
| Health | Microsoft.InfrastructureInsights.Admin |
| Network | Microsoft.Network.Admin |
| Storage | Microsoft.Storage.Admin |
Additional resource providers that are installed by default are visible under the Resource Explorer > Resource Providers blade. These are the base resource providers that enable the functionality you see in the portal after installation. Removing of any of these also breaks core functionality in Azure Stack.
| Resource Provider | NameSpace |
| Authorization | Microsoft.Authorization |
| BackupAdmin | Microsoft.Backup.Admin |
| Commerce | Microsoft.Commerce |
| CommerceProviders | Microsoft.Commerce.Providers |
| Fabric | Microsoft.Fabric |
| FabricAdmin | Microsoft.Fabric.Admin |
| Gallery | Microsoft.Gallery |
| GalleryAdmin | Microsoft.Gallery.Admin |
| GalleryProviders | Microsoft.Gallery.Providers |
| InfrastructureInsightsProviders | Microsoft.Infrastructure.Insights.Providers |
| Insights | Microsoft.Insights |
| InsightsProviders | Microsoft.Insights.Providers |
| KeyVault | Microsoft.KeyVault |
| KeyVaultAdmin | Microsoft.KeyVault.Admin |
| Resources | Microsoft.Resources |
| ResourcesAdmin | Microsoft.Resources.Admin |
| Subscriptions | Microsoft.Subscriptions |
| SubscriptionsAdmin | Microsoft.Subscriptions.Admin |
| SubscriptionsProviders | Microsoft.Subscriptions.Providers |
| UpdateAdmin | Microsoft.Update.Admin |
Resource Manager - Tags, polices, and locks
Resource Manager provides the ability to apply additional management constructs to your resources to assist with billing, consistency, and prevent administrative error. Like Azure, Resource Manager resource tags, policy, and locks can be used in Azure Stack to mitigate these types of issues when planning and managing a large Azure Stack environment. As an administrator of an instance of Azure in your datacenter, you’ll need to develop a strategy to implement these and other constructs in your subscriptions to provide a well-managed Azure Stack experience for your users.
Tags
Resource Manager provides the ability to use resource tags to logically categorize and assign meaningful metadata to each resource in your subscription. Resource tags can be assigned and viewed in the portal, are accessible programmatically, and are visible in your Azure bill. Since resource tags are metadata on a given resource, you can assign them to resources outside of a single deployment, allowing for ease of identification when reviewing your bill.
When creating tags, you must use a name/value pair. Some common examples of situations where you may want to use tags include:
- Grouping components of an application.
- Grouping of resources related to applications, cost centers, or user units for billing purposes.
- Organization of components for management purposes.
Careful planning is required when applying tags, as each resource or resource group can have a maximum of 15 tags. The tag name is limited to 512 characters, and the tag value is limited to 256 characters. Having consistency in your naming convention for resource tags is important for being able to reconcile these in your Azure billing statement.
You can apply tags through the portal, PowerShell or within Resource Manager JSON templates at deployment time. Applying tags ensures that any new resources that should be part of a logical grouping are automatically assigned the proper resource tags. Figure 22 shows the Tags blade in the Azure Stack portal.
Figure 22: Tags in the Azure Stack portal
You can also add tags using PowerShell scripts, which is especially valuable if you have a lot of existing resources that require updating with a new tag. The command below will allow you to obtain a list of all tags in a subscription and the number of resources to which each tag is applied:
Get-AzureRmTag
To obtain a list of all tags applied to a resource, you can use this command:
(Get-AzureRmResource -ResourceName <Name of Resource> -ResourceGroupName <Name of RG>).Tags | %{ $_.Name + ": " + $_.Value }
To obtain a list of all resources with a specific tag applied, you can use this command:
(Find-AzureRmResource -TagName <Name of Tag> -TagValue <Value of Tag>).Name
For example:
(Find-AzureRmResource -TagName Dept -TagValue Development).Name
Policies
Resource Manager uses policies to prevent users in your organization from breaking conventions that are needed to manage resources. Policy definitions can be used to describe the actions or resources that are specifically denied. You apply policy definitions at a specific scope, such as the subscription, resource group, or resource. Policy rules allow you to set explicit allow (default) or deny permissions to operations based on your defined criteria.
It is important to note that all policies are inherited by all child resources. So, if you apply a policy to a resource group, it affects all resources in that resource group.
You may want to use polices for:
- Application of required tags on resources for chargeback and billing purposes.
- Managing environments of resources.
- Applying naming conventions.
Policy definitions are created within the JSON templates you use to deploy a resource. You configure one or more conditions or logical operators, and these define the actions that are to be taken and the effect when a condition is satisfied.
A policy requires the following three components:
- Parameters: Values that are specified when the policy is assigned.
- Condition/logical operators: A set of conditions that you can manipulate through a set of logical operators.
- Effect: What happens when the condition is satisfied—either deny or audit.
The example below allows you to configure a deny policy based on the parameters of the naming prefix and suffix not being met.
{
"if" : {
"not" : {
"field" : "name",
"like" : "namePrefix*nameSuffix"
}
},
"then" : {
"effect" : "deny"
}
}
Read the article Resource policy overview for more information on the configuration and use of policies. Also, AzureStack-Tools on GitHub provides a policy example for Azure Stack.
Locks
You can use locks to restrict operations on resources. By using locks, you can prevent deletion of, or tampering with, high-value assets. As a best practice, you should apply locks on resources that tend to be static, and those that have a high impact if they are deleted.
You can apply locks at the subscription, resource group, or resource levels through the portal, or by using any of the common tools for managing Azure Stack, such as PowerShell, CLI, or REST APIs. When applied, they allow two types of enforcement:
- CanNotDelete: Authorized users can only read and modify resources.
- ReadOnly: Authorized users can only read from the resource but may not modify or delete it.
Those applied to a parent will flow down to all child resources through inheritance, with the most restrictive lock being applied if there is more than one lock on a resource. To create or delete a lock you must have owner access to that resource.
Important points
- A maximum of 15 tags can be applied to any one resource or resource group.
- Policies work together with RBAC to deny or audit access to resources.
- Policies are inherited by all child resources.
- Resource locks should be used on static resources to prevent against accidental modification or deletion.
This article is Part 4 in the Azure Stack Validation Environment series:
- Part 1: Overview
- Part 2: Quotas, Plans, and Offers
- Part 3: Subscriptions
- Part 4: Services and Resource Manager (this article)
- Part 5: Putting it all together
The next article in this series is Part 5: Putting it all together.
Azure CAT Guidance
"Hands-on solutions, with our heads in the Cloud!"
Comments
- Anonymous
November 29, 2017
UPDATE: I added the links to all five parts of this article series.