101–110 of 243 posts
It’s not “monolith vs distributed”.
It’s “good monolith vs bad monolith or big ball of mud vs domain-driven design”
It depends on what your primary domain is, level of complexity, number and makeup of enterprise integrations, and more.
Some monoliths are very bad.
Some distributed systems are very bad.
My rundown is:
- is it a simple crud system? —-- monolith
Otherwise: - model it, identify bounded contexts, proceed accordingly
Earlier quoted context omitted.
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
Earlier quoted context omitted.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
Because we can't definitively prove which one is better. There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument. The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle. Monoliths wi…
Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.
Earlier quoted context omitted.
There is no going back. The industry has seen a 5X raise in money and people. It's only natural that a job that used to take 2 now takes 10 people because of those facts. And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
Faced with this serious problem impacting sales, the programmers thought about it and eventually found a solution. They added... SLEEP instructions. All over the code in key points, sleep(seconds), calibrated so the response time was about the same as on ye olde CP/Me machines.
Customer reaction: completely satisfied.
... I think we can draw some conclusions on the universality of human stupidity and incentives to act that way.
You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Here's why I'd choose microservices for a large project:
1. People don't produce uniform code quality. With microservices, the damage is often contained.
2. Every monolith is riddled with exceptional cases in a few years. Only a few people know about corner cases after a few years, and the company becomes dependent on those developers.
3. It's easier for junior developers to start contributing. With a monolith you'd need to be rigid with code reviews, whereas you could be a little lax with microservices. Again, ties into (1) above. This also allows a company to hire faster.
4. Different modules have different performance and non-functional requirements. For example, consider reading a large file. You don't want such an expensive process to compete for resources with say a product search flow. Even with a monolith, you wouldn't do this - you'd make an exception. In a few years, the monolith is full of special cases which only a few people know about. When those employees leave, the project sometimes stalls and code quality drops. Related to (2).
5. Microservices have become a lot easier thanks to k8s and docker. If you think about it, microservices were becoming popular even before k8s became mainstream. If it was viable then, it's a lot easier today.
6. It helps with organizing teams and assigning responsibility.
7. You don't need super small microservices. A microservice could very well handle all of a module - say all of payments (payment processing, refunds, coupon codes etc), or all of authentication (oauth, mfa etc).
8. Broken Windows Theory more often applies to monoliths, and much less to microservices. Delivery pressure is unavoidable in product development at various points. Which means that you'll often make compromises. Once you start making these compromises, people will keep making them more often.
9. It allows you the agility to choose a more efficient tech/process when available. Monoliths are rigid in tech choices, and don't easily allow you to adopt a different programming language or a framework. With Microservices, you could choose the stack that best solves the problem at hand. In addition, this allows a company to scale up the team faster.
Add:
10. It's difficult to fix schemas, contracts and data structures once they're in production. Refactoring is easier with microservices, given that the implications are local compared to monoliths.
Software would be 50% better if every developer understood Tesler's Law: "Complexity can neither be created nor destroyed, only moved somewhere else." The drive to simplify is virtuous, but often people are blind to the complexity that it adds. Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain? The correct solution depends on…
Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create). The quote would probably be more accurate as: > "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."
Earlier quoted context omitted.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
On a vaguely related note but still shows how the World works. Back in 1992, my Eastern European computer science teacher told us a story. He used to work as a programmer, doing "ERP" software for communist companies (state-owned, of course). The software would run on machines featuring Z80 CPU with CP/M operating system. Anyhow after the change of regime they got 386 PCs and rewrote the software to run on them. The…
Slaves don't trade productivity for their lives, they trade time.
No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.
Earlier quoted context omitted.
If you can have a monolith for $500/month with a team of 2, or a distributed system for $50,000/month with a team of 50, what manager in their right mind would choose the former. Zero prestige in that.
Not just managers, but the senior engineers too. You can aggregate all the inter-service communication and say that you’re managing 1000 QPS service mesh rather than a meager backend with 10 QPS.
Can't we all just go back? Seriously every system I've worked on in the last 10 years seems worse in every metric than what I worked on 2000-2010.