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?
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.
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)
This is the right take on this. All tech people here that rave on that microservices really make their life easier even though they are working in a small team for an entire product are looking through rose colored glasses while chucking down the koolaid and also not the intended audience. The tech complexity is hardly ever worth it unless you are a large Corp.
Org complexity is a valid point. Sure you can solve it using microservices. But in this particular case (solving org complexity) such "microservice" is akin to a library with some RPC. You might as well have each team developing their "microservice" as a shared / statically linkable lib. Same thing in this context.
I feel like microservices are a solution for magpie developers. It's hard to keep a hundred engineers excited about working in an aging Java stack when there's all these shiny new tools out there. But maybe that's just my perspective, coming from a consultancy firm whose devs wanted to stay on the cutting edge.
I think this leads to silos.
MicroServices written in different lang's mean Java Dev X can't maintain Python service Y.. Not in an efficient way.
What's worse, Java Dev can't move to Team Y without upskilling not only on the service, but also the lang, so they get pidgin holed. She also can't move because she's the only Java dev left.
Except when the team division in the company does not map to any natural service API boundaries, yet it is insisted that each "team" own their services.
Then microservices increase organizational complexity too.
Suddenly product owners and middle management are chief architects without even knowing it.
Except that you do not need microservices to solve organisational problems. You need, as has always been done, to have well-defined modules with well-defined interfaces.
If there’s no organizational barrier (e.g. microservices architecture, separate repos with strict permissions) that will prevent devs from leaking abstractions across technical boundaries, those well-defined modules and interfaces will devolve into a big ball of mud.
I say this with the assumption that the team is large and members regularly come and go.
Microservices is an organizational optimization. It can allow one team to manage and deploy their own subsystem with minimal coordination with other teams. This is a useful thing, but be aware what it's useful for.
If each of your developers manages a microservice, that probably reflects that you do no actual teamwork.
rather they are used to solve organizational problems. Having 10 developers working on a single monolith? Probably fine. 100? Good luck managing that.
Yes they add technical complexity. But they reduce organizational complexity.