8 ms·

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not

by ozim 5y ago

Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of monoliths ended up being spaghetti code just like now lots of micro service architectures end up with everything depending on everything.

addsidewalk 5y ago
What’s a mono repo of micro services called? We sure spent a lot of time debating semantics for a supposedly economical culture. I tend to focus on stability, correctness, security as those have concrete human meaning. All the rest is jargon largely unhelpful to solving problems. Often helpful selling books, finding “consultant” work, and booking speaking fees though.
ravenstine 5y ago
> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it should have the responsibility to handle or is reasonable for one repository to manage. I wish these sorts of battles would just go away, though, because it's not like micro services are actually bad, or even monoliths depending on the situation. They're just different sides of the same coin. A monolith results from not a lot of care for the future of the code and how it's going to be scaled or reused, and micro services are often written because of too much premature optimization. Most things should be a "modular monolith". In fact I think most things should start out as modular monoliths inside monorepos, and then anything that needs to be split out into its own separate library or microservice can be made so later on.
- lostcolony 5y ago
  No one had to invent the monolith or define how far it should go; it was the default. Microservices came about because companies kept falling into the same trap - that because the code base was shared, and because organizational pressures mean features > tech debt, always, there was always pressure to write spaghetti code rather than to refactor and properly encapsulate. That doesn't mean it couldn't be done, it just meant it was always a matter of time before the business needs meant spaghetti. Microservices, on the other hand, promises enforced separation, which sounds like a good idea once you've been bitten by the pressures of the former. You -can't- fall into spaghetti. What it fails to account for, of course, is the increased operational overhead of deploying all those services and keeping them playing nicely with each other. That's not to say there aren't some actual benefits to them, too (language agnostic, faults can sometimes be isolated), but the purported benefits tend to be exaggerated, especially compared to "a monolith if we just had proper business controls to prevent engineers from feeling like they had to write kluges to deliver features in time".
  - Lhiw 5y ago
    > organizational pressures mean features > tech debt, always I wish. Our organisation focuses on building libraries and frameworks. Literally every solution is a new library. Products take months to ship because you have to either make a new version of a library because the old version wasnt really expecting to work with your needs, or you need to refactor your existing libraries to work with new needs, that takes months of refactoring all the usage points. It's nuts. I tried to build a completely new thing recently, got told to build a library. My thing is pretty specific, doesn't need a library, and will just be single use. It will consume lots of libraries. Would have taken about a week to ship. Instead, here we are week 4 still figuring out how to make this pile of shit work. Sometimes I wish people would just build abstractions on top of what we have. Not everything needs to be a library, sometimes, your new product code is all you need to solve a problem.
  - spc476 5y ago
    The individual code bases of a microservice might not involve spaghetti code, but the interconnections certain can. I'm looking at a diagram of the service I work on, with seven components (written in three languages), five databases, 25 internal connections, two external interfaces, and three connections to outside databases, all cross-wired (via 6 connections) with a similar setup geographically elsewhere in case we need to cut over. And that's the simplified diagram, not showing the number of individual instances of each component running. There is clear separation of concerns among all the components, but it's the interconnections between them that take a while to pick up on.
jhgb 5y ago
> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Isn't "non-modular monolith" just spaghetti code? The way I understand it, "modular monolith" is just "an executable using libraries". Or is it supposed to mean something different?
- falcor84 5y ago
  The way I see it, spaghetti code is actually a very wide spectrum, with amorphic goto-based code on one end, and otherwise well structured code, but with too much reliance on global singletons on the other (much more palatable) end. While by definition spaghetti code is not modular, modularity entails more. I would define modularity as an explicit architectural decision to encapsulate some parts of the codebase such that the interfaces between them change an order of magnitude less frequently than what's within the modules.
rco8786 5y ago
> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Yes! Thank you. The "modular monolith" is just "decent separation of concerns in your code" and should be there from the start.
- sbysb 5y ago
  I would actually disagree - to me you can have "decent separation of concerns in your code" but still have only built the app to support a single entry point. "Modular monolith" to me is a system that is built with the view of being able to support multiple entry points, which is a bit more complex than just "separating concerns"
  - zbentley 5y ago
    If your concerns are well separated in a monolith (in practice this means being able to call a given piece of functionality with high confidence that it will only talk to the data stores/external resources that you expect it will), adding new entry points is very easy. Now, it's not trivial--going from, say, a do-everything webserver host to a separation of route-family-specific web servers, background job servers, report processing hosts, and cron job runners does require work no matter how you slice it--but it's a more or less a mechanical or "plumbing" problem if you start from a monolithic codebase that is already well behaved. Modularity is one significant part of said good behavior.
