Resource Naming Convention

If you know of parents who named their children as Child-surname-boy-01 and Child-surname-girl-02, you know at least one of the parents is a public cloud infrastructure engineer. This form of naming convention is not limited to one public cloud and is even recommended by IaC providers who provide a unifying language over multiple clouds.

Organizing the resources when they number in tens or more demands a certain discipline as it would in library science. The public clouds suggest a naming convention that speaks to resource type, environment, workload, region, and instance so that there is no need to make an additional call to get the details the resource to tell them apart. Unique names are also necessary when resources get destroyed and re-created many times. When we freeze the instance, customers can expect to find the resource the way they saw it earlier. Consider a database server that was provisioned and used to save some data, but it got destroyed and recreated and now the data does not exist. Customers referring to that server by its name might find data at one point and find it missing later. To ensure that the instances have changed, it is better to increase the instance number whenever a resource is destroyed and recreated.

It is also important to know that the naming conventions help to sort and index just as any data in a database. These are two powerful techniques when we want to retrieve a subset of resources among hundreds and find it easier to discern them. Closely related names are especially helpful to indicate a similarity in origin or workload and being able to spot similarity and differences are probably one of the core duties of building out infrastructure in an organization.

Another habit of infrastructure engineers deserves special attention. When trying to use a name as a literal to input on an editor or search a set of resources, the veterans will never try to interpret the names to reconstitute it part-by-part at another location, because such steps are prone to mistakes and typos. Instead, they will treat the name as opaque between copying and pasting and taking care that the name was selected whole. Unfortunately, a significant source of errors during deployments of large-scale infrastructure occur because a resource or its component or associations were not referred to by the right name. It would help professionals deploying infrastructure-as-code to pay a lot of attention to names throughout the code just like they would if they were reading quantitative information from a resume.

Conventions can be strict or relaxed and allow grading to enforce order and structure and the inclusivity is up to the discretion of engineers as some may choose to combine or omit some components. Clear, consistent, and descriptive names will make resource management easier.

Another popular principle is the Copy-on-write where two entities sharing the same list of names will make a copy whenever one of the tries to modify it so that the other can continue to read the original. This principle applies even to resources that are currently being used so that the original set of resources are not destroyed until the traffic moves to the newly created resource set. Since creation and deletion can be repeated in an idempotent manner, this principle facilitates a safe, reliable and robust migration.

Previous articles: https://1drv.ms/w/s!Ashlm-Nw-wnWhPYQF4gznvaSS_8_bQ?e=cov7hG