It remains critical to have the right governance framework and processes to reap maximum benefit from Microsoft Azure Cloud and make the environment more robust, secure, efficient, and effective. Enterprise IT needs to ensure that data and systems are adequately protected while balancing it with the need to quickly meet the demands of customers (both internal and external).
Moving to Azure would only yield results when done right. Once the strengths and weaknesses of the Cloud are diagnosed, IT governance can then be revised accordingly. Besides, properly planned governance and security foundations, go on to create a protected and controlled environment.
The tried and true way forward is to understand the features and concepts of Azure governance. While Microsoft has tools and resources to guide organizations based on their governance needs but deciding where to begin and how best to implement them can often be tricky.
The following article is the part–1 of a four-part article series on common Azure governance–related mistakes organizations make and best recommendations to tackle them. The article will also address some critical considerations helping organizations align their IT strategy with business strategy and produce measurable results, with authority.
Subscription Planning
Effective subscription design helps organizations establish a structure to organize assets when migrating to Azure. Each resource in Azure, such as a VMs and database, is associated with a subscription. Adopting Azure begins by creating an Azure subscription, associating it with an account, and deploying resources to the subscription.
See Azure fundamental concepts for a better understanding of concepts and terms that are used in Azure.
Moreover, as the digital estate in Azure grows, organizations often need more than one Azure subscription to meet the requirements. Subscription resource limits and other governance considerations often require additional subscriptions. Having a robust strategy for scaling your subscriptions is very important.
Microsoft outlines several subscription best practices when deploying your production and preproduction workloads. Microsoft recommends that while deploying your first production workload in Azure, you should start with at least two subscriptions: one for your production environment and one for your pre-production (dev/test) environment.
If you have only a few subscriptions, managing them independently is relatively simple. But if you have many subscriptions, you should consider creating a management-group hierarchy to simplify managing your subscriptions and resources.
Management groups allow efficient management of access, policies, and compliance for an organization’s subscriptions. Each management group is a container for one or more subscriptions.
Coming Soon: Part-2 of this series for more insights on subscription planning, design recommendations, and naming best practices.
Resource Groups Planning
The key to success in Azure is to learn how to optimize management and performance, as well as minimize costs. Resource groups (RG) remains critical in grouping a collection of assets in logical groups for easy or even automatic provisioning, monitoring, and access control, and more effective management of their costs. While RGs have some limitations too, some recommended Azure resource management best practices include:
Use Azure Resource Manager (ARM) and its templates to replicate Azure resource groups, with ease and flexibility. Use either an API call or Azure portal to execute templates and create workflows continually. The ARM architecture 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.
To minimize the Cloud bill, organizations must consider leveraging Azure Reserved VM instances (RIs) – a type of discounted Azure VM compared to on-demand VMs. Moreover, with Microsoft’s flexibility feature for RIs, users can now apply the discount to differently sized VM instances within the same VM family.
Naming Conventions
Using naming conventions for your resources is not new and age-old best practice. However, in on-premise environments, the resource types were very limited (Virtual Machine, Server or Storage) and naming was done in a controlled fashion. In Cloud, you have multiple different resource types. For instance, for a simple virtual machine, you may create end-up with different resources like resource group, resource name, multiple storage accounts, vnet, nsgs, public ip, and many more.
Azure has its own set of naming rules and restrictions for the resources and a baseline set of recommendations for naming conventions. The choice of a name for any resource in Microsoft Azure is important because:
- It is difficult to change a name later.
- Names must meet the requirements of their specific resource type
However, naming conventions in Azure have been a subject of elaborate debates. Quite so, considering a systematic naming process could prove powerful when organizing and retrieving information as it gives identity to the resources (ease of identification). A well-documented and consistently followed naming convention would enable organizations to retrieve important Azure resource-related information such as ownership and costs. More importantly, it will give an overview of the entire infrastructure, making collaboration across departments and teams easier and quicker.
You should also plan your naming conventions keeping the subscription, resource groups and tagging in mind. You do not want to duplicate the information and make it easier for everyone to understand and manage the resources.
Resource Tagging
Tagging your Azure resources to either support IT teams managing Cloud workload or integrate all company information, will eventually reduce the complexity of monitoring assets and make operational decision-making much easier. While resource groups provide the functionality to group resources that share the same lifecycle, tags can be associated with resources belonging to multiple resource groups but the same subscription.
We should suggest what type of tags – like application, application owner, environment type, creator name, etc. should be created, along with suggesting a rule for creating at least 5 to 7 different tags as below –
- Creator – Name of the person who created/requested the resource
- Department/CostCenter – the department for the resource for example Marketing, Finance, R&D, or Client Name
- Application – the application using this resource
- Application Owner – the name of the person or a group/role who is main owner of the application – like a contact person or role. Could be a Project Manager, Department Head e.g. HR Manager
- Role – what is the purpose or role of the resource for example File Server, web server, DB Server, etc.
- Project – name of the project, client project name
- Environment – type of the environment
Limitations of resource tagging: Various resource types do not support the tagging feature. Also, each resource group or resource can only have a maximum of 15 tag names or value pairs. The tag name cannot be longer than 512 characters. Similarly, for the tag value, the character limit is 256 characters. In the case of storage accounts, the tag name gets limited to 128 characters, although the threshold for tag value stays the same. All tag names and values can be only 2048 characters long for virtual machine sets.
.png){kind=icon}