Azure Naming Conventions – Think First, or You’ll Be Stuck

In the Azure cloud environment, many computing resources and asset types can be created to build-up an operational environment to support business needs. These include computers, networks, databases, queues, IP addresses, etc. All Azure resources have one thing in common – they must be given a name when being created. It’s a very good idea to develop a naming convention for resources prior to creating them.

Why Naming Conventions?

For anyone who’s worked with computers, and especially for those who write software, naming conventions are a well-known topic and best practice. A good naming convention – using abbreviations or upper/lower case for example – can improve maintainability, reduce human errors, and lower training complexity. The reason is rather simple, actually – the name assists in identifying the intended use of something, and possibly a categorization. For example, a SQL Server storage procedure might be called sp_Calculate_Salestax, where “sp” indicates that the object is a stored procedure (useful when seeing a long list of items; it’ll also cause like items to sort together in a display), and it performs a sales tax calculation. Without ever seeing the source code or having to reverse-analyze it, one can discern what the object is, and what it does. The underscores and initial capitalization make the name easier to read quickly.

A significant factor in Azure resource naming is that once a name is chosen at creation-time, it cannot be changed. The closest approximation of changing a name is to create an identical new resource with the preferred name, then delete the old one. That’s fine if you’ve just created the resource, but if you’ve got 100 of them and they’re interlinked, it’s essentially impossible. You’re stuck with the “wrong” name indefinitely. That’s why adopting a convention before creating resources is a really, really good idea.

Azure Silly Naming

Azure’s a bit funny when it comes to names, however. Some resource names can include punctuation, some can include mixed-case, and others cannot. There doesn’t seem to be any rhyme or reason – it’s really up to the specific resource being created. Therefore, it’s impossible to create one naming convention and use it consistently throughout Azure. Name length limits are also variable, dependent upon resource type, from 24 to 1024 characters. Microsoft’s documentation shows 23 different naming rules for the various Azure resources (see link, below), and you can expect this list to grow as new services are added.

One factor that influences allowable name syntax is whether the resource is internet-facing with a DNS name, or not. The internet’s naming rules have been around a long time and are very set, so it’s reasonable that internet-facing resources must comply with DNS naming requirements. Azure takes this a little further, disallowing some valid DNS syntaxes in certain contexts.

The following image shows a valid internet DNS name (jimmy-azure.core.windows.net) being rejected by Azure for a storage account.

DNS name rejection by Azure

But here’s a similar name, accepted for a Function App (jimmy-azure.azurewebsites.net).

DNS name acceptance by Azure

Automatic Names

There’s also a resource naming oddity I’ll mention in particular. When creating a Function App and specifying the Consumption Plan, Azure will make a special version of an App Plan on your behalf (with a unique icon) and set the name based upon deployment region. In the East US datacenter, Consumption App Plans will all be named EastUSPlan, a duplicate name which you cannot change. You won’t be able to distinguish which plan goes with which Function App. Internally, the identifier for each App Plan is unique, so Azure won’t confuse them, but your administrator won’t easily be able to understand which is which, and specific associations to Function Apps.

Here are 2 Consumption App Plans with duplicate names, created and named automatically during provisioning of a Function App.

Duplicate App Service Plan names

In another example, provisioning an Azure AD Domain Service also caused the creation of a virtual network with associated NICs, address, and load balancer. Note the last 4 items' names - something Azure itself assigned, and which cannot be changed.

Azure-assigned resource names

Tags

Resources also can have multiple tags associated with them. A tag is just a free-form short textual name/value pair. This allows you to locate resources according to your tagging strategy, regardless of the resource type or name. While not exactly a “name”, tags are an alternative way to label and manage Azure resources, using whatever tag-naming convention you wish and applicable across all Azure resources.

Here, a tag “applicationType : web” is used to locate resources, which are show in the right blade.

Application tags

Naming Best-Practice Suggestions

OK, taking into account the above peculiarities, what’s an Azure architect or admin supposed to do when choosing a resource naming convention? Are there any suggestions?

Sort-of. Microsoft has published an article with good details on exactly this topic. They document the naming restrictions mentioned above, per resource type. Azure resource names should be composites, formed segment-by-segment from meaningful short strings.

Consider these name components to form a name. Use the minimum number of components to clearly identify a resource within a larger Azure environment; avoid using redundant components that don’t add identification value. Abbreviate name segments to 2 or 3 characters at most, to insure the final name won’t be too long. When allowed, hyphenate the segments for easier reading. Consider excluding your company’s organization names, since re-orgs can occur, and companies merge or acquire other companies; thus this class of names is not necessarily durable.

