Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

Post reply on HN
Print view View original

441–450 of 498 posts

Re: Names should be cute, not descriptive

#441

Post by marcosdumay »

mlyle wrote: post #393
throw__away7391 wrote: post #388

Earlier quoted context omitted.

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 functionalit…

> 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.

Re: Names should be cute, not descriptive

#443

Post by jakelazaroff »

zffr wrote: post #422
jakelazaroff wrote: post #382

Earlier quoted context omitted.

> 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.

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.

Re: Names should be cute, not descriptive

#444

Post by marcosdumay »

AtlasBarfed wrote: post #434
erikpukinskis wrote: post #348

There’s some history here people are missing. Back in the day we used cutesy names for boxes , and we did it for good reason: Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off. You would frequently rebalance which services…

... that implies all your services already were HTTP-separated or some other swappable network invocation besides direct calls ... Which means... you were microservicing before microservices were a thing? If not, do you care to share how you abstracted your service invocations so they could fluidly go from inter-box comms to separated boxes?

Network services were port-separated since the internet was a thing. (A bit earlier, but ports had different names.)

Re: Names should be cute, not descriptive

#446

Post by unbalancedevh »

throw__away7391 wrote: post #374

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, "becau…

> 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.

Re: Names should be cute, not descriptive

#447

Post by marcosdumay »

ummonk wrote: post #38
doctor_eval wrote: post #25

Earlier quoted context omitted.

Yeah but surely there is a directory somewhere that explains this? I mean - the problem is not the number of names but the number of services. A new hire still isn't going to be able to work out what a service does just based on the name, regardless of how whimsical or apt it is. "policy-engine" might seem to be a good name for a service, but it's only one level below "kevin" in terms of opaqueness, especially when t…

"policy-engine" is an example of a name that is neither cute nor descriptive

You mean a generic policy-engine? One that reads code-as-configuration from a database, executes arbitrary I/O, and gives back a result?

Very few times somebody starts something like this. And yes, they do have cute names, because they don't have any short identification.

Re: Names should be cute, not descriptive

#448

Post by franga2000 »

AtlasBarfed wrote: post #434
erikpukinskis wrote: post #348

There’s some history here people are missing. Back in the day we used cutesy names for boxes , and we did it for good reason: Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off. You would frequently rebalance which services…

... that implies all your services already were HTTP-separated or some other swappable network invocation besides direct calls ... Which means... you were microservicing before microservices were a thing? If not, do you care to share how you abstracted your service invocations so they could fluidly go from inter-box comms to separated boxes?

The vast majority of IPC already used sockets decades ago, so it was easy to split a composition of services across multiple machines (just change the config from unix domain- to network sockets). Anything that ran commands to do things could be wrapped in ssh (for example, that's how I offloaded image processing for a sharing site).

Two layers of DNS records solve the addressing issue: each box gets a static codename with an A record and each service gets a descriptive name with a CNAME record pointing at the box it's on.

When you move a service, change the CNAME to point to the new box. If you have full box replicas/backups, you can also switch the box name or reroute at the IP level. Preferably you're running your own DNS and can issue a flush command to your entire fleet so you're not stuck waiting for propagation.

Re: Names should be cute, not descriptive

#449

Post by knorker »

MrGilbert wrote: post #144
knorker wrote: post #44

Earlier quoted context omitted.

Cute names don't scale. You can name your servers after star trek characters, and routers after star wars characters, only if you have very few.

Sure, yes - something that's not an issue at my home, but surely will at other places. Regarding naming - Middle Earth should have many possible names at hand.

Star trek has many names too. It's just that they get more and more obscure.

Which is fine if it's just you. But if it's a company and you hire someone who doesn't rewatch TNG every weekend, then it doesn't help that you know the daud's wife's name.

And that would hurt the business.

I'm sure every character in the star wars cantina has a name. That's not the point.

Re: Names should be cute, not descriptive

#450

Post by marcosdumay »

taneq wrote: post #209
causi wrote: post #149

Earlier quoted context omitted.

Modern generic-ass naming schemes are absolutely infuriating. I hear someone say "oh yeah, it's been easier since we moved our Bluē processes into Laundr containers which we manage through a mix of Bicycle and Parakeet" and my lungs are not big enough for the sigh I want to emit.

And then you look up the Bluē website and it just says "revolutionize your business by streamlining Laundr workflow!" and the Laundr website describes it as "flexible double-acting hypercraft for Parakeet ecosystems" and the Bicycle website just says "Bicycle" with a giant picture of a fixed-speed bike. (I'm assuming you made all these names up but honestly I can't even tell any more.)

They all have a "know more" session with a video (it doesn't tell anything more), a huge set of companies that use them, and a link to the documentation, where you can find a diagram with arrows pointing all over Laundr, Bluẽ, Bicycle and Parakeet.

If you insist on the docs, there are installation instructions (use Docker) and something that looks like an API. But it's not clear even if you must use the API to interact with the thing, or if it's the development docs.

Is there some kind of consultancy doing those sites?

Post reply on HN