Don't do this. I see these names as just obvious ways to describe what things do like variables. I wouldn't want to be reading code like ``` beeblebrox = zaphod + trillian ``` similarly names of services in architecture diagram shouldn't be undecipherable (outside of perhaps ultra secret projects -- then maybe those agencies should have a name generator :) ). The cute names even if based on some theme get very old and the cultural context almost always gets lost once the company/team outgrows. Also it's a much easier to refactor away a new service if lets say you find yourself adding a completely unrelated feature to a service named "accounting" or something boring,whereas if you named it "hades" or something cutesy, you don't have any indicator whether the feature has outgrown. I've found it much easier to deprecate/sunset services and systems when they're obviously named too. One exception I'd say is when nicknames just arise and it becomes obvious to call it that. It's very rare and it happens. Borg at google is perhaps a good example here. It's so all encompassing that it's obvious what it means and calling it another name like "container orchestrator" or something similar perhaps doesn't have same gravitas. I think Microsoft had something called Autopilot which is even clearer but not it can be applied to many things.