As we briefly discussed in Chapter 1, Getting Started with Azure, your architecture begins with the subscriptions structure and an overall naming convention. The reason I bring this up is that these go hand in hand from a fundamental perspective. I have learned that there are two paths you can take with respect to your Azure configuration: the corporate path and the consultant path. The corporate path is for organizations that develop their own solutions, and all work is strictly for the organization alone. The consultant path is for those that do work for others and themselves. The reason this becomes important to point out is that this not only affects the structure of your subscriptions, but how the optional parts of the naming convention work.
Now, I like to take a simplistic approach to building things in Azure and when I am architecting solutions in Azure.
Let's take a look at what I mean. When you are building out a subscription model and a naming convention for an organization, you should take a simple approach. One mistake I have found that most people make is that they approach it from an old-school point of view, meaning that they create subscriptions and subsequently their naming conventions in a complicated n-tier or functional perspective, which creates a highly complicated support model. When you are working within an organization, you need to consider what your interaction with Azure will be the same as using Wildcard certificates or Express Route. This is because there are quite a few things in Azure that don’t span subscriptions or can span with some help.
However, this creates more complications. There are two schools of thought on organization setups: one is breaking up subscriptions based on departments, and the other is by environments. Some organizations try to blend these concepts together, which can further complicate your Azure environment. I believe a simpler approach to these is beneficial to most organizations, but some would say that resource limits could be hit. However, they can increase either through time (Microsoft increasing the limits) or through support from Microsoft increasing limits via a support ticket. The simplistic environmental approach I take is prod and non-prod. I do this so that I can get Dev/Test pricing for my non-prod environments. I then use resource groups as my application lifecycle containers. I do this for cost saving, as when I use Express Route, I only have to manage VNet peering. This doesn't solve Wildcard Cert issues or other sharing problems, but it simplifies the support for them. Now, for many large organizations, it may make sense to break up subscriptions and your naming convention to include departments as well as prod and non-prod environments.
Let’s take a quick look at a simplified view of resource naming based on the naming convention recommendations by Microsoft that can be found at https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions:
Simplified resource naming
For larger organizations, this would change slightly, but the increase in subscriptions will increase sharing support. Let’s see what this looks like. This will create a subscription by department, as well as a prod and non-prod subscription. As you can see, this will complicate your overall Azure, but may be needed for defining boundaries within a large organization:
Simplified department resource naming
The naming convention can really be leveraged any way that makes sense to you. I chose this way because it helps in using the search bar to find resources quickly and easily.
Developing a good naming convention is always a good practice within an organization, but develop one that fits you and use the recommendations as guidance during that journey, as this isn’t easily changeable in the future without redeploying and migrating.
Now, the change when looking at this from a consultant point of view is to put your clients in their own subscription, which you will mostly do from a prod and non-prod perspective. This is important to remember because subscriptions can be transferred to another tenant, or in some cases, you will create a tenant for them and follow the organizational model. Let's see what these changes will look like:
Client simplified resource naming
Now that we have discussed the importance of naming, I would like to point some other important things, such as using Tags to identify resources that can be searched or grouped. You can also leverage them to track the finance of a resource or group of resources. I leverage tags to group resources and expose the cost burn on dashboards. These things are architectural in nature but important to know, in order to get specific information from both the portal and PowerShell. First, you want to know how you get tenant information, as well as the subscriptions you have access to. This information is by tenant, which means you will need to switch to the tenant before the information will be available. Once you log in to the Azure portal (https://portal.azure.com), you will see your name and an icon in the upper-right-hand part of the portal. You click on the Help (?) icon and you will see a link for Show diagnostics. This will open your tenant JSON file with all of your information, as you can see in the following screenshot:
Show diagnostics
Once you click on this link, it will save your tenant JSON file and allow you to open it. I am familiar with this, as I refer to this file a lot in my Azure work. You can also get your TenantID from your AAD property blade, as well as the Directory ID property. You can also get it from using the following command to log in to Azure:
Always run your PowerShell Console or IDE in administrator mode so that you don't run into permission issues. You can do this by right-clicking on the icon and choosing Run as Administrator.
Login-azaccount
This is the result you should see:
