3 ms·

Last five years I'm looking at how my colleagues are struggling to dismantle a king of monoliths to services to enable various teams to move at faster pace and

by p2t2p 5y ago

Last five years I'm looking at how my colleagues are struggling to dismantle a king of monoliths to services to enable various teams to move at faster pace and scale different parts independently. Those people couldn't be more wrong. Monoliths are not your friend. Deployment times will be longer, requirements for hosts where you deploy it will be bigger, you will end up with _huge_ instances to rent because some parts of you monolith want more RAM and some want more compute. You'll have to scale more than you really need to because some parts of your monolith are more scalable than another, etc, etc, etc. You'll be unable to use different technologies to optimise that one particular use case, because it has to be deployed together with everything else and you totally don't have any infrastructure to call into another service. You'll be stuck with "one size fits all" technological choices for every component in your system. Monolith is good basically only on PoC stage. Once you have business running, you need to dismantle it ASAP. edit: grammar, spelling, formatting.

Mavvie 5y ago
Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dismantle it ASAP". I think it's a case-by-case thing, and you're ignoring the significant complexity costs of a microservices approach. > Deployment times will be longer Not necessarily. I'd say that when you have multiple changes across boundaries that need to go out together, monolith deployments can actually be faster as you only need to do a rolling update of 1 container instead of N. But if by "deployment time" you mean the time between deploys, I agree. But also...so what? As long as your deployment times are good enough, it doesn't really need to be faster. > requirements for hosts where you deploy it will be bigger True > you will end up with _huge_ instances Not necessarily. Depends on the tech stack, framework, etc. I've seen .NET (and even Rails) monoliths that are huge and only use hundreds of MB/a GB or two of RAM. But I've also seen Java monoliths using 12GB+ to handle small amounts of traffic, so YMMV. > You'll have to scale more than you really need to because some parts of your monolith are more scalable than another A problem often easily fixed with throwing a bit of $$$ at the problem, depending on your scale and per-request profitability.

by p2t2p 5y ago

Mavvie 5y ago

Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dismantle it ASAP". I think it's a case-by-case thing, and you're ignoring the significant complexity costs of a microservices approach. > Deployment times will be longer Not necessarily. I'd say that when you have multiple changes across boundaries that need to go out together, monolith deployments can actually be faster as you only need to do a rolling update of 1 container instead of N. But if by "deployment time" you mean the time between deploys, I agree. But also...so what? As long as your deployment times are good enough, it doesn't really need to be faster. > requirements for hosts where you deploy it will be bigger True > you will end up with _huge_ instances Not necessarily. Depends on the tech stack, framework, etc. I've seen .NET (and even Rails) monoliths that are huge and only use hundreds of MB/a GB or two of RAM. But I've also seen Java monoliths using 12GB+ to handle small amounts of traffic, so YMMV. > You'll have to scale more than you really need to because some parts of your monolith are more scalable than another A problem often easily fixed with throwing a bit of $$$ at the problem, depending on your scale and per-request profitability.