3 ms·
The problem is that I see microservices adopted for two very different reasons: 1) We need to split this thing out because we need to isolate it Problematic.
by bsder 4y ago
The problem is that I see microservices adopted for two very different reasons:
1) We need to split this thing out because we need to isolate it
Problematic. Generally the issue is political--not technical. The service is necessary but not getting enough support--isolate it to force fixes. Some service not being responsive enough to internal customers--isolate so tickets now can be assigned and blamed on them. etc.
2) We need to split this thing out because it's a perfromance bottleneck and we need to scale it
A reasonable choice. The people scaling something need to be able to bound and limit the scope or they'll never make any progress.
The issue is that #2 is VASTLY rarer than #1.
- youngtaff 4y agoIsolation is probably #3 “If this services fails we can carry on working with a degraded experience”, notifications on Twitter et al are probably one example of this
- bcrosby95 4y agoI kinda disagree. I've scaled plenty of code by just adding another monolithic app server. It rarely matters where the load is coming from, another pile of resources evens it out. But if you have a problematic part of your codebase that regularly shits the bed, keeping it in your monolith will take it all down. Splitting it out is the smart thing.