3 ms·

It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the

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.

mlyle 4y ago
> 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.
- imwillofficial 4y ago
  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”
  - mlyle 4y ago
    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.
- marcosdumay 4y ago
  > 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.
jakelazaroff 4y ago
> 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.
- throw__away7391 4y ago
  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.

mlyle 4y ago

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

imwillofficial 4y ago
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”
- mlyle 4y ago
  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.
marcosdumay 4y ago
> 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.

jakelazaroff 4y ago

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

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