This did sound cool to me, at the beginning of the auto-scaling, image-based, cloud times... But then I did realize a couple of things, that improve with meani

This did sound cool to me, at the beginning of the auto-scaling, image-based, cloud times... But then I did realize a couple of things, that improve with meaningful names: 1) Alerts impact and scope. It's easy to know what are you seeing in your phone, if balancers, rds clusters, and instances have meaningful names. 2) Metrics visualization. Maybe the graph is the same, but a meaningful legend sometimes helps. 3) SSH connection. I like to auto-complete SSH, not to copy/paste ssh and write down extra parameters like different .pem files. 4) (Inter) team communication. The same that with graph legends, for humans, it's easier with names than with ids. 5) Custom commands parametrization. The same than ssh, I prefer to be able to write down the parameter (host name, service name) of my command, without getting out of the terminal, copy the ID or IP, get back, paste, verify... 6) Costs/Reports visualization. 7) Backup management. Let's say S3 parent for the backups of a instance/service. Backup reports too. At the end, I think that I can have cattle mentality regarding Configuration Management, System patching, Version change, etc... BUT I still can get benefits from thinking a little bit element and service names. At the beginning (of the cloud concept), I did read pet Vs cattle, and I did think IDs were the thing. Now I think that to scale to many customers or many environments, it's better with previous thinking. Being the little string of the alert in the phone, the biggest winer.