3 ms·
We always had the location in the name. It really helps when you have multiple data centers. If a machine was to move from one data center to another, it would
by SkipperCat 3y ago
We always had the location in the name. It really helps when you have multiple data centers. If a machine was to move from one data center to another, it would be renamed (or more probably rebuilt).
Each DC had a different business usage, so knowing that immediately gave you context of what that machine should be doing.
We also would also have the environment (prod or dev) in the name. It just gave you an immediate understanding of the sensitivity of the machine and therefore stopped/warned folks from doing crazy things in prod.
Of course, YMMV, but I've always been a fan of names which give you context. Too much can be annoying but a little goes a long way.
- jmbwell 3y agoSure. And I would add that application identifiers can be a different problem domain. `app-dev.houston-1.example.com` would be a perfectly reasonable name for an application, whether it resolves to a host or a load balancer or a CDN endpoint or whatever. The underlying machines I still don’t really care about; they will register their availability in the cluster or whatever automatically, or else they’ll get names like “db” and “web” in the docker-compose file, or what have you. But sure, where a human might reasonably need to enter a name for a resource in order to access it, a brief descriptive name makes sense.