I've seen codenames in modern microservices and in very old systems where the operating system's file names limited creativity for binary names to two-letter ar

I've seen codenames in modern microservices and in very old systems where the operating system's file names limited creativity for binary names to two-letter area code and 6-digit running number for a module of the system. Fun times! Codenames pros & cons --- Pros: - security by obscurity – you won't understand your system beyond 20+ services; the attacker also :) - no discussions in the team on naming the service – you just take the next name from the list from the dictionary you chose - service splits or merges don't change the service name - ownership changes and moving services to another domain does not affect the service name (it may make it sound like from another universe though, like a black sheep, e.g. mixing chemical elements with action figures) - does not lead to acronym invasion where three three-letter acronyms describe three different services and you never know which is meant - leads to stronger ownership for the service --- Cons: - no way to understand what the service does w/o looking at API spec or one-line description (which does not exist) - multiple teams will implement (almost) the same thing and won't run into a naming collision telling them otherwise - optimizes for # services built, not well-defined domain/product structure - service splits or merges may invalidate the former name causing you to rethink the implications for your customers and those you know what X does - with sufficient amount of teams you will run into name collisions anyways as you run out of hero names, chemical elements, action figures, etc. - cross-team communication is very hard as teams speak gibberish to one another – it's like you'd read: "'foo' failed because of timeouts from 'bar' causing resource exhaustion and thus circuit breakers opening in 'handy' and 'dandy'" - English words will mix with service names making communication hard to understand as you won't be able to tell from context whether it's a service name or word - if you use codenames for teams you will run into the service name & team name collision eventually - strong ownership for the service leads to dysfunctions where devs get too opinionated and clingy to their past decisions --- Ways to organize the codename mess: - Use functional DNS names to alias the service URLs (you can change the implementation, but keep a stable interface for clients) - Use functional names in cross-team communication, but codenames internally - Market under the codename, so that the name is catchy - Application registry (API/CLI) allowing to view metadata & one-line purpose of the service