3 ms·

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

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

ubercow13 4y ago
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'.
- throw__away7391 4y ago
  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.
jakelazaroff 4y ago
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.

ubercow13 4y ago

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

throw__away7391 4y ago
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.

jakelazaroff 4y ago

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.