10 ms·
Naming microservices needs to be trivial, not cryptic (2018)
- gregschlom 4y ago100% agree with that. Also, obligatory reference to https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- yakshaving_jgt 4y agoThe fact that this is such a common phenomenon supports the argument that programming is pop culture, and it validates the complaints of so many of us curmudgeons.
- Spivak 4y agoKafka, Redis, Rabbit, Mongo, Kubernetes, Django, Ubuntu, Python, Ruby, Java, Spark, Airflow. 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.”
- yakshaving_jgt 4y agoI think there has to be a distinction between names chosen for the purposes of marketing vs names chosen for labelling internal systems.
- hrpnk 4y agoTrue that. You also want to be able to rebrand the external name multiple times – easy to do with public APIs via DNS aliases to the old one.
- for1nner 4y agoIs it too on the nose to point out the URL (domain) vs. this title?
- danhab99 4y agoI strive to follow the Apature Science naming scheme with everything I code.
- SkyMarshal 4y agoWhile I played the Portal games way back when, I can’t recall anything about the naming scheme. What are some example names from this scheme?
- jstarfish 4y agoGLADoS. Companion Cube. Potato battery.
- cm42 4y agoYeah, but if you have shipping01...03 instead of quirky-noun, ugly-color, and random-animal, then everybody will just know what's broken straight away and you won't have a job 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)
- cm42 4y agoSuddenly lamenting the emptiness left by the lack of configurability for those name generators, a la i18n. "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..."
- dewey 4y agoAt the beginning of my career I always choose fun names and was strongly in the camp of having fun names to identify better with my projects. 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.
- stevebmark 4y agoAfter a few more years where you have to scale these systems and redesign what services do and create competing ones that exist in parallel, you may find yourself back in support of non-descriptive names.
- pbreit 4y agoPremature optimization....
- stevebmark 4y agoMaybe, except there's not much downside. You also save significant time, because engineers trying to come up with the name of a service can be a drawn out and painful exercise, especially if it's a new service where you won't know its full responsibilities and boundaries until it's been used and built on for a significant time in production. I've seen so much time wasted with engineers trying to name services descriptively, especially when a similar service already exists.
- afiori 4y agoWhy not both? jellyfish-scraper, cantor-proxy-manager, pluto-webrouter
- dewey 4y ago
- k__ 4y agoWe had Asterix characters in my first company.
- lambda_lord 4y agoThis article is too long for the simple point it makes. “Don’t name your service fun cryptic names because it doesn’t scale well” could have been a paragraph on why it’s bad. 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.
- advisedwang 4y agoCodenames better recognize how design evolves over time. * 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!
- hourago 4y ago> If you split functionality out of one service, you end up with the old service's name implying it does both. 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.
- dasil003 4y agoThis completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.
- hourago 4y ago> it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense. Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing. Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
- tengbretson 4y agoThe argument for descriptive naming is that you want to make it easier for people that lack an understanding of your architecture to make changes to it?
- deleted 4y ago[deleted]
- honkycat 4y agoThe name is an abstraction. Naming it "cache" is not specific enough. 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.
- preseinger 4y agoIf a search service does more than search, this is a problem to be solved, not a property to be accommodated in a naming scheme. One of the core purposes of a service oriented architecture is to define and enforce bounded contexts. Purpose-driven names reinforce that goal.
- stevebmark 4y agoDDD is a poison to the mind and business growth. Keep the domain at the user configuration level where possible, not locked in to service design. Build domain agnostic, functionality based services. You shouldn't need to channel engineering to iterate on your business model. In the context of naming services it's even worse, trying to name services after significant domains in your business is an even stronger lock-in of temporary business concepts to service design. It's a poisonous coupling.
- preseinger 4y agoNah. The "service architecture" is literally dictated by the business. DDD is a way to model that reality.
- hamandcheese 4y agoThis doesn’t work once you are big enough or have been around long enough that a service needs to be rewritten. Personally I’m a proponent of <code name>_<functional name>. Descriptive names with the ability to disambiguate.
- VincentEvans 4y agoI like codenames that have some sort of a association with the thing being named, like “igor” for the service that retrieves something, or “hoard” for the service that stores something, or whatever. Because the association helps you remember, but it’s also is loose enough to allow for things to evolve and responsibilities to be split in the future.
- lioeters 4y agoEarlier this week I saw the name "bob" for a build system.
- VincentEvans 4y agoI approve :)
- aaronbrethorst 4y agoThis requires everyone else who works on your product to be embedded in and cognizant of the same pop culture as you. 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.
- VincentEvans 4y agoIt has downsides, just like any other proposed naming scheme.
- layer8 4y agoNaming your microservice after a favorite pop culture entity may end up spoiling your enjoyment of said entity, because the name will trigger PTSD from that messed-up microservice. So better pick some neutral name.
- monocasa 4y agoClassic satire on the topic: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- Sohcahtoa82 4y ago110% this, especially as a security engineer who might have to know about all the microservices in a product, while the software engineers might only have to know about a few of them. 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.
- thaumasiotes 4y ago> 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?
- Sohcahtoa82 4y agoTrue, I have to do it eventually anyways, but having an idea of what each service is before diving in helps a lot. 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".
- stevebmark 4y agoAirBnB doesn't allow you to name microservices descriptively. It makes sense because it doesn't scale. After the 10th "SMS Service" is created, no one knows what any of them do. And that's kind of the point of microservices, you have lots of them. It's inevitable there will be overlapping functionality. 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.
- vitiral 4y agocom.company.shopping.user.experience.shipping.intake What's the problem? /s
- bmhin 4y ago> After the 10th "SMS Service" is created, no one knows what any of them do 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).
- hourago 4y ago> it takes just as much time to learn what "Ernest" does as it takes to learn what "shipping" does. 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.
- afiori 4y ago> After the 10th "SMS Service" is created 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.
- AJRF 4y ago"First we have to call the bingo service, see bingo knows everybody's name-o, so we get the users-id out of there..." https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- stevebmark 4y agoMy favorite part of this video is how it accidentally shows the benefits of silly names: "Bingo knows everyone's name-o" is clever and easy to understand what it does. If this was called the "name service" no one would have any idea what it did from the service name alone. You have to learn what both services do regardless of descriptive or silly name, and Bingo is arguably easier to remember.
- hrpnk 4y agoI'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