Hacker News new | ask | show | jobs
by tentacleuno 1610 days ago
> 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.

3 comments

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.

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

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.
Or moved into its own microservice and then RPC'd to from those other services. But yeah.