04-11-19 | References
Want to learn how to use Azure research groups to streamline your assets and improve business efficiency? Check out this guide on the Azure research manager to learn more about the system.
Resource groups (RG) in Azure is a new approach to group a collection of assets in logical groups for easy or even automatic provisioning, monitoring, and access control, and for more effective management of their costs. One benefit of using RGs in Azure is grouping related resources that belong to an application together, as they share a unified lifecycle from creation to usage and finally, de-provisioning.
The underlying technology that powers resource groups is the Azure Resource Manager (ARM). ARM was built by Microsoft in response to the shortcomings of the old Azure Service Manager (ASM) technology that powered the old Azure management portal. With ASM, users could create resources in an unstructured manner, leading to many challenges in tracking such resources or understanding their dependencies. This led to huge difficulties that discouraged people from using Azure, as they would have a big mess once they had to deal with multiple applications that spanned more than one region.
To better understand this challenge, imagine you wanted to create an application in the old Azure management portal. To do so, you would create the virtual networks, the storage account(s), the cloud services, virtual machines, and potentially many other components of that application—without the ability to group them. If you were to build or deploy more than one application, it would become difficult to find which resources depended on which, what order to create them by, or even which application they belonged to.
Azure Resource Manager, which was announced in 2014 and became generally available in 2017, addresses this challenge and others by providing a new set of application programming interfaces (APIs) that are used to provision resources in Azure. ARM requires that resources be placed in resource groups, which allows for logical grouping of related resources.
In the figure below, two resource groups are used for grouping: First, those that are related to a line-of-business(LOB) application, and second, to an infrastructure as a service (IaaS) workload.
Although creating a resource group requires specifying a region for it to be stored in, the resources in that resource group could span multiple regions. The requirement to have a region for a resource group comes from the need to store the deployment metadata (definitions) associated with it in a specific location and does not dictate that resources belonging to it need to be in the same region.
Before ARM, you had to provision resources independently and you had to have a good understanding of their dependencies and accommodate for them in deployment scripts. As an example, to create a virtual machine, you needed to create a storage account, a virtual network, a subnet, etc. first.
On the other hand, ARM can figure out the dependencies of resources that need to be provisioned before creating the virtual machine and what order they need to be provisioned in, saving the user from having to repeat their work to fix unnecessary errors during deployment. In the example above, ARM will automatically create the virtual network and storage account simultaneously with the virtual machine. The portal blades walk the user through defining the related resources as part of provisioning the virtual network. As an example, in the screenshot below, you can see that creating a virtual machine requires specifying the other dependencies in the settings blade, including the virtual network, the subnet, the public IP address, and storage account, among other things.
ARM provides the ability to provision resources declaratively using JavaScript Object Notation (JSON) documents. The JSON document may include a description of multiple resources that need to be provisioned in a resource group, and ARM knows how to provision them accordingly. This provides an added flexibility and ease in managing resources belonging to resource groups. Using JSON in this manner allowed for creating resource templates that would make it much faster to provision resources belonging to a resource group. This also allowed for third party providers to make hundreds of templates available to provision different resources that correspond to many deployment scenarios. Those templates are available from code repositories such as GitHub or the Azure Marketplace.
In the ARM architecture, resource groups not only become units of deployment, but also units of management of related resources. This allows users to determine the cost associated with the whole resource group, making accounting and chargebacks more manageable. It also allows role-based access control (RBAC) at the resource group level, making it much easier to manage user access to the resources in the group. When users log into the Azure Portal, they will only see resource groups they have access to and not others within the subscription. Administrators will still be able to assign access control for users to individual resources within the resource group based on their roles.
Aside from scripting (e.g. using PowerShell or the Azure CLI 2.0,) resource groups can only be managed in the new Azure portal that became generally available last year. If using the new Azure Portal, a resource group item is available in the navigation menu by default and can be used to open the RG management “blade,” as you can see in the screenshot below.
The RG management blade provides a straightforward way to create and manage resource groups. It also provides a flexible customizable, high-level view of available resource groups in a specific Azure subscription. The user can select what columns to see in this view based on their role and interests and may use filters to zoom in on resource groups specific to a subscription or a location.
The new portal was designed to work well with the ARM concepts and architecture providing great flexibility and user experience in how resources are displayed and managed. The portal displays blades to the user as additional resources are created. A blade is a self-contained page (or set of pages) that allows the user to view and manage all aspects of the resource they have created using a step-by-step wizard-like approach for building the resource.
Despite the advantages resource groups and ARM bring to Azure users, it is important to use them with care and good insight. The key to having a successful design of resource groups is understanding the lifecycle of the resources that are included in them. For instance, if an application requires different resources that need to be updated together, such as having a SQL database, a web app, a mobile app, etc., then it makes sense to group these resource in the same resource group. It is important, however, to use different resource groups for dev/test, staging, or production, as the resources in these groups have different lifecycles.
In this guide on the Azure Resource Manager, we explained why Microsoft built the ARM architecture and the concept of resource groups at a high-level. It is this architectural change that allowed for easier and more scalable use of Azure and put it on the growth path it is enjoying now. If you have any questions or would like to learn more about how to use Azure Resource Groups, please contact us or learn more about what managed Microsoft Azure can do for you.
Manage your Azure spend by cost center: Setting budgets has become a key weapon in the ongoing struggle of organizations to understand and control their cloud spend. Public cloud providers have responded by offering their users services such as budget alerts and server tagging. Users, however, still struggle to see the costs associated…(Keep Reading)
AWS vs Azure: Key differences: Amazon Web Services (AWS) and Microsoft Azure are two of the biggest names in public cloud computing. Which one is right for you? To help you make that decision, let’s talk about what each provider brings to the public cloud table, and key differences between them…. (Keep Reading)
What is Azure Security Center, and how do I use it? If you use Azure, you know you need to know about the Security Center. Why? One of the biggest challenges (and a major concern for executives) to using the cloud successfully is security, and for good reason…(Keep Reading)
AWS Lambda vs Azure Functions: Key differences: Serverless computing, where operational resource management is left to the cloud provider, has been exploding in popularity. According to Right Scale’s 2018 State of the Cloud report, it’s the fastest growing extended cloud service, at 75 percent rate year over year. That growth has led to more curiosity and use of serverless architectures and Function as a Service from the two biggest cloud providers…(Keep Reading)
OTAVA provides the secure, compliant hybrid cloud solutions demanded by service providers, channel partners and enterprise clients in compliance-sensitive industries. By actively aggregating best-of-breed cloud companies and investing in people, tools, and processes, OTAVA’s global footprint continues to expand. The company provides its customers in highly regulated disciplines with a clear path to transformation through its effective solutions and broad portfolio of hybrid cloud, data protection, disaster recovery, security and colocation services, all championed by an exceptional support team.
