Hacker News Reader

Comment by throw__away7391 | Hacker News Reader

If you're going to do this, why not also do it for classes, function, and variables?

The the reasons you wouldn't do that are also reasons you shouldn't do it for services.

A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "because Bingo knows everyone's name-o". (https://youtu.be/y8OnoxKotPQ)

A random aside, definitely the very worst name you can give any product is "Atlas". I once worked on a product called "Atlas" that also used a library and an unrelated external API also called "Atlas".

View on HN

In my opinion, one of the top criteria for a good developer is that they don't fear making changes. If a function has changed purposed, a good programmer will rename that function even if it's across hundreds of files.

A poor programmer will see that as wasted effort and not do it.

From my experience working with a good infrastructure team, good system administrators do the same sort of thing. It's easy to not change names but in 10 years you have no idea what you're looking at. Our team is constantly moving stuff around and renaming things when it makes sense to do it.

To me the most painful style of wasted effort is that of renaming an entity and all of the connection points to other services, and documentation, wikis, slack channel names, email lists, etc. because the name is causing cognitive dissonance.

If you plan to exit in 2 years and you don’t give a sh*t after that, sounds like a plan!

That's the trade off. You have to decide whether or not it's worth it. But if you never do it, then you end up a with a system where nothing means what it says and that's awful.

I feel the best time to rename something is as early in the development process as possible. Because the longer something is wrong the more entrenched it becomes.

I guess it can be subjective whether the cognitive dissonance isn’t more painful, but it certainly can be a constant strain. This is especially the case if the term in question is a software engineering term you also want to use in its regular meaning. “Cute” names at least avoid that situation.

> If you're going to do this, why not also do it for classes, function, and variables?

Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.

It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the point where you can't even choose a descriptive name for said service.

> Why would you shove unrelated functionality into the same service?

Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service.

Then, later, you end up not even using the broadcast functionality.

Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.

Then change the service name.

“The name doesn’t reflect its function anymore” is not a good case for “let’s name it some random thing”, and certainly not a good case for “let’s arbitrarily give descriptive names for some resources over others”

It's very difficult to change service names, given that you have a large population of people conditioned to say the name and lots of documentation artifacts, other code, etc.

"Broadcast message service" is, as the author points out, way too generic and also too long to be used freely. "Scattershot" rolls off the tongue and won't be completely wrong if functionality changes. And hopefully we have a small enough quorum of services that we don't drown in jargon.

> Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients.

Looks like you are trying to get a complete separation of concerns. That's a good practice when modularizing code, but it's not unambiguously good for services, because composing services come with added cost.

On practice that means that if those pieces of information are really important, there will probably exist many services that read them, and trying to reduce that to a single one will break many good qualities your software has elsewhere. Your service having a clear purpose is one of those qualities.

> It sounds like your deployment and provisioning infrastructure is sub-par.

If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.

If you need to choose a random name up front because you can't predict what the service might be doing someday, possibly you have a poor architecture--services should follow scaling and data boundaries, both of which lock you into a specific (namable) scope, or if we are more charitable to you and blame devops instead it takes too much effort to deploy new services, there too many manual steps involved, or you're doing things like hard-coding configuration or references between services, leaving you to shove unrelated functionality into the same services out of expediency.

You could make the exact arguments you're making about classes or modules. You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code. If your infrastructure is not set up to allow services to be changed easily or I think you should stick to a monolithic architecture, because trying to do development in an infrastructure-constrained environment is a nightmare.

I have to admit initially it didn't cross my mind that this could just be bad service design, Service boundaries chosen poorly not because infrastructure makes changes difficult but because developers just didn't know or plan properly, but now that I think about it that is probably the more common case and in fact is another good argument for descriptive names--e.g. hopefully it would give one pause if they decided to add some order processing code into a service named "delivery notification".

It's not always possible to know upfront the perfect architecture of your whole system. Not every business domain is as trivial as 'delivery notification'.

If you change "not always" to "almost never", I'd agree with you. I still think you can give your services descriptive names. Even non-trivial domains can have a name.

Anyone building a monolithic application is using packages or sub-modules to organize their code. While basically all monolithic applications have some kind of product or code name, I have never once seen anyone give a sub-module a weird cute name. But deploy that same code into a container and suddenly people want to start calling it "Skywalker" or "Cthulhu".

If you are using Domain Driven Design (or something similar, hopefully you're using some kind of methodology), naming the domain is one of the very first steps. You should be able to come up with a name for a service domain that is descriptive enough such that a major change to the name would also mean it was a different service.

What I am seeing is all the pro-cute names arguments against this seems to be describing a scenario where you're just sort of randomly adding code to services out of convenience. This is very much putting the cart before the horse and I don't really know what else to say beside that if you're doing that I think having cute names is probably the least of your problems, particularly when you're talking about long term maintenance of this software. These names do eventually have to be described to someone, and if you can give a coherent description of what the "Birdman" service does, you should be able to give it a good name.

First and foremost, services should own their own data, therefore it necessarily follows that service boundaries will follow data/domain boundaries. The second most important consideration for service boundaries is scaling points, which in turn directs service boundaries to follow specific interactions. I almost never break up services unless they cross one of these two lines, and taken together they give a scope of data and activity for any service that is enough to give it a descriptive name.

Here's where you lose me:

> You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code.

Unless you have extremely simple infrastructure, it's very much not "all just code": it's programs that are running on different machines that don't intrinsically know about each other.

Then it becomes a coordination problem. For example, if service B calls service A and you want to change the hostname of service A, you need to first make sure that service A will respond to the new hostname, and then that your discovery layer knows about that change before service B — and also that it still handles the old name correctly until service B has been updated.

"Oh, but I have all my infrastructure in [Terraform/Cloudformation/Pulumi/etc], that's not a problem for me." First of all, there are a ton of reasons things might slip through the cracks. Maybe you're migrating from one system to another, or maybe some dependency doesn't have great support, etc. But second of all, infrastructure is stateful and things can go wrong. If your change fails halfway through for some reason, and only some pieces are aware of the new name, are you sure your system is consistent?

Code, on the other hand, is just code — changes are atomic and self-contained. If I change a function name, I know that everything that could possibly use that function is contained within my codebase. When I deploy, it's either using the new name or not — and it doesn't matter if half of my servers have different names for the function, because they don't interfere with each other.

The one exception to this is public APIs, which are difficult to change without breaking downstream consumers. But consumers can always choose not to upgrade their version of the library. And when they can't — when it's a proxy for an external dependency, like a web service — the issue isn't the name in the code, but the name in the infrastructure.

Are they easy to change? Consider the scenario of a SDK provided to external developers (ex: UIKit). Any symbols made to be public API cannot be changed between releases cannot be changed without breaking clients.

It's true the SDK authors can deprecate and remove symbols, but this is not always easy to do, and sometimes can take several months or years to do.

Broadly, I'd say there are three categories, in ascending order of change difficulty:

1. Private code. Renaming things is easy, since you only have to worry about your own references.

2. Libraries with no external dependencies. Changing symbols in the public API can break clients, but clients can always not upgrade and everything will continue working exactly as before.

3. Libraries with external dependencies, like on an operating system (e.g. UIKit) or a web service. Changing names will break clients that don't also upgrade. IMO this doesn't really count as changing the name in code, per se — the issue isn't that the downstream code is coupled to the library code, per se, but the underlying infrastructure.

Public API names aren’t easy to change, for backwards compatibility reasons, but for the same reason you also wouldn’t change their semantics, which is what would trigger a rename.

The exception is when a name is wrong for the semantics from the beginning. In that case, there’s usually the option to deprecate it (make it trigger a warning) and only keep it for compatibility, and add the correct name as an alias next to it.

The difference is that a service might do many things, while functions and variables usually have smaller purpose.

Surely though in any case either there is some unified theme or purpose for a service or you are building a monolithic application which can just have the same name as the product.

If you are putting random functions into a service to the point where you can't even pick a descriptive name, that sounds like you've got bigger problems.

You can expose multiple things with each having their own name, and still have it implemented within a single service (single unit of deployment). The clients however don’t have to depend on it being a single service; it can appear as separate services to them. That way the scope of the “all in one” service name remains limited, and can therefore also be more easily changed.

This is similar to running multiple services on the same host, but clients don’t use the canonical hostname, but service-specific subdomain names.

> the very worst name you can give any product is "Atlas"

I always thought the worst name was "Next Generation ...", which quickly becomes kind of silly when it's time for the revision after that.

so true, names in different contexts have different needs. For internal stuff comprehension is king. I see this show up in front end and backend stuff frequently, especially in the microcosm of a console app in python where argparser can specify the `dest`, or internal name of a command line option. All my bool options get dest=is_xxx prefixes. Using more verbose names under dest is good too.

Reply on news.ycombinator.com