3 ms·

Microservices don't disable spaghetti. They simply give you a means to cut it into pieces. A spaghetti monolith is many thousands of times worse than a spaghett

Microservices don't disable spaghetti. They simply give you a means to cut it into pieces. A spaghetti monolith is many thousands of times worse than a spaghetti microservice. You are doing the same thing OP did: Fundamentally misunderstanding the purpose of programming. It's an interface for humans to communicate with machines in a way that makes sense to humans. If monoliths always end up being unmaintainable pieces of garbage, then monoliths aren't really designed for humans or our tendencies. That means monoliths are the problem... they don't adapt to human nature.

AstralStorm 8y ago
Nah, spaghetti monolith is much more navigable than ravioli SOA mess. 1) You have tooling. 2) Probably also shared conventions and libraries. 3) Everything is easy to find and run on single dev machine. And no, monoliths almost never end up that way as long as they're internally modular. Services are just modules with less sharing and more overhead.
- jhall1468 8y ago
  > Nah, spaghetti monolith is much more navigable than ravioli SOA mess. How many monolithic 1,000,000+ line code basis have you navigated. 1) That's true of both. 2) That can be true or false of both. 3) That's covered by tooling? > And no, monoliths almost never end up that way as long as they're internally modular. Well your caveat is literally the problem this post is discussing. They usually aren't.
AnimalMuppet 8y ago
I've been a professional programmer for over 30 years; I'm pretty sure I don't fundamentally misunderstand the purpose of programming. Thanks for assuming that I'm stupid or ignorant, though. (For the record, I agree with your definition of the purpose of programming.) You don't have to prove to me that monoliths are bad. I get it. (You don't have to prove to me that spaghetti is bad, either.) But you seem to have missed my point. Monoliths don't just happen. They didn't just wind up in your server room because the roof leaked during rainy season. They didn't get delivered by FedEx by mistake, and your people went ahead and signed for them. No, the monoliths are there because people wrote them. Why did people write them? 1. Because they didn't know better, and just fell into it. 2. Because they thought that was the best way to architect something. 3. Because they didn't take the time and effort to make something more modular. People cause the monoliths. To fix monoliths, you have to fix the people problem, or you're going to continue to get monoliths.
- mbrodersen 8y ago
  35+ years here. Agree with you. And will add that a team of people making a mess of a monolith will make an even bigger mess of micro-services.
mbrodersen 8y ago
There is this other amazing technology that also makes it possible to cut large applications into manageable pieces and scale to any size. Even across organizations. It has been around for a very long time and has been "tested in combat". I am of course talking about "libraries". The technology that has allow the largest applications in the world to scale. For the last 50+ years.

AstralStorm 8y ago

Nah, spaghetti monolith is much more navigable than ravioli SOA mess. 1) You have tooling. 2) Probably also shared conventions and libraries. 3) Everything is easy to find and run on single dev machine. And no, monoliths almost never end up that way as long as they're internally modular. Services are just modules with less sharing and more overhead.

jhall1468 8y ago
> Nah, spaghetti monolith is much more navigable than ravioli SOA mess. How many monolithic 1,000,000+ line code basis have you navigated. 1) That's true of both. 2) That can be true or false of both. 3) That's covered by tooling? > And no, monoliths almost never end up that way as long as they're internally modular. Well your caveat is literally the problem this post is discussing. They usually aren't.

AnimalMuppet 8y ago

I've been a professional programmer for over 30 years; I'm pretty sure I don't fundamentally misunderstand the purpose of programming. Thanks for assuming that I'm stupid or ignorant, though. (For the record, I agree with your definition of the purpose of programming.) You don't have to prove to me that monoliths are bad. I get it. (You don't have to prove to me that spaghetti is bad, either.) But you seem to have missed my point. Monoliths don't just happen. They didn't just wind up in your server room because the roof leaked during rainy season. They didn't get delivered by FedEx by mistake, and your people went ahead and signed for them. No, the monoliths are there because people wrote them. Why did people write them? 1. Because they didn't know better, and just fell into it. 2. Because they thought that was the best way to architect something. 3. Because they didn't take the time and effort to make something more modular. People cause the monoliths. To fix monoliths, you have to fix the people problem, or you're going to continue to get monoliths.

mbrodersen 8y ago
35+ years here. Agree with you. And will add that a team of people making a mess of a monolith will make an even bigger mess of micro-services.

mbrodersen 8y ago

There is this other amazing technology that also makes it possible to cut large applications into manageable pieces and scale to any size. Even across organizations. It has been around for a very long time and has been "tested in combat". I am of course talking about "libraries". The technology that has allow the largest applications in the world to scale. For the last 50+ years.