3 ms·

> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example,

> Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices. Wouldn't this piece of business logic be best placed in an import-able module? Then, that module would be imported by those 4 microservices and problem solved ...? I don't really understand this argument.

staticassertion 5y ago
Or moved into its own microservice and then RPC'd to from those other services. But yeah.
wafer-bw 5y ago
Perhaps the language/stack they were using wasn't condusive to this but honestly I can't think of one where this would be a problem they couldn't solve with a module/package the performs the essential business logic piece.
phphphphp 5y ago
I have a very strong objection to this line of thinking. Effective use of microservices depends upon a strong, meaningful boundary between the services and that boundary should be business driven, not code driven. As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. If every microservice knows about the business logic for generating basket prices, whether the code comes from a package or not, you no longer have microservices… you have a lot of monoliths. I joined a company that did this and it was one of my worst experiences as a software engineer, I would never recommend it. [1] specifically packages containing business logic. Packages containing functionality for cross-service communication etc. are very reasonable.
- tentacleuno 5y ago
  > As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. While this sounds very radical (to me at least), I mostly understand how you've come to this conclusion. Obviously "just one package" is going to lead to further complexities down the line, and perhaps many more packages than that. Perhaps a dedicated microservice for this piece of business logic would be better, as you suggested.

staticassertion 5y ago

Or moved into its own microservice and then RPC'd to from those other services. But yeah.

wafer-bw 5y ago

Perhaps the language/stack they were using wasn't condusive to this but honestly I can't think of one where this would be a problem they couldn't solve with a module/package the performs the essential business logic piece.

phphphphp 5y ago

I have a very strong objection to this line of thinking. Effective use of microservices depends upon a strong, meaningful boundary between the services and that boundary should be business driven, not code driven. As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. If every microservice knows about the business logic for generating basket prices, whether the code comes from a package or not, you no longer have microservices… you have a lot of monoliths. I joined a company that did this and it was one of my worst experiences as a software engineer, I would never recommend it. [1] specifically packages containing business logic. Packages containing functionality for cross-service communication etc. are very reasonable.

tentacleuno 5y ago
> As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. While this sounds very radical (to me at least), I mostly understand how you've come to this conclusion. Obviously "just one package" is going to lead to further complexities down the line, and perhaps many more packages than that. Perhaps a dedicated microservice for this piece of business logic would be better, as you suggested.