by arthurjj on 7/20/22, 4:41 PM with 68 comments
by advisedwang on 7/20/22, 5:21 PM
* If you split functionality out of one service, you end up with the old service's name implying it does both. E.g. you end up with a "auth" service that only handles cookie auth but not API keys.
* If you expand the functionality of a service, you end up with a service's name not really clueing you in to what it does. E.g. "metadata" service that actually now includes smaller objects inlined into the database.
* When you make a rewrite of a service, until the old one is fully retired you have two confusing names, and I hope you don't pick "new_auth" or something as that will be even more confusing after the first is turned down.
Also codenames make searching for a particular component really easy. If you have to search for "auth" you will get all kinds of irrelevant results. If you search for "kazoo", you'll probably only get docs related to kazoo!
by stevebmark on 7/20/22, 6:34 PM
There's plenty of other reasons too.
Silly names are fine, it takes just as much time to learn what "Ernest" does as it takes to learn what "shipping" does. For both services, there's 30 seconds of learning, and then everyone knows what both names mean.
The anti-silly-service name dogma is misguided.
by dewey on 7/20/22, 5:14 PM
After a few years, a growing number of services and branching out a bit more into infrastructure I came to the realization that this isn't the best choice and I'm fully in support of boring descriptive names now.
Our services are now called scraper, proxy-manager, webrouter. This makes it a lot easier to see dependencies, figure out what an alert is for or track down issues in a large micro-service architecture where you are not always sure what a service is used for.
by monocasa on 7/20/22, 6:11 PM
by honkycat on 7/20/22, 5:29 PM
The uses and functionality of services change over time and then you have to rename them.
We have a service called "Search" that does... much much more than search. If we had named it "Harry" we could put a README in the project root and avoid confusion.
In fact, looking around my current work's stack... we have a LOT of "boring" service names that no longer describe what the service actually does.
by gregschlom on 7/20/22, 4:58 PM
Also, obligatory reference to https://www.youtube.com/watch?v=y8OnoxKotPQ
by lambda_lord on 7/20/22, 5:20 PM
I was hoping for a framework on naming services/APIs when a good technical name is not obvious. How do I know if “fee-record-srv” is a good or bad name? What do I do if my service’s responsibility changes over time, etc.
by yakshaving_jgt on 7/20/22, 5:01 PM
by Sohcahtoa82 on 7/20/22, 6:11 PM
It's especially bad when there's a major lack of documentation, so I gotta either set up tons of meetings or spend time examining code just to figure out what Galactus, Omega Star, and Papaya all do.
by VincentEvans on 7/20/22, 5:47 PM
by AJRF on 7/20/22, 7:14 PM
by layer8 on 7/20/22, 6:05 PM
by cm42 on 7/20/22, 5:12 PM
Besides, half of the fun is in figuring out who (or what!) deployed the mystery service, as well as the secrets that lie within (and are not in the password manager for some reason, Carrrl)
by for1nner on 7/20/22, 5:03 PM
by danhab99 on 7/20/22, 5:05 PM
by hamandcheese on 7/20/22, 5:40 PM
by k__ on 7/20/22, 5:18 PM
by hrpnk on 7/20/22, 7:23 PM
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
by tengbretson on 7/20/22, 5:28 PM