I have fond memories of when IT admins would give names to their servers, and even assign them unique personalities. It was a simpler time, before virtualization and the cloud made infrastructure exponentially more complex. My favorites were the The Lord of the Rings fans who named their servers after hobbits and elves; anything related to Bilbo and Frodo might be a web server, while Arwen and Legolas were databases. It was a fun way for IT admins to express themselves, but you had to know your Tolkien to understand the role a server might play.
This model worked for small environments but doesn’t scale in the era of virtualization and the cloud. There are simply too many things to name, and you’re forced to pull out esoteric Tolkien references that only a supergeek would know.
With the cloud, and specifically IaaS, many of us have abandoned the notion of naming or even uniquely identifying servers. It’s impossible at this scale, where workloads are spun up and torn down by the hundreds. With a service like AWS, we use machine-generated IDs that have little significance for people.
But in the process of giving up on names, we’ve lost some of our ability to manage and control our infrastructure. If servers before were treated like pets, managing this new environment is akin to herding cattle. We still need a way to classify servers, both physical and virtual, as well as the workloads and services that run on top of them. Only in this way can we manage our infrastructure in the most efficient, effective way.