3 ms·
Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion. And when you have alternatives, great. But for example game de
by pas 5y ago
Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion.
And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!).
If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic.
And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))
- marcosdumay 5y agoBuilding, ok, but for testing or debugging microservices aren't really an alternative. Just like scalability, they add no new capability here. The most they can do is adapt better to some set of procedures than a monolith. For deploying they are nothing but a very large hindrance.
- pas 5y agoIs it not better to debug one microservice than the whole monolith? Easy to run locally, easy to reproduce errors, etc. (My last two weeks was working in such an environment hunting a production bug. Debugging it was a pleasure. Clear interfaces, etc. Of course when a small feature requires changing 3-4 microservices the pleasure is definitely less :D) It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc. There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here. I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)
- marcosdumay 5y ago> Is it not better to debug one microservice than the whole monolith? As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.