SkyPuncher 5y ago
> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Unless you're in a large established org, modulatity is likely a counter-goal. Most startups are looking to iterate quickly to find pre-PMF. Unless you write absolutely terrible code, my experience is you're more likely to have the product cycle off a set functionality before you truly need modularity. From there, you either (1) survive long enough to make an active decision to change how you work (2) you die and architecture doesn't matter. "Modular monolith" is a nice framing for teams who are at that transition point.
jameshart 5y ago
The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big ball of mud’) Monoliths are monoliths because they have - one set of shared dependencies - one shared database - one shared build pipeline - one shared deployment process - one shared test suite - one shared entrypoint As organizations and applications get larger these start to become liabilities. Microservices are part of one solution to that (not a whole solution; not the only one).
- Retric 5y ago
  Monoliths don’t actually look like that at scale. For example you can easily have multiple different data stores for different reasons, including multiple different kinds of databases. Here’s this tiny little internal relational database used internally, and there’s the giant tape library that’s archiving all this scientific data we actually care about. Here’s the hard real time system, and over there’s the billing data etc etc. The value of a monolith is it looks like a single thing from outside that does something comprehensible, internally it still needs to actually work.
  - jameshart 5y ago
    But all those data sources are connected to from the same runtime, right? And to run it locally you need access to dev versions of all of them. And when there’s a security vulnerability in your comment system your tape library gets wiped.
    - jacinda 5y ago
      > But all those data sources are connected to from the same runtime, right? Yes, this is an accurate assessment from what I've seen. > And to run it locally you need access to dev versions of all of them. In my experience, no. If the runtime never needs to access it because you're only doing development related to datastore A, it shouldn't fall over just because you haven't configured datastore B. Lots of easy ways to either skip this in the runtime or have a mocked interface. > And when there’s a security vulnerability in your comment system your tape library gets wiped. This one really depends but I think can be an accurate criticism of many systems. It's most true, I think, when you're at an in-between scale where you're big enough to be a target but haven't yet gotten big enough to afford more dedicated security testing at an application code level.
stepbeek 5y ago
I explicitly claim to use a "citadel" archicture [0] when talking about breaking off services for very similar reasons. Having a single microservice split out from a monolith is a totally valid application of microservices, but I've had better results in conversation when I market it properly. I've found this to go so far as to have "monolith" understood to mean "single instance of a system with state held in memory". [0] https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ https://m.signalvnoise.com/the-majestic-monolith-can-become-...
deleted 5y ago
[deleted]
outworlder 5y ago
> Micro services were not an answer to monolith being bad Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.
- actually_a_dog 5y ago
  > Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart. And, this is not necessarily a bad thing.
  - deleted 5y ago
    [deleted]
  - danjac 5y ago
    The problem is that orgs are not set in stone. Teams get merged and split in reorgs, buyouts and mergers happen, suddenly your microservices designed around "cleanly defined boundaries" no longer make any sense. Sure you can write completely new microservices but that is a distraction from delivering value to the end customer.
    - actually_a_dog 5y ago
      So? The solution is that services travel with teams. I've been through more than one reorg. That's what always happens. The point is to have clear ownership and prevent conflicts from too many people working on the same code.
- one2three4 5y ago
  You do that anyway as per Conway's law.
- mbrodersen 5y ago
  Not really. You could do the same by having different organisational units being responsible for different libraries. And the final monolith being minimum glue code combined with N libraries. Basically the same way your code depend on libraries from other vendors/OSS maintainers.
stickfigure 5y ago
My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.
- api 5y ago
  I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. A microservice architecture also tends to lock you into requiring things like Kubernetes, further increasing lock-in to the managed cloud paradigm if not to individual clouds.
  - staticassertion 5y ago
    > I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. Disagree. I'd argue that microservices are inherently more cost effective to scale. By breaking up your services you can deploy them in arbitrary ways, essentially bin packing N microservices onto K instances. When your data volume is light you reduce K and repack your N services. Because your services are broken apart they're easier to move around and you have more fine grained scaling. > further increasing lock-in to the managed cloud paradigm if not to individual clouds. Also disagree. We use Nomad and it's not hard to imagine how we would move to another cloud.
    - nijave 5y ago
      Yeah, the ops side of microservices is important. More granular scaling. Scaling up instances of 8, 16, 32GB or even larger instances is much more expensive than 1,2,4GB instances. In addition, monoliths tend to load slower since there's more code being loaded (so you can't scale up in sub minute times) Obviously there's lazy loading, caching, and other things to speed up application boot but loading more code is still slower
