Originally created as a PowerShell utility, the Azure Naming Tool (“ANT” from here on out) was designed to provide a way for users to generate Azure resource names that matched their company’s naming convention. ANT V1 was a great success, allowing Azure customers a way to define their naming structure, set optional/excluded properties, and generate a simple to use UI for end-users to self-service their naming needs. V1 was adopted into the Microsoft Cloud Adoption Framework tool list and became a part of many organizations’ toolsets.
In order to improve performance and adoption, the ANT was completely re-written into a modern framework/architecture, providing a simplified user interface, a robust API for extensibility, and customizable deployment options. The project is 100% open-source and available to everyone. Due to the complexity of tool and how it functions, I wanted to give an in-depth look at the technology and architecture behind the tool.
The Azure Naming Tool is a web application that allows you to generate unique names for Azure resources. It is a free, open-source tool that is available on GitHub.
The ANT has a very specific architecture, designed to provide the required functionality, while limiting the number of dependencies. The tool is 100% self-contained, meaning it can run anywhere, even without internet connectivity. This architecture was chosen to remove the barrier for entry for adoption, allowing users on any platform to use the tool.
The ANT consists of a few key components:
The ANT is a .NET 6.0 Blazor Server application, providing a fluid and simple UI for all functionality. The site relies heavily on modals and toasts to interact with components, update configurations, and provide user feedback. The site caches data when possible, improving performance and responsiveness. Configuration and name generation activities are logged to the file system, as well.
You can find more details about the UI in the Overview documentation.
The ANT heavily uses a helpers and services pattern for the code. Services provide functionality to work with components (standard and custom components), as well as name generation, logging, admin activities, and importing/exporting. This allows the tool to have a single location for functionality and simplifies development & integration. Additionally, all interaction with the JSON configuration files is done via the services classes.
Multiple helper classes exist for file system processes, logging, service interaction, and messaging. Additional helpers may be added in the future. All UI functionality is contained in pages, along with shared modals and layouts.
The tool leverages a robust API for all functionality. This allows every aspect of the tool to be integrated with other systems easily. All API calls require an API Key (configurable in the Admin utility) to execute. All API calls leverage the services and helpers classes detailed above.
You can find more details about the API documentation.
The ANT was designed to be completely stand-alone, meaning there is no backend database requirement. To store persistent data, the tool uses several JSON configuration files on the files system. The files include
The site requires all configuration files to be stored in a persistent location. When running as a container, a volume must be mounted to ensure configuration are not lost if the container is deleted/restored.
The ANT was designed to be hosted in any environment, depending on the user’s needs. The included Docker file allows the tool to be run as a container in Docker Desktop, AKS, or an Azure Container App service.
You can find more details about running the tool as a container in the Installation documentation.
The ANT uses several configuration files to function. Many of these files are customizable by the user, while some are controlled by the ANT repository. All default configuration files are stored in the /repository folder. All customizable files are stored in the /settings folder. When the site is first launched, all files in /repository folder are copied to the /settings folder. All changes are then recorded in the /settings folder.
Here is the process:
The ANT’s load process will confirm all configuration and security files are present. This ensures the site has all required components to function.
Here is the process:
The ANT has very specific security aspects that allow the tool to be run in any environment, while providing as much security as possible. Because of the lack of dependencies on 3rd party systems, all security must be contained within the app. With the project being open-source, this presents a unique challenge for keeping it secure. To get around this issue, the following process/concepts have been implemented.
When first installed, the ANT will require an Admin password be set before any action can occur. This value is stored in the configuration files. The Admin utility allows for the password to be updated at any time.
When installed, the ANT will generate a random SALT key that is stored in the appsettings.json file. After the password is set (or changed later), the entered value is encrypted using the SALT key. The same process is applied to the API Key.
The ANT has a built-in Admin section for configuring the site and managing log files. In the current version, there is a single Admin password that enables this functionality. All other site activity does not require credentials and activity is logged anonymously.
The ANT uses resource type-specific configurations during the name generation process. This configuration includes invalid characters, length requirements, special character requirements, as well as a regular expression. The ANT component configuration is used to determine if the required components are present. This process applies to names generated via the UI, as well as the API.
When using the tool UI, a name is created using the user’s selected values on the Generate page.
When using the API, the components are supplied in the JSON payload call to the /api/ResourceNamingRequests/RequestName endpoint.
The following details the process for when a generate name request is received:
The ANT uses semantic versioning to track updates to the tool. When the site is launched and the user is authenticated as the Admin, the tool will check the installed version number against the current version in the GitHub repo. If the version is out of date, a modal will be displayed to inform the user that an upgrade is available.
You can read more about the process in the Updating documentation.
Similarly, the resourcetypes.json and resourcelocations.json files are frequently updated with new types and Azure data centers. The Configuration page will display a message if the installed version of the files of the file is out of date with the current version hosted in GitHub. This process allows the ANT team to publish new resource type configurations without requiring the tool to be re-installed.
The Azure Naming Tool was designed to be as extendable and functional as possible. In order to accommodate that flexibility, several architecture aspects were implemented. I hope this article helps answer some of your technical questions regarding the architecture. The ANT team will continue to improve the tool and publish updates to the GitHub repository. All feedback is welcome, and feel free to submit a code change if you have a better idea for any part of the tool. Good luck!