4 ms·

Wasn't git invented for that? In what way do Microservices even help? It seems to me you still have to synchronize to be sure that the Microservice from team B

Wasn't git invented for that? In what way do Microservices even help? It seems to me you still have to synchronize to be sure that the Microservice from team B does exactly the things that are specified in the new version? Is it not easier to have a pull request that says "this will do thing x", you merge it into your monolith, and then you can see in the git log that this version will indeed to x? How do Microservice organizations even manage that? Is it the reason that Atlassian has a billion dollar evaluation, because people need it to keep track?

soylentgraham 5y ago
The only thing you need to synchronise is API, no? Which is where version numbers comes in. To me, if youre working with a lot of modules/micro services, lots of modules should be able to sit on old versions and develop independently (which is the crucial part for 100 developer scenario)
kqr 5y ago
Well, not git, but modularity was invented for that. You can have a modular monolith that works just as well with 100 people as something service-oriented would. The difference lies in the level of discipline needed. It's much easier to "just go in and make that field public because it makes my implementation easier" when you have a modular monolith. With microservices, you are more explicitly changing an external API by doing that. Yes, it's the same thing. But somehow, psychologically, people feel worse about changing a networked API than making an identifier public instead of private. Edit: I forgot, there's one more thing: with service orientation, you can deploy in finer grains. You shouldn't have heavily stateful services, but if you do (and you always do!), it can be cumbersome to redeploy them. At that point, it's nice to be able to deploy only the parts that changed, and avoid touching the stateful stuff.
- kkjjkgjjgg 5y ago
  Redeployment is an argument I can accept. If it takes hours to redeploy the whole monolith, fixing bugs becomes difficult.

soylentgraham 5y ago

The only thing you need to synchronise is API, no? Which is where version numbers comes in. To me, if youre working with a lot of modules/micro services, lots of modules should be able to sit on old versions and develop independently (which is the crucial part for 100 developer scenario)

kqr 5y ago

Well, not git, but modularity was invented for that. You can have a modular monolith that works just as well with 100 people as something service-oriented would. The difference lies in the level of discipline needed. It's much easier to "just go in and make that field public because it makes my implementation easier" when you have a modular monolith. With microservices, you are more explicitly changing an external API by doing that. Yes, it's the same thing. But somehow, psychologically, people feel worse about changing a networked API than making an identifier public instead of private. Edit: I forgot, there's one more thing: with service orientation, you can deploy in finer grains. You shouldn't have heavily stateful services, but if you do (and you always do!), it can be cumbersome to redeploy them. At that point, it's nice to be able to deploy only the parts that changed, and avoid touching the stateful stuff.

kkjjkgjjgg 5y ago
Redeployment is an argument I can accept. If it takes hours to redeploy the whole monolith, fixing bugs becomes difficult.