misterbwong 5y ago
Agree. IMO modularity/coupling is the main issue. My issue w/ the microservice architecture is that it solves the modularity problem almost as a side effect of itself but introduces a whole host of new ones that people do not anticipate. Yes, if you, at the outset, say we will separate things into separate services, you will get separated services. However, you do NOT need to take on the extra complexity that comes with communication between services, remote dependency management, and additional infrastructure to reduce coupling.
winternett 5y ago
In my world, the solution depends on the requirement. I can't take all the criticism of each as if they are competition to each other. Also, multiple monolithic (can't stand that word as well) can be applied to distribute resources and data, and to reduce dependencies. Compute, storage, and other services have gotten to the point where they are unlimited, they were originally designed for what was considered monolithic applications. Shared tenancy is not good in the age of multiple dependencies and in terms of security needs for mission-critical applications and data. Cloud host providers got too eager in seeking to create new lines of business and pushed micro-service architectures far too early to maturity, and now we're just beginning to see it's faults, many which can't be fixed without major changes that will likely make them pretty much useless, or alternatively just similar to monolithic architectures anyway. Profit and monopolistic goals shouldn't drive this type of IT innovation, solving critical problems should. We shouldn't just throw away all that we've engineered over the past decade and reinvent the wheel... Heck, many liars are still running FINTECH on COBOL.
- Ialdaboth 5y ago
  > * got too eager in seeking to create new lines of business and pushed * far too early to maturity, and now we're just beginning to see it's faults, many which can't be fixed without major changes that will likely make them pretty much useless Welcome to tech.
LaserToy 5y ago
It is due to shortcuts. It is very hard to keep things modular under the pressure when violating is easy. Micro services make it hard.

by ozim 5y ago

addsidewalk 5y ago

What’s a mono repo of micro services called? We sure spent a lot of time debating semantics for a supposedly economical culture. I tend to focus on stability, correctness, security as those have concrete human meaning. All the rest is jargon largely unhelpful to solving problems. Often helpful selling books, finding “consultant” work, and booking speaking fees though.

ravenstine 5y ago

> monolith was always supposed to be MODULAR from the start Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go. Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it should have the responsibility to handle or is reasonable for one repository to manage. I wish these sorts of battles would just go away, though, because it's not like micro services are actually bad, or even monoliths depending on the situation. They're just different sides of the same coin. A monolith results from not a lot of care for the future of the code and how it's going to be scaled or reused, and micro services are often written because of too much premature optimization. Most things should be a "modular monolith". In fact I think most things should start out as modular monoliths inside monorepos, and then anything that needs to be split out into its own separate library or microservice can be made so later on.

lostcolony 5y ago
No one had to invent the monolith or define how far it should go; it was the default. Microservices came about because companies kept falling into the same trap - that because the code base was shared, and because organizational pressures mean features > tech debt, always, there was always pressure to write spaghetti code rather than to refactor and properly encapsulate. That doesn't mean it couldn't be done, it just meant it was always a matter of time before the business needs meant spaghetti. Microservices, on the other hand, promises enforced separation, which sounds like a good idea once you've been bitten by the pressures of the former. You -can't- fall into spaghetti. What it fails to account for, of course, is the increased operational overhead of deploying all those services and keeping them playing nicely with each other. That's not to say there aren't some actual benefits to them, too (language agnostic, faults can sometimes be isolated), but the purported benefits tend to be exaggerated, especially compared to "a monolith if we just had proper business controls to prevent engineers from feeling like they had to write kluges to deliver features in time".
- Lhiw 5y ago
  > organizational pressures mean features > tech debt, always I wish. Our organisation focuses on building libraries and frameworks. Literally every solution is a new library. Products take months to ship because you have to either make a new version of a library because the old version wasnt really expecting to work with your needs, or you need to refactor your existing libraries to work with new needs, that takes months of refactoring all the usage points. It's nuts. I tried to build a completely new thing recently, got told to build a library. My thing is pretty specific, doesn't need a library, and will just be single use. It will consume lots of libraries. Would have taken about a week to ship. Instead, here we are week 4 still figuring out how to make this pile of shit work. Sometimes I wish people would just build abstractions on top of what we have. Not everything needs to be a library, sometimes, your new product code is all you need to solve a problem.
