4 ms·

One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be

One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.

dragonwriter 3y ago
I disagree that this is the case; decomposing into microservices doesn’t mean that the functionality within a service boundary is trivial and easy to rewrite.
- bheadmaster 3y ago
  Of course, there's a whole continuum of complexity between microservices and monoliths in real life. Much of that continuum is labeled as "microservices". I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.
anotherhue 3y ago
That assumes the service is doing something generic enough to be trivial in any language, in which case, why not just choose one? It's like we're advocating for the outcome of the Tower of Babel tale.
- zerbinxx 3y ago
  I mean, ultimately most languages and frameworks are/should be at least intelligible and serviceable by your teammates. I’ve both been on teams where I cannot work on Jerry’s Fucking Insanity Factory API after he leaves even though it’s written in JS and I know JS, but this is some insane Rube Goldberg machine that only Jerry’s mind understands, I’ve also been on teams where someone will write their thing in Go or Rust and I don’t know those but I can at least maintain them, because they’re well abstracted and do nice things and their authors were not schizophrenic like Jerry
ohgodplsno 3y ago
One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten. Micro services replace your unmaintainable bean injection XML abomination with 50 reimplementations of database access and a salary for the one guy who knows his to make your kubernetes setup work. It's not a technology problem, it's a people problem. Micro services make it a distributed people problem.
- bheadmaster 3y ago
  > One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten I... I don't really understand this sentence.
  - floydnoel 3y ago
    probably because you are replying to a quote of a quote, but didn't read the quoted comment? spend more time reading and less time writing would be my suggestion to help with understanding the comments here.
    - dragonwriter 3y ago
      > probably because you are replying to a quote of a quote Its not a quote of a quote, its an attempt at a mocking modification of an upthread comment that isn’t a quote, but the original doesn’t fix the incoherence of the mocking reply.
    - bheadmaster 3y ago
      I wrote the quoted comment. You'd probably notice that if you were to spend more time reading and less time writing.
  - scott_w 3y ago
    He’s mocking you
The_Colonel 3y ago
My (small) team spent a year rewriting one simple clojure/mongo CRUD microservice into Java/Postgres. The process was anything but easy. Interestingly, even a simple CRUD can be made in a complex way in Clojure which makes it difficult to understand for non-clojure devs. Data migration path is also a huge issue (and the major reason it took so long). I believe the original service took 6 months to develop (including all iterations of the design/spec), a "simple" 1:1 rewrite a double of that.
codedokode 3y ago
That would be extremely irrational, to throw away money spent on designing, developing, testing, benchmarking, optimizing, debugging weird bugs, fixing that service just because you like another language.

One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.

dragonwriter 3y ago

I disagree that this is the case; decomposing into microservices doesn’t mean that the functionality within a service boundary is trivial and easy to rewrite.

bheadmaster 3y ago
Of course, there's a whole continuum of complexity between microservices and monoliths in real life. Much of that continuum is labeled as "microservices". I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.

anotherhue 3y ago

That assumes the service is doing something generic enough to be trivial in any language, in which case, why not just choose one? It's like we're advocating for the outcome of the Tower of Babel tale.

zerbinxx 3y ago
I mean, ultimately most languages and frameworks are/should be at least intelligible and serviceable by your teammates. I’ve both been on teams where I cannot work on Jerry’s Fucking Insanity Factory API after he leaves even though it’s written in JS and I know JS, but this is some insane Rube Goldberg machine that only Jerry’s mind understands, I’ve also been on teams where someone will write their thing in Go or Rust and I don’t know those but I can at least maintain them, because they’re well abstracted and do nice things and their authors were not schizophrenic like Jerry

ohgodplsno 3y ago

One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten. Micro services replace your unmaintainable bean injection XML abomination with 50 reimplementations of database access and a salary for the one guy who knows his to make your kubernetes setup work. It's not a technology problem, it's a people problem. Micro services make it a distributed people problem.

bheadmaster 3y ago
> One of the pros of monoliths is that each individual functionality it provides is so simple that it doesn't need to be rewritten I... I don't really understand this sentence.
- floydnoel 3y ago
  probably because you are replying to a quote of a quote, but didn't read the quoted comment? spend more time reading and less time writing would be my suggestion to help with understanding the comments here.
  - dragonwriter 3y ago
    > probably because you are replying to a quote of a quote Its not a quote of a quote, its an attempt at a mocking modification of an upthread comment that isn’t a quote, but the original doesn’t fix the incoherence of the mocking reply.
  - bheadmaster 3y ago
    I wrote the quoted comment. You'd probably notice that if you were to spend more time reading and less time writing.
- scott_w 3y ago
  He’s mocking you

The_Colonel 3y ago

My (small) team spent a year rewriting one simple clojure/mongo CRUD microservice into Java/Postgres. The process was anything but easy. Interestingly, even a simple CRUD can be made in a complex way in Clojure which makes it difficult to understand for non-clojure devs. Data migration path is also a huge issue (and the major reason it took so long). I believe the original service took 6 months to develop (including all iterations of the design/spec), a "simple" 1:1 rewrite a double of that.

codedokode 3y ago

That would be extremely irrational, to throw away money spent on designing, developing, testing, benchmarking, optimizing, debugging weird bugs, fixing that service just because you like another language.