|
This article looks like a giant stack of bullshit, trying to surf the wave of trendy topics. If you are small and not have scaling problems, it is highly unlikely that you see a real difference between monolith or microservice except on the margin. But lots of things look off in the article:
Billing needed to
...
Create the order What? Billing service is the one creating the orders instead of the opposite? Monday: A cascading failure took down the entire platform for 4 hours. One service had a memory leak, which caused it to slow down, which caused other services to time out, which caused retries, which brought everything down. In the monolith days, we would’ve just restarted one app. Now we had to debug a distributed system failure.
Hum, they could have restarted the service that failed, but if they had a leak in their code, even being a monolith the whole app would have gone done until the thing is fixed even constantly restarting. And I don't imagine the quality of your monolith service that is constantly restarting in full...Finally it claims that Monday their service started to be slow, and already Wednesday the customer threatened to leave them because of the service to be slower. Doesn't look like to be a customer very hooked or needing your service if only after 2 days of issues they already want to leave. Also, something totally suspicious is that, even if small or moderate size of company you could still have people push some architecture that they prefer, no company with a short few months cash runaway will decide to do a big refactor of the whole architecture if everything was good on the first place and no problem encountered. What will happen in theory is that you will start to face a wall, degrading performances with scale of something like that and then decide that you will have to do something, a rework. And then there will be the debate and decision about monolith, microservice, whatever else... |