4 ms·

> No matter how careful you are with the initial architecture of your microservices system, it is inevitable to re-architect as you go. Isn't this true for all

by nuerow 5y ago

> No matter how careful you are with the initial architecture of your microservices system, it is inevitable to re-architect as you go. Isn't this true for all software systems? If anything, microservice architectures just make it easier to re-architect parts of the system, thus lower the bar to actually do the work.

flavius29663 5y ago
Microservices make it easier to change stuff inside each service, but only if the separation makes sense in the first place. If you have a distributed monolith, then it's actually harder. I personally think keeping the monolith around until it's very clear what the microservices are is the best way to go.
- nuerow 5y ago
  > Microservices make it easier to change stuff inside each service, but only if the separation makes sense in the first place. With regards to stuff inside each service, microservices aren't really different from monoliths. When service calls are involved, I'd argue that microservices make it even simpler to refactor/rewrite modules and entire services. Microservice architectures already impose boundaries between components that help limit the scope of any work, and teams are free to deploy and run in parallel, even in production, any service they wish to update/rewrite/launch. You can control which service is called with a load balancer, and don't bother much with the services you're developing.
  - flavius29663 5y ago
    What I meant is that you need a good separation of concerns for the microservices. Each microservice is owned by a different team, so if you need to change something that touches 2 or more, you need to collaborate with other teams...this adds a lot of overhead. Not to mention that it becomes almost impossible to do real re-architecting: you can't really move data flows or code from one microservice to another. In my experience you're more likely to end up with duplicate flows, duplicate code, just because it's too damn hard to move "class X" from A to B. In a monolith you can and often do those kinds of changes. It's also easier to have unit tests. It's easier to have integration tests that are still fast and self contained. Sure, you might say that unit tests are easy to write in any scenario but what I mean is maintaining them becomes easier, especially if you're doing Detroit style. It's easier to not break them when doing larger refactorings.

by nuerow 5y ago

flavius29663 5y ago

Microservices make it easier to change stuff inside each service, but only if the separation makes sense in the first place. If you have a distributed monolith, then it's actually harder. I personally think keeping the monolith around until it's very clear what the microservices are is the best way to go.

nuerow 5y ago
> Microservices make it easier to change stuff inside each service, but only if the separation makes sense in the first place. With regards to stuff inside each service, microservices aren't really different from monoliths. When service calls are involved, I'd argue that microservices make it even simpler to refactor/rewrite modules and entire services. Microservice architectures already impose boundaries between components that help limit the scope of any work, and teams are free to deploy and run in parallel, even in production, any service they wish to update/rewrite/launch. You can control which service is called with a load balancer, and don't bother much with the services you're developing.
- flavius29663 5y ago
  What I meant is that you need a good separation of concerns for the microservices. Each microservice is owned by a different team, so if you need to change something that touches 2 or more, you need to collaborate with other teams...this adds a lot of overhead. Not to mention that it becomes almost impossible to do real re-architecting: you can't really move data flows or code from one microservice to another. In my experience you're more likely to end up with duplicate flows, duplicate code, just because it's too damn hard to move "class X" from A to B. In a monolith you can and often do those kinds of changes. It's also easier to have unit tests. It's easier to have integration tests that are still fast and self contained. Sure, you might say that unit tests are easy to write in any scenario but what I mean is maintaining them becomes easier, especially if you're doing Detroit style. It's easier to not break them when doing larger refactorings.