• Company name (internet-facing only)
• Division name
• Resource location (East, West, etc.)
• Azure resource type (Storage, SQL, Virtual Machine, etc.)
• Technical function (Web server, DB server, domain controller, etc.)
• Serial / sequence 

Naming Samples

Resource Name	Description
RG-Math	Resource group for math functions. Visible internally only, can contain resources in multiple regions.
JA-AS-Math-Sqrt	App Service (web app) that provides a math function for square roots for Jimmy Azure company. Region doesn’t matter. Name is visible on the internet as http://as-math-sqrt.azurewebsites.net. Using a company prefix is a good idea here, since this name must be globally unique within azurewebsites.net.
ASP-Math	App Service Plan (PaaS VM scale unit) underlying the math app service. Must be in same region as app service, but doesn’t matter which region that is. Visible internally only.
VN-East-Sql	Virtual network in East region, intended to hold SQL Server. Network isn’t directly visible on the internet; that’s the job of a public IP address.
GW-East-Sql	Gateway attached to the virtual network for SQL in the East region.
JA-FN-Math-Sine	Function App for company Jimmy Azure, for a math function that calculates Sines. Visible on the internet as https://ja-fn-math-sine.azurewebsites.net.
jasaeastsql01	Company Jimmy Azure, Storage Account intended for SQL Server in the East region, number 01. Visible on the internet. Has more restrictive character requirements. Accessible at jasaeastsql01.core.windows.net and must be unique in core.windows.net.
JA-Srch-Docs01	Company Jimmy Azure, Search engine for documents, visible on the internet at https://ja-srch-docs01.search.windows.net. Region doesn’t matter.

  

References

• Microsoft general naming suggestions and restrictions.
• Microsoft Storage naming
• Microsoft Queue naming
• Microsoft Table naming
• Microsoft video starting with naming suggestions

Azure Site Recovery Setup - Failure Was An Option

The past couple days, I performed a "lab" experiment using Azure Site Recovery. This is the feature that, amongst other things, lets you replicate on-premise Hyper-V virtual machines to Azure.

ASR is a component of a disaster recovery / business continuity plan that enables running Hyper-V loads in Azure, after a brief fail-over period. Once ASR is initially set up, one click "fails-over" the network to use a newly-provisioned Azure virtual machine to continue operations. Data from on-premise VM disks gets replicated up to an Azure storage account frequently, minimizing any lost data. RPO and RTO objectives can be met for modest requirements, if not for transactional workloads.

You can also use this technique to migrate on-premise VMs to an Azure IaaS setup, though it's a funky approach and I'm not sure I'd really recommend it.

My home office computing environment is flexible and provides a platform for modeling and experimenting with a Windows Server 2012R2 domain, Hyper-V, networks, databases, and so on. I created a test VM to use for the experiment, which was expendable upon experiment completion. I figured that I'd spend a day setting it up, playing with it, and then tearing it all back down.

That was the plan, anyway. But it didn't work out that way.

Sure, I watched the videos and read the documentation. I checked the prerequisites. And, the Azure management portal is generally pretty good at guiding administrators through a sequence of steps to setup most any resource. Using these three sources, and my good general knowledge of all the technology and architecture involved, I figured it wouldn't be too hard to do.

I started in the Azure portal, setting up resources using the Resource Group approach (i.e., not Classic). Setup steps include creating a backup vault, storage account, and virtual network. The storage account holds the replicated VM's disks, and the virtual network is where the Azure VM will connect after a fail-over. But you don't make a VM, as you'd pay quite a bit for that resource even if it's never used. Instead, Azure will automatically provision a VM upon fail-over; it'll select a best-match for the "hardware" configuration of your Hyper-V VM (this increases RTO by a few minutes, in exchange for strongly reduced costs).

Hurdle 1 - Not on a DC

The first step for preparing on-premise machines is to install an ASR agent on the Hyper-V host, obtained via the Azure portal. This is the computer that actually runs the VMs you'd like to protect.

This is when issue #1 appeared. It's not documented at present, but you cannot run the ASR agent on a domain controller. Yep, in my small office, I have a DC doing overtime by running several functions that aren't normally setup that way in a commercial environment. But in my low-load environment, it works fine. This is where my VMs were running, but thanks to this restriction, I was unable to proceed. Dead-end on that computer.

