* 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!
If you change what a class does you need to change the name, if you change what a method does you need to change the name, same for services. If it's too hard to change service names, that's your problem.
> When you make a rewrite...
Internal changes in a service must be transparent to consumers. If consumers are aware that you are doing internal work then you are doing something wrong.
Codenames is the equivalent to call your variable John.
Imagine that you have a singleton object floating around your system, every single function written anywhere in the system must interact with that object heavily, and as a consequence everyone is familiar with what the object does and where it's defined.
What problems do you think might arise if that object were named "John"?
My experience is when we use "trivial" names folks just use abbreviations or other methods to disambiguate them anyway. For example, look at all the AWS services. Does anyone ever say "Elastic Compute Cloud" service? Come to think of it, that does seem like a fair compromise to have some formal-ish name for the service and just use a codename when referring to it.
"Codenames" are used for products for which the "name" is recognized as significant to the product. Thus, choosing the name is a project of its own -- and might take quite a bit of time -- while you might want to start work on the product before you finish picking the name. (Indeed, the work might inform the name!) But you have to be able to refer to the product, so you just give it some other name. When it's ready, you give it the "name".
That's not what's happening here; what we have here is a big complicated system with a name. We don't expect to replace the name, but we do need to have it so that we can talk about the system.
1. 10 services named after Darkwing Duck characters
2. 8 services with descriptive names, and 2 with slightly wrong names
I think most people would prefer 2
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.
One of the useful things about descriptive names is that it can help you detect duplicate work.
- Text Service
- SMS Service
- TwilioProxy
- Telephony Service
Yeah, that's always been my concern. "Descriptive" is a very precarious strategy because it takes very little to go from maybe descriptive to generic and confusing. Multiple variations of the same "descriptive" name are another common issue. I see often a lot of very similar named services that are the bane of naming in my opinion. Someone made a User Management Layer and then someone else made a Person Data Service and next thing you know you see a User Data Service and now it's just confusing. Factor in that each one of those things gets called the UML, PDS, and UDS and it just gets worse (did I mention they each connect to the Person/User Data Store/base).
If that is right we should apply it everywhere, as it does not matter. My method many is going to be PeterPan and the class name Wonderland. It's as easy to learn as a descriptive name.
Are you also going to create 10 classes with incompatible but overlapping interfaces and tradeoffs?
Some names are descriptive and other are just names. Your coworker is more likely to be named Ernest than GuyWithLongHairThatListenToPopMusicWhileReadingMangaAtTheParkAndIsReallyGoodWithPython and that is probably a good thing.
What's the problem? /s
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.
Sorry, engineers who grew up in another country. Sorry, offshore QA team is going to be utterly baffled by your nomenclature. Sorry, college grad new hires.
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.
I think you can forgive people for naming things abstractly because they don’t want to shoehorn them into a specific purpose. Calling your company’s app something vague like Fulgur rather than API makes it so you can avoid the “yes we know it’s called API but due to historical reasons it also handles some batch processing.”
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.
But you have to do that anyway. If you don't bother examining a service's most-commonly-used functionality just because the service's name implies different functionality, what kind of security engineer are you?
This is especially true when working with Java or Kotlin apps where there's 100 levels of abstraction and calls to functions named "invoke" and "run".
Potato battery.
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)
"Pop-culturation, or p13n, helps teams reduce the randomness of their random names by seeding the noun/adjective list with configurable themes, like old-timey western european guys in wigs, famous rapppers, characters from The Office, Seinfeld, Pokemon, and more. In this repo, I will..."
Also, obligatory reference to https://www.youtube.com/watch?v=y8OnoxKotPQ
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.
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
