5 ms·

If monoliths almost always end up spaghetti code, and the problem is that people always tend towards writing spaghetti code, then the problem is monoliths. Pro

If monoliths almost always end up spaghetti code, and the problem is that people always tend towards writing spaghetti code, then the problem is monoliths. Programming is for people. I can count on zero hands how many times I've seen monoliths not end up... globbed together. It's fundamental to humans to like things broken up into little pieces with boundaries. If monoliths don't work for people, then monoliths are the problem.

EpicEng 8y ago
And a micro-service architecture tends toward spaghetti code as well because... "people always tend toward writing spaghetti code." The only difference is at what layer everything gets all tangled up. It's a function of people and constraints.
AnimalMuppet 8y ago
I think you've got cause and effect backwards. People almost always end up writing spaghetti code. They create monoliths on the way. But the problem is the people, not the monoliths. Or look at it this way: Even if monoliths are the problem, well, the people wrote the monoliths...
- jhall1468 8y ago
  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.
toasterlovin 8y ago
So somehow you can't end up with the micro services version of spaghetti code? If an engineering organization can't handle managing a single codebase, why would you assume they would be good stewards of multiple codebases?
- tracker1 8y ago
  Not only that, but who takes on the configuration and orchestration complexity of micro services? I'm not saying they cannot work, but often a restructured monolith is still a better idea... I prefer to break off bottlenecks into services where practical. Such as doing image resizing in a separate service. Breaking data structures apart often leads to it's own form of spaghetti.
  - slowmovintarget 8y ago
    Microservices allow you to scale your organization, not your application. For that particular use, microservices are absolutely better than monoliths. I can say this based on four years working on a large multi-tenant service platform composed of several hundred microservices, held against a background of 24 years building software systems, including multi-million-line monoliths (good and bad). If you're a small company, should you start with a microservices architecture? No. It is much harder to operate. Should you factor your monolith so it is easy to transition to microservices later? Yes. Your monolith will be of higher quality for doing so.
    - tracker1 8y ago
      I'm not against smaller services... but I've seen people use them, "because" and break their data models into separate services where coordinating data then becomes weird to say the least. I'm not against micro-services, I'm against making everything a microservice because one can.
    - mbrodersen 8y ago
      Change "micro-service" to "library" and you have a technology that scales equally well without introducing the additional failure modes and complexities of micro-services. That's how pretty much all open source software works. Open source software consists of thousands of libraries that people reuse for all kinds of purposes.
mbrodersen 8y ago
I have worked on many monoliths that were straightforward to maintain. Working on some right now. Spaghetti code is written by unskilled developers. It's quite simple really.

EpicEng 8y ago

And a micro-service architecture tends toward spaghetti code as well because... "people always tend toward writing spaghetti code." The only difference is at what layer everything gets all tangled up. It's a function of people and constraints.

AnimalMuppet 8y ago

I think you've got cause and effect backwards. People almost always end up writing spaghetti code. They create monoliths on the way. But the problem is the people, not the monoliths. Or look at it this way: Even if monoliths are the problem, well, the people wrote the monoliths...

jhall1468 8y ago
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.

toasterlovin 8y ago

So somehow you can't end up with the micro services version of spaghetti code? If an engineering organization can't handle managing a single codebase, why would you assume they would be good stewards of multiple codebases?

tracker1 8y ago
Not only that, but who takes on the configuration and orchestration complexity of micro services? I'm not saying they cannot work, but often a restructured monolith is still a better idea... I prefer to break off bottlenecks into services where practical. Such as doing image resizing in a separate service. Breaking data structures apart often leads to it's own form of spaghetti.
- slowmovintarget 8y ago
  Microservices allow you to scale your organization, not your application. For that particular use, microservices are absolutely better than monoliths. I can say this based on four years working on a large multi-tenant service platform composed of several hundred microservices, held against a background of 24 years building software systems, including multi-million-line monoliths (good and bad). If you're a small company, should you start with a microservices architecture? No. It is much harder to operate. Should you factor your monolith so it is easy to transition to microservices later? Yes. Your monolith will be of higher quality for doing so.
  - tracker1 8y ago
    I'm not against smaller services... but I've seen people use them, "because" and break their data models into separate services where coordinating data then becomes weird to say the least. I'm not against micro-services, I'm against making everything a microservice because one can.
  - mbrodersen 8y ago
    Change "micro-service" to "library" and you have a technology that scales equally well without introducing the additional failure modes and complexities of micro-services. That's how pretty much all open source software works. Open source software consists of thousands of libraries that people reuse for all kinds of purposes.

mbrodersen 8y ago

I have worked on many monoliths that were straightforward to maintain. Working on some right now. Spaghetti code is written by unskilled developers. It's quite simple really.