Should that be a microservice? Factors to keep in mind

Re:Should that be a microservice? Factors to keep in mind by bvrmn on Sunday April 21, 2019 @12:42AM (#19710575)

There is a 7th main factor. You should have multiple teams. It's sad how most of pro-microservice articles forget to mention this point explicitly. For most IT companies microservices don't make sense at all.

[ Parent | on HN ]

Re:Should that be a microservice? Factors to keep in mind by majewsky on Sunday April 21, 2019 @02:57AM (#19710883)

Exactly this. Conway's Law should be taken not as an observation, but as advice. "Sure, you can have a service structure that doesn't match your org structure, but it's gonna cost ya."

[ Parent | on HN ]

Re:Should that be a microservice? Factors to keep in mind by scarface74 on Sunday April 21, 2019 @07:26AM (#19711585)

If you have multiple teams, a well structured monolithic application where each module is it’s own service and only exposes functionality via an interface, how does being a microservice help? If each team also writes unit tests, when the other team makes changes, they can easily see if their change affects the other team.

If you are using a statically typed language, you can make a change in the signature of your function and automatically see where the change affects other parts of the code and do and automatic, guaranteed safe refactor.

[ Parent | on HN ]

Re:Should that be a microservice? Factors to keep in mind by radomir_cernoch on Sunday April 21, 2019 @02:58AM (#19710884)

This is my #1 reason for using them. Microservices can be great at delimiting responsibility.

[ Parent | on HN ]