Your Naming Convention is Holding you Back!

Recently, a customer asked for recommendations to accelerate their transition to an automated infrastructure environment. While they had strong organizational buy-in for automation at all levels, some legacy processes were creating unexpected bottlenecks. One significant challenge we identified was their complex naming and IP addressing conventions, which were causing delays and preventing them from fully benefiting from their automation platform.

Traditional Naming Conventions

Naming conventions have long been an integral part of infrastructure management. I’ve seen organizations traditionally create elaborate names and descriptions to embed multiple pieces of information about each component. For example, a typical network device naming convention might include seven different information elements in a single string as presented below:

				
					[AIRPORT_CODE][LOCATION_ID]-[POD]-[RACK]-[PLATFORM]-[ROLE]-[NUMBER]
				
			

This results in device names like:

cdg1-p2-aa55-eos-spine1 (Paris CDG Airport, Site 1, Pod 2, Rack aa55, Arista EOS platform, Spine role, ID 1)

iad2-p7-fe10-jos-leaf3 (IAD Airport, Site 2, Pod 7, Rack fe10, Juniper OS platform, Leaf role, ID 3)

Similar “naming” conventions are also used for other attributes, like interface descriptions to capture the role of the interface, the name of the peer, the type and the ID of the circuit attached to it etc.

Why Traditional Naming Conventions Exist in The First Place

We’re so used to naming infrastructure as combinations of data points in a text string that it’s easy to forget why this happened in the first place. Understanding what these names are trying to accomplish is key to finding a better way.

Initially, the main users of these naming conventions were humans who needed to understand what they were looking at and what was happening with the infrastructure. As infrastructure became more complex, it became necessary to capture more information, but there was really no place to store it (except in an Excel spreadsheet). Operators naturally started using names and descriptions to capture that information. Because the number of characters is usually limited for these fields, the naming convention became increasingly complex to store as much information as possible.

Over time, many tools and systems started to use these names and descriptions to extract information from the infrastructure too, often because there was no better solution available. Traditional monitoring platforms are known to extract contextual information from a description using Regex.

The Problems with Traditional Naming Systems

The amount of information we can store with this system is very limited and usually restricted to mostly static information to limit the number of changes. For example, the administrative state of a device (active, maintenance, etc.) is usually not part of the naming convention because it would change the device name over time, making it very difficult for other tools that use the name as the main identifier.

Data accuracy can also be a challenge, not so much for names, but it’s a real problem for (interface) descriptions that change more frequently. For data to be useful, people must be able to trust it and know it’s accurate. Trust in data is very fragile, and a dataset with even a small inaccurate part can quickly lead people to lose trust in their data and find another way to get the information they need.

From a tooling perspective, combined text strings are very fragile, hard to analyze, and difficult to work with in programs, which leads to many other challenges.

A Better Approach

In a modern environment, a data management platform like Infrahub (also known as Source of Truth) is the perfect place to store all information related to the infrastructure: names, locations, roles, statuses, and much more in a structured format.

Storing all this business and contextual information in a central data management platform is a game-changer in many ways:

  • There is no limit to the amount of information we can store or the level of detail that can be captured.
  • There are no restrictions regarding how often data can be updated; Infrahub is an ideal platform to store the Administrative Statuses of all components in your infrastructure
  • The data is “connected” instead of being “duplicated,” which greatly reduces the effort to keep information up-to-date. Instead of storing the location name, a device object will be connected to a Location.

Having all infrastructure information properly organized in a data management platform creates many possibilities for the operations team. You can build specialized tools that use information from various data sources to quickly get to the root cause of a problem and to reduce the Mean Time To Repair (MTTR) of your infrastructure.

Once all your data is easily accessible, the possibilities are endless; from a simple python script that will display all information for a given interface to a more interactive chatbot in Slack that will provide a form to execute the most common tasks of the operation team.

To go one step further, classifying all infrastructure components with the three golden attributes—Role, Type, and Status—is a major step toward a modern automation platform. Check out this blog on Pets vs. Cattle to learn more.

What Should I do with My Current Naming Convention

Naming conventions remain valuable for human operators so they shouldn’t completely go away, it’s much easier to understand cdg1-spine than dev-340d-41be-a39d.

For most organizations, the biggest challenge lies probably with the legacy tools and systems that are actively relying on these naming conventions to work properly. Unfortunately, a lot of tools & systems don’t have a programmatic interface to keep in sync with the Source of Truth.

Automate your Naming Convention

If you can’t get rid of your complex naming conventions, the next best option is to automate them to guarantee that they will always be accurate.

The solution to this problem is to leverage automation to generate these name/description and to use automation to ensure that all descriptions, across the infrastructure, are always up to date.

In Infrahub, we recently added support for Computed Attributes to help you codify your naming convention to ensure that everything is always up to date. Computed Attributes can be defined in Jinja2 or in Python.

To guarantee consistency, Infrahub automatically analyzes which data the Computed Attributes rely on and recalculates the value when any datapoint is updated. This approach is fully integrated with the rest of the platform and works seamlessly with the automation pipeline.

With this solution, it’s possible to have multiple naming conventions depending on the consumer without adding more workload to the infrastructure team, such as: computed_name_for_IT and computed_name_for_finance.

Summary

Based on my experience, to create a more automation-friendly environment, you should:

  • Simplify naming conventions to focus on human readability rather than data storage

  • Store component information in a structured Source of Truth instead of encoding it in names

  • Use automation tools to maintain consistency across the infrastructure

  • Challenge and update legacy processes that don’t align with modern automation practices

  • Implement systems that can automatically generate and update descriptions based on your Source of Truth

Remember: The goal is not to eliminate naming conventions entirely, but to use them more effectively while leveraging modern tools and practices for managing infrastructure information.

By making these changes, I’ve seen organizations remove unnecessary complexity, reduce manual maintenance, and accelerate their automation initiatives.

Share the Post:

JOIN OUR MAILING LIST

Please enter your email address to stay informed about OpsMill developments. Your email address will be stored according to GDPR and will never be sold.

REQUEST A DEMO

See OpsMill in action and learn how it can help you achieve your goals. Fill out the form below to schedule a personalized demo.

By submitting this form, you agree that your personal data will be stored and processed by OpsMill in accordance with our privacy policy.