3 ms·

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,

by 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.
  - thrashh 5y ago
    IMO the only reason why people run into trouble is because they code as if everything completes instantly. For example, they’ll write to disk assuming the operation is quick, because that’s what they’re used to. You see this all the time in all sorts of software when it freezes up and errors cascade. People just code like everything works all the time. Then when they want to integrate an external service, they have to rewrite everything. If you understand that network calls have to made and electrical signals have to pass down a bus when you write either a monolith or a microservice, going back and swapping services is super easy.
  - tomnipotent 5y ago
    > Take a email/notification service being part of monolith The only extra work is updating the monolith to call the extracted service, which isn't that hard.

by Youden 5y ago

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.
- thrashh 5y ago
  IMO the only reason why people run into trouble is because they code as if everything completes instantly. For example, they’ll write to disk assuming the operation is quick, because that’s what they’re used to. You see this all the time in all sorts of software when it freezes up and errors cascade. People just code like everything works all the time. Then when they want to integrate an external service, they have to rewrite everything. If you understand that network calls have to made and electrical signals have to pass down a bus when you write either a monolith or a microservice, going back and swapping services is super easy.
- tomnipotent 5y ago
  > Take a email/notification service being part of monolith The only extra work is updating the monolith to call the extracted service, which isn't that hard.