6 ms·

> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. A

> It is extremely difficult to change a monolith’s technology or language or framework because all components are tightly coupled and dependent on each other. As a result, even relatively small changes can require lengthy development and deployment times. I disagree with this so much. I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure. I would take a properly structured monolith any day. This not only includes code/features but also deployments. Adding more services introduces more complexity in the deployment architecture as well. A good example of this is just by looking at the GitLab codebase https://gitlab.com/gitlab-org/gitlab https://gitlab.com/gitlab-org/gitlab, it's a monolith but has good abstractions/structure vs say the Google Microservices Demo app https://github.com/GoogleCloudPlatform/microservices-demo https://github.com/GoogleCloudPlatform/microservices-demo which is not tightly coupled but introduces more complexity from implementation to deployment.

qaq 5y ago
It's obvious BS driven by cloud marketing because in monolith case you pay them for way fewer services. In Micro Services case a single client request will generate a number of downstream requests to multiple services driving the cloud provider's profits up. You also have a higher chance of using their highest margin tracing/telemetry offerings.
- da39a3ee 5y ago
  Not sure whether you just meant that as humorous cynicism, but I think it has more to do with pain experienced by teams working on monoliths and them thinking “there has to be a better way”.
  - qaq 5y ago
    It's orders of magnitude easier to architect modular monolith than to build, test, deploy and manage a distributed system (e.g. microservices).
    - ehnto 5y ago
      Well made modularity gets you many of the same benefits as microservices, without any of the deployment complexity. The articles argument about changing architecture and language being difficult seems like a red herring, because you shouldn't want to be changing architecture or language particularly frequently. I'd really wager that you should be building your code to last the full life of the product from the start, with adaptability to changing scope and requirements being delivered by that modularity. You of course don't always know the full scope of the project from day one, so you don't typically build software like you would build a bridge, with a fully holistic plan. But you can totally account for the future when you initial build a monolith.
mrighele 5y ago
> technology or language or framework Note what they are talking about. They are right: of course if you want to change your Rails monolith to a Spring Boot java project it will be extremely difficult. The point is, how often do you want to do that ? Maybe in google it happens often, but for most smaller companies that is "very rarely"
KronisLV 5y ago
> Adding more services introduces more complexity in the deployment architecture as well. This is true, but having multiple services or even instances that can horizontally scale gives you more leeway as far as resiliency against errors goes. For example, the issues in the monolith at my current day job could have a way lower priority/impact, if they didn't risk bringing down the entire application should the application server/instance fail - instead, if there were N instances, the load could just be handled by the other instances. Actually, one of my first blog posts talks about how scalable and modular monoliths might be a way to leverage the best of both worlds: https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services https://blog.kronis.dev/articles/modulith-because-we-need-to... Of course, if you actually have the operational capacity to support microservices, that may be a good investment in some particular systems - if a part of the whole system would start to misbehave, its impact could be far more limited, for example, due to resource constraints or rate limits that should be in place. Monitoring could also become somewhat easier and you could figure out where any problem lies, except for the most complex Byzantine failures. > I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure. However, where monoliths fail in my eyes, is the strong coupling. For example, i currently need to migrate the very same monolith to far newer frameworks and runtimes, which is essentially impossible to ship, because a large number of edge cases and specific functionality all break when this is done. So instead of being able to ship the parts that'd work (say, the RESTful API and the front end), i'm blocked by the things that don't work (report functionality, PDF functionality, file handling functionality, database migration functionality), so for approx. the past month it has probably looked like i'm not generating much business value, due to struggling with all of this. I wrote more about the problems with this here on HN: https://news.ycombinator.com/item?id=29204841 https://news.ycombinator.com/item?id=29204841
Youden 5y ago
I think you missed the "technology or language or framework" part. Their argument is that if you have a monolith and want to say move from Ruby to TypeScript, you basically have to rewrite the whole thing and migrate in one go, which is a massive pain. If you have microservices and want to do the same, you can move one service at a time.
- necovek 5y ago
  But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trickier, but they'd be tricky anyway (eg. if you want to move user management APIs which tie into privilege handling, it's going to be finicky no matter how you slice it). The main driver for SOA (and microservices by extension) is to allow independent iteration of components by independent teams. On small teams, it's usually not a win at all because you introduce a lot of overhead and you need to really be on point regarding backwards compatibility (or statelessness) and API specs. Sure, monoliths do allow unrestricted use of (a particular set of) suboptimal patterns, but I've seen one too many "microservices" which have "custom" protocols that are only ever changed in sync on both sides of the microservice (server and clients).
  - blackoil 5y ago
    It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.
    - necovek 5y ago
      Depends on how it's structured in the monolith. If it's well encapsulated — eg. one API call to trigger a notification that goes to a job-runner which sends the actual notification, which is the standard way of doing these in the monoliths I've seen — it's going to be similarly simple/hard. But that was exactly my point: how hard it is depends on the code structure that has no relationship to whether you are in a SOA or a monolith architecture. Sure, some (bad) patterns are hard in SOA which are trivial in a monolith, but they are bad patterns regardless. What matters is that you replace bad patterns with good patterns.