- spc476 5y ago
  The individual code bases of a microservice might not involve spaghetti code, but the interconnections certain can. I'm looking at a diagram of the service I work on, with seven components (written in three languages), five databases, 25 internal connections, two external interfaces, and three connections to outside databases, all cross-wired (via 6 connections) with a similar setup geographically elsewhere in case we need to cut over. And that's the simplified diagram, not showing the number of individual instances of each component running. There is clear separation of concerns among all the components, but it's the interconnections between them that take a while to pick up on.

jhgb 5y ago

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Isn't "non-modular monolith" just spaghetti code? The way I understand it, "modular monolith" is just "an executable using libraries". Or is it supposed to mean something different?

falcor84 5y ago
The way I see it, spaghetti code is actually a very wide spectrum, with amorphic goto-based code on one end, and otherwise well structured code, but with too much reliance on global singletons on the other (much more palatable) end. While by definition spaghetti code is not modular, modularity entails more. I would define modularity as an explicit architectural decision to encapsulate some parts of the codebase such that the interfaces between them change an order of magnitude less frequently than what's within the modules.

rco8786 5y ago

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Yes! Thank you. The "modular monolith" is just "decent separation of concerns in your code" and should be there from the start.

sbysb 5y ago
I would actually disagree - to me you can have "decent separation of concerns in your code" but still have only built the app to support a single entry point. "Modular monolith" to me is a system that is built with the view of being able to support multiple entry points, which is a bit more complex than just "separating concerns"
- zbentley 5y ago
  If your concerns are well separated in a monolith (in practice this means being able to call a given piece of functionality with high confidence that it will only talk to the data stores/external resources that you expect it will), adding new entry points is very easy. Now, it's not trivial--going from, say, a do-everything webserver host to a separation of route-family-specific web servers, background job servers, report processing hosts, and cron job runners does require work no matter how you slice it--but it's a more or less a mechanical or "plumbing" problem if you start from a monolithic codebase that is already well behaved. Modularity is one significant part of said good behavior.

SkyPuncher 5y ago

> Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Unless you're in a large established org, modulatity is likely a counter-goal. Most startups are looking to iterate quickly to find pre-PMF. Unless you write absolutely terrible code, my experience is you're more likely to have the product cycle off a set functionality before you truly need modularity. From there, you either (1) survive long enough to make an active decision to change how you work (2) you die and architecture doesn't matter. "Modular monolith" is a nice framing for teams who are at that transition point.

jameshart 5y ago

The interesting thing about microservices is not that it lets you split up your code on module boundaries. Obviously you can (and should!) do that inside any codebase. The thing about microservices is that it breaks up your data and deployment on module boundaries. Monoliths are monoliths not because they lack separation of concerns in code (something which lacks that is not a ‘monolith’, it is what’s called a ‘big ball of mud’) Monoliths are monoliths because they have - one set of shared dependencies - one shared database - one shared build pipeline - one shared deployment process - one shared test suite - one shared entrypoint As organizations and applications get larger these start to become liabilities. Microservices are part of one solution to that (not a whole solution; not the only one).

Retric 5y ago
Monoliths don’t actually look like that at scale. For example you can easily have multiple different data stores for different reasons, including multiple different kinds of databases. Here’s this tiny little internal relational database used internally, and there’s the giant tape library that’s archiving all this scientific data we actually care about. Here’s the hard real time system, and over there’s the billing data etc etc. The value of a monolith is it looks like a single thing from outside that does something comprehensible, internally it still needs to actually work.
- jameshart 5y ago
  But all those data sources are connected to from the same runtime, right? And to run it locally you need access to dev versions of all of them. And when there’s a security vulnerability in your comment system your tape library gets wiped.
  - jacinda 5y ago
    > But all those data sources are connected to from the same runtime, right? Yes, this is an accurate assessment from what I've seen. > And to run it locally you need access to dev versions of all of them. In my experience, no. If the runtime never needs to access it because you're only doing development related to datastore A, it shouldn't fall over just because you haven't configured datastore B. Lots of easy ways to either skip this in the runtime or have a mocked interface. > And when there’s a security vulnerability in your comment system your tape library gets wiped. This one really depends but I think can be an accurate criticism of many systems. It's most true, I think, when you're at an in-between scale where you're big enough to be a target but haven't yet gotten big enough to afford more dedicated security testing at an application code level.

stepbeek 5y ago