ASR error message

Fortunately I have a new laptop that functions as a backup DC and Hyper-V host, and is even more powerful than my older desktop/server machine, so I was able to demote it and install the agent. Annoying, but not a deal-breaker. It just meant that I was running without a domain backup for a day - a minor risk that I was willing to take, to appease somebody in Redmond.

Hurdle 2 - Not during the summer

Once the agent was installed on a Hyper-V host, the next step was to download a configuration file from the Azure portal and supply it to the ASR setup utility. Trivial, right?

No.

Turns out that ASR setup checks time-of-day accuracy of the host before proceeding. I could speculate why it does this, but that doesn't matter. With the host computer's timezone set to "(UTC-05:00) Eastern Time (US & Canada)", but Daylight Savings Time in effect (which gives an actual offset of UTC-4:00), ASR insisted that my time was wrong, and therefore it would not proceed. I keep my computers (and clocks, etc.) within 1 second of correct time, so I knew this was a bogus "error".

I've never seen such an error from any software before. The interweb is full of problem reports related to this issue, and even a couple years after those complaints, the issue still isn't fixed. Maybe they only test in Redmond during the winter, when actual time offsets match the configured timezone region?

Anyway, the work-around is easy enough: change the hosts's timezone to "(UTC-04:00) Atlantic Time (Canada)", then set my clock to the current local time where it's sitting. Problem resolved, and now I could continue with configuration. Also had to remember for later, to reset the computer's timezone.

Hurdle 3 - Not in a paired region

After getting the ASR Agent installed, configured, and running OK on the on-prem Hyper-V host, I continued setup within the Azure portal. In short order I successfully completed that, and clicked that wonderful button labeled "Enable replication".

Success! Or so I thought.

That's when the next hurdle in sequence appeared. If you imagine that I might be getting tired of getting blocked by setup problems, you'd be right.

The problem was the Azure region I had selected for the Azure VM replica. I normally place Azure assets in East US, so I chose West US for the replicated VM and disks. This is due to region pairing. Well, an error appeared in the portal indicating that West US wasn't allowed (along with certain others).

Of course, I'd already configured a virtual network and storage account in the disallowed region, and now I had to tear them down and rebuild in another acceptable region (moving those resources to another region wasn't an available portal option). I chose West US 2, rebuilt assets, and retried the replication.

Finally, replication started working.

At this point I thought it'd just take some time, and the replicated disks and VM would be ready for fail-over testing in Azure. A nice accomplishment, though with much time wasted bumping into problems that weren't documented, or were bugs. Actual experimenting like this - a Proof Of Concept - is where you discover the difference between the lovely videos and marketing info, and how something really works.

Epilogue

Lest you think I was successful with ASR after all the above, there was one last issue that broke the whole deal.

When replication of my on-premise disks had reached 98%, it stopped with an error in the Azure portal UI. The message was too general to be actionable - something about failure accessing Azure storage - and to check the Hyper-V host's event logs to find details. I did that, and found no information.

I also searched for how to restart replication as the error message further suggested, but alas could never find how to do it in the portal.

So after many hours, configuration changes, and trials, I decided to terminate the experiment. I reset the host computer's timezone, removed the ASR software, and re-promoted it to a DC. Chalk it up to learning, and move on.

After resetting the host computer, I later discovered that the replication restart for which I'd searched was in the host's Hyper-V management tool, via right-click of the appropriate VM. In other words, VM replication uses the mechanism within Windows Server 2012R2 Hyper-V, and not something in the Azure agent. Would've been nice if the error message in the Azure portal had mentioned that, since most other replication setup was in the portal, leading one to assume that's where the restart function lived.

And lastly, about that VM I was trying to replicate? I'd made sure to use a scrappable VM in case something happened, which it did. Even after the config tear-down, that VM was still configured to replicate to Azure. There was no way to disable it - the Hyper-V management tool said that replication had been enabled by another program, and that program must be used. So my VM was in an undesirable state (though it still apparently worked for the time being). The solution? Delete the VM.

Astute Azure Attainment

I've played with Microsoft Azure's cloud computing environment for a few years, and it's a lot of fun. I'm convinced that Azure, and competing cloud services, are the future of internet-based web sites, services, and SaaS (Software as a Service - essentially fully-featured online apps).

In this blog I'll be cataloging my experiences learning, using, building, and tearing-down Azure resources, and related items from the world of C# development, SQL Server, and the whole Microsoft stack. Stay tuned!