qaq 5y ago

It's obvious BS driven by cloud marketing because in monolith case you pay them for way fewer services. In Micro Services case a single client request will generate a number of downstream requests to multiple services driving the cloud provider's profits up. You also have a higher chance of using their highest margin tracing/telemetry offerings.

da39a3ee 5y ago
Not sure whether you just meant that as humorous cynicism, but I think it has more to do with pain experienced by teams working on monoliths and them thinking “there has to be a better way”.
- qaq 5y ago
  It's orders of magnitude easier to architect modular monolith than to build, test, deploy and manage a distributed system (e.g. microservices).
  - ehnto 5y ago
    Well made modularity gets you many of the same benefits as microservices, without any of the deployment complexity. The articles argument about changing architecture and language being difficult seems like a red herring, because you shouldn't want to be changing architecture or language particularly frequently. I'd really wager that you should be building your code to last the full life of the product from the start, with adaptability to changing scope and requirements being delivered by that modularity. You of course don't always know the full scope of the project from day one, so you don't typically build software like you would build a bridge, with a fully holistic plan. But you can totally account for the future when you initial build a monolith.

mrighele 5y ago

> technology or language or framework Note what they are talking about. They are right: of course if you want to change your Rails monolith to a Spring Boot java project it will be extremely difficult. The point is, how often do you want to do that ? Maybe in google it happens often, but for most smaller companies that is "very rarely"

KronisLV 5y ago

> Adding more services introduces more complexity in the deployment architecture as well. This is true, but having multiple services or even instances that can horizontally scale gives you more leeway as far as resiliency against errors goes. For example, the issues in the monolith at my current day job could have a way lower priority/impact, if they didn't risk bringing down the entire application should the application server/instance fail - instead, if there were N instances, the load could just be handled by the other instances. Actually, one of my first blog posts talks about how scalable and modular monoliths might be a way to leverage the best of both worlds: https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services https://blog.kronis.dev/articles/modulith-because-we-need-to... Of course, if you actually have the operational capacity to support microservices, that may be a good investment in some particular systems - if a part of the whole system would start to misbehave, its impact could be far more limited, for example, due to resource constraints or rate limits that should be in place. Monitoring could also become somewhat easier and you could figure out where any problem lies, except for the most complex Byzantine failures. > I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure. However, where monoliths fail in my eyes, is the strong coupling. For example, i currently need to migrate the very same monolith to far newer frameworks and runtimes, which is essentially impossible to ship, because a large number of edge cases and specific functionality all break when this is done. So instead of being able to ship the parts that'd work (say, the RESTful API and the front end), i'm blocked by the things that don't work (report functionality, PDF functionality, file handling functionality, database migration functionality), so for approx. the past month it has probably looked like i'm not generating much business value, due to struggling with all of this. I wrote more about the problems with this here on HN: https://news.ycombinator.com/item?id=29204841 https://news.ycombinator.com/item?id=29204841

Youden 5y ago

I think you missed the "technology or language or framework" part. Their argument is that if you have a monolith and want to say move from Ruby to TypeScript, you basically have to rewrite the whole thing and migrate in one go, which is a massive pain. If you have microservices and want to do the same, you can move one service at a time.

necovek 5y ago
But that ain't true either. You can even move from one monolith to the other. Eg. a single DB store, and you just move a set of APIs (this set of APIs live in Ruby monolith, and it can talk to TypeScript monolith). Just put a reverse proxy in front (which you're likely to already run), and route requests to the proper service. Sure, some things will be trickier, but they'd be tricky anyway (eg. if you want to move user management APIs which tie into privilege handling, it's going to be finicky no matter how you slice it). The main driver for SOA (and microservices by extension) is to allow independent iteration of components by independent teams. On small teams, it's usually not a win at all because you introduce a lot of overhead and you need to really be on point regarding backwards compatibility (or statelessness) and API specs. Sure, monoliths do allow unrestricted use of (a particular set of) suboptimal patterns, but I've seen one too many "microservices" which have "custom" protocols that are only ever changed in sync on both sides of the microservice (server and clients).
- blackoil 5y ago
  It is possible but not as simple as you suggest. Take a email/notification service being part of monolith, changing that to a new language / arch. is lot more complex then a similar micro-service connected via Kafka/GRPC.
  - necovek 5y ago
    Depends on how it's structured in the monolith. If it's well encapsulated — eg. one API call to trigger a notification that goes to a job-runner which sends the actual notification, which is the standard way of doing these in the monoliths I've seen — it's going to be similarly simple/hard. But that was exactly my point: how hard it is depends on the code structure that has no relationship to whether you are in a SOA or a monolith architecture. Sure, some (bad) patterns are hard in SOA which are trivial in a monolith, but they are bad patterns regardless. What matters is that you replace bad patterns with good patterns.