I explicitly claim to use a "citadel" archicture [0] when talking about breaking off services for very similar reasons. Having a single microservice split out from a monolith is a totally valid application of microservices, but I've had better results in conversation when I market it properly. I've found this to go so far as to have "monolith" understood to mean "single instance of a system with state held in memory". [0] https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ https://m.signalvnoise.com/the-majestic-monolith-can-become-...

deleted 5y ago

[deleted]

outworlder 5y ago

> Micro services were not an answer to monolith being bad Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart.

actually_a_dog 5y ago
> Micro services today are mostly used for one purpose: to be able to ship your corporation's org chart. And, this is not necessarily a bad thing.
- deleted 5y ago
  [deleted]
- danjac 5y ago
  The problem is that orgs are not set in stone. Teams get merged and split in reorgs, buyouts and mergers happen, suddenly your microservices designed around "cleanly defined boundaries" no longer make any sense. Sure you can write completely new microservices but that is a distraction from delivering value to the end customer.
  - actually_a_dog 5y ago
    So? The solution is that services travel with teams. I've been through more than one reorg. That's what always happens. The point is to have clear ownership and prevent conflicts from too many people working on the same code.
one2three4 5y ago
You do that anyway as per Conway's law.
mbrodersen 5y ago
Not really. You could do the same by having different organisational units being responsible for different libraries. And the final monolith being minimum glue code combined with N libraries. Basically the same way your code depend on libraries from other vendors/OSS maintainers.

stickfigure 5y ago

My theory is that microservices became vogue along with dynamically typed languages. Lack of static types means that code becomes unmanageable at a much lower level of complexity. So the complexity was "moved to the network", which looks like a clear win if you never look outside a single component.

api 5y ago
I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. A microservice architecture also tends to lock you into requiring things like Kubernetes, further increasing lock-in to the managed cloud paradigm if not to individual clouds.
- staticassertion 5y ago
  > I've wondered if it's not a ploy by cloud vendors and the ecosystem around them to increase peoples' cloud bills. Not only do you end up using many times more CPU but you end up transferring a lot of data between availability zones, and many clouds bill for that. Disagree. I'd argue that microservices are inherently more cost effective to scale. By breaking up your services you can deploy them in arbitrary ways, essentially bin packing N microservices onto K instances. When your data volume is light you reduce K and repack your N services. Because your services are broken apart they're easier to move around and you have more fine grained scaling. > further increasing lock-in to the managed cloud paradigm if not to individual clouds. Also disagree. We use Nomad and it's not hard to imagine how we would move to another cloud.
  - nijave 5y ago
    Yeah, the ops side of microservices is important. More granular scaling. Scaling up instances of 8, 16, 32GB or even larger instances is much more expensive than 1,2,4GB instances. In addition, monoliths tend to load slower since there's more code being loaded (so you can't scale up in sub minute times) Obviously there's lazy loading, caching, and other things to speed up application boot but loading more code is still slower

misterbwong 5y ago

Agree. IMO modularity/coupling is the main issue. My issue w/ the microservice architecture is that it solves the modularity problem almost as a side effect of itself but introduces a whole host of new ones that people do not anticipate. Yes, if you, at the outset, say we will separate things into separate services, you will get separated services. However, you do NOT need to take on the extra complexity that comes with communication between services, remote dependency management, and additional infrastructure to reduce coupling.

winternett 5y ago

In my world, the solution depends on the requirement. I can't take all the criticism of each as if they are competition to each other. Also, multiple monolithic (can't stand that word as well) can be applied to distribute resources and data, and to reduce dependencies. Compute, storage, and other services have gotten to the point where they are unlimited, they were originally designed for what was considered monolithic applications. Shared tenancy is not good in the age of multiple dependencies and in terms of security needs for mission-critical applications and data. Cloud host providers got too eager in seeking to create new lines of business and pushed micro-service architectures far too early to maturity, and now we're just beginning to see it's faults, many which can't be fixed without major changes that will likely make them pretty much useless, or alternatively just similar to monolithic architectures anyway. Profit and monopolistic goals shouldn't drive this type of IT innovation, solving critical problems should. We shouldn't just throw away all that we've engineered over the past decade and reinvent the wheel... Heck, many liars are still running FINTECH on COBOL.

Ialdaboth 5y ago
> * got too eager in seeking to create new lines of business and pushed * far too early to maturity, and now we're just beginning to see it's faults, many which can't be fixed without major changes that will likely make them pretty much useless Welcome to tech.

LaserToy 5y ago

It is due to shortcuts. It is very hard to keep things modular under the pressure when violating is easy. Micro services make it hard.