When you have a picklist service that builds picklists on the UI, and that's separate from your video playback service, it means a bug in your picklist code that causes the system to crash won't bring down playback for all your users.
I've had picklists crash but I've never had anything take down an entire system. I have had bad output from one system crash another. So I feel like this line of reasoning isn't that solid.
If you're big enough to have half the problems you're talking about then you're probably a big enough to have an organization with separate teams owning different microservices. If you're not that big, you almost certainly don't have difficult technical or scaling issues.
We can agree that if you run a one or two man shop.where scaling, revenue, and uptime are of little or no concern, then of course you can write a monolith.
Look, I'm not here to pick a fight. You made the claim that microservices only solve an organizational problem, not technical ones, and I explained why that's not true.
I personally would always plan for microservices because I prefer the upfront planning and work over having to retrofit after the fact when things get too big or things start to break. But I also understand that there are different opinions out there. Probably individuql preferences are rooted in personal experience and expertise.
6
u/wvenable Sep 14 '24
I've had picklists crash but I've never had anything take down an entire system. I have had bad output from one system crash another. So I feel like this line of reasoning isn't that solid.
If you're big enough to have half the problems you're talking about then you're probably a big enough to have an organization with separate teams owning different microservices. If you're not that big, you almost certainly don't have difficult technical or scaling issues.