For a long time, I have wanted to document my naming conventions for Azure Resources - this post does just that. A consistent naming convention makes resources easier to find and easier to understand. It can provide structure amongst the chaos of potentially hundreds (if not, thousands) of resources deployed across different regions and environments. A consistent naming standard is the first pillar of the Azure enterprise scaffold and a best practice for cloud applications.
Remember that it’s difficult to rename resources in Azure, so a few minutes now will save you trouble later.
Important Note: The naming convention that I use, is unique to me. It provides me with the information that I need and organises resources in such a way that makes sense to me. This means it might not work for you. It may, however, be a great starting point.
Consider naming rules and restrictions:
Each resource or service type in Azure enforces a set of naming restrictions. Before defining your own standards for naming resources, I strongly recommend you take a look at the Naming rules and restrictions for Azure cloud services.
This convention provides a naming standard for subscriptions, resource groups and resources. The following rules are shared across all three:
<env>for a subscription, you should do the same for the resource groups and resources assigned to the given subscription.
|Contoso||Information Technology||Internal Apps||Development||con-it-internal-sub-dev|
|Contoso||Payroll System||Development||North Europe||con-payr-rg-dev-n-eu|
|Contoso||Payroll System||Production||North Europe||con-payr-rg-prd-n-eu|
|Contoso||Payroll System||Production||West Europe||con-payr-rg-prd-w-eu|
|Fabrikam||Expenses Service||Production||UK South||fab-exp-rg-prd|
|Contoso||Payroll System||App Service Plan||N/A||Development||con-payr-asp-dev|
|Contoso||Payroll System||App Service Plan||Internal||Development||con-payr-asp-int-dev|
|Contoso||Payroll System||Web App Service||N/A||Development||con-payr-web-dev|
|Fabrikam||Expenses Service||Azure SQL Server||N/A||Production||fab-exp-sqlsrv-prd|
|Fabrikam||Expenses Service||Azure SQL DB||N/A||Production||fab-exp-sqldb-prd|
Let’s take a look at a full example, including a subscription, resource group and a selection of resources - deployed into both development and production.
In this example, we will omit the environment identifier for production across all names:
The naming convention so far assumes a single instance of each resource group or resource will be deployed into each environment. For a number of reasons, this isn’t always the case. For example, you may have multiple production instances deployed across multiple regions. In this scenario, we can use the
<env> variable for the resource name and replace it with
<instance> could be an incrementing number (e.g. 01, 02, 03) or we could use the
uniqueString function to generate a unique name for each resource.
As you start to define your own naming convention, I encourage you to review and adopt where possible Microsoft’s Patterns and Practices guidance. In addition to a well defined naming convention, consider how to organize resources with tags. Resource tags give resources metadata to logically organize them into a taxonomy - and can be used to capture all the information that doesn’t make sense to store in the name.
If you decide to use this convention let me know how you get on in the comments below. Please let me know if you have any feedback too!
Thanks to Paul for reviewing this content pre-publish!
TypeScript 2.9, which was released in May 2018, introduced a new compiler option called
resolveJsonModule. This allows you to import
Take the example below. This file is called config.json. It has two properties
logLevel with type
resolveJsonModule enabled, you can import this file like any other module:
By default, this feature is disabled. You can enable it in your project’s
Alternatively, you can enable it when running
You can also selectively import individual properties from your
Take a look at TypeScipt 2.9 announcement to see what other new features came with TypeScript 2.9.
I recently read Jeremy Likness’s 2018 in Review. I was drawn to the section titled “Goals Retrospective.” As an agile advocate, I was inspired by the idea of an annual retrospective - an opportunity to reflect on the previous year. It felt like a simple way to apply “Inspect and Adapt” to my goals, aspirations and objectives (both professional and personal). Jeremy also shared his major goals for 2019. Six measurable and achievable objectives that ensure both personal and professional development.
Azure Container Registry (ACR) is a fully managed private Docker registry in Azure. In this post, I will show you how to create a continuous integration pipeline in Visual Studio Team Services to build a Docker image and push it to Azure Container Registry.
The .NET Core command-line interface (CLI) is a cross-platform toolchain for developing .NET applications. This post will explore creating a Visual Studio solution using the CLI without needing to rely on Visual Studio.