Skip to content

Naming Things

Naming Things#

More care must be taken around the naming of things

Naming things as a Cloud Architect#

When you architect a system you might build and configure it but not be involved in day-to-day operations. Other people are involved: automation teams, operations, implementation teams, managed IT services and service centre staff.

If we can save a few seconds of confusion and frustration by making names obvious, we can save hours or days across all teams. Customers also benefit when issues are resolved faster.

It may take a lot longer to think of a meaningful name but you could be saving days for other people.

Names should be:

  • Consistent
  • Obvious

Adding features across new regions becomes easier when names of things are consistent across regions.

You want to give the minimum to make it distinct.

Things to avoid:

  • Unnecessarily long names Inconsistent naming Mixing display names and IDs. Automation teams will use the id or uuid while frontend users will use the display name Inconsistent casing Spaces, especially for API-related names

Know who is using your system#

Users should know where to go in an obvious way and should not require a lookup.

For example, the oVirt management console could be:

ovirt.example.com

Is obvious. xkm65099vm.example.com is not.

Sources#