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
idoruuidwhile 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.