4 ms·

Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right languag

Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.

bheadmaster 3y ago
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.
wizofaus 3y ago
Are there actually many real-life examples of large-scale microservices architecture operating successfully with a range of different languages in use? I did (briefly) work at such a shop, I can't say the experience was particularly rewarding, but I was expected to be on top of ALL said languages/stacks and their various idiosyncrasies etc., and much of the code was pretty poorly written. Arguably the biggest challenge was maintaining the build system!
- anotherhue 3y ago
  I haven't heard of any, the classic 'allowed languages' pages of tech companies come to mind. "You build it you run it", until the OCaml guy quits and now you need to support OCaml.
  - scott_w 3y ago
    I do recall speaking to people at a betting company many moons ago who tried to recruit me with the claim they were so open with microservices that they had a key system written in Erlang that only one engineer in the company understood. I politely explained my position on why that seemed suboptimal.
    - lozenge 3y ago
      That's good, when I had to consume their API it was closer to zero engineers who understood it.
- jamesfinlayson 3y ago
  I've worked at a place where it was a case of choose what you want - there's lots of C#, Python and Javascript, some Go but there's still Scala and CoffeeScript lurking around, as well as some other more esoteric stuff that seemed like a good idea at the time.
  - wizofaus 3y ago
    Would you describe it as a "large-scale microservices architecture operating successfully" though?
88913527 3y ago
Most (successful) paths lead to balkanization. Just one acquisition can do it, much less 2 or N more. And the pace of these changes can outpace your ability to respond to it, which makes fighting it a losing battle.
- The_Colonel 3y ago
  Yes, it is inevitable at some level, but supporting 2 different stacks (result from acquisition) is better than 20 (result from "pick the best tool for the job" culture).
  - deleted 3y ago
    [deleted]
- danjac 3y ago
  That's a "nice to have" problem down the line. What I've seen is the insanity of microservices being adopted by one-pizza-team startups.
  - StackOverlord 3y ago
    Been there, except I was the pizza being eaten by 5 microservices.

bheadmaster 3y ago

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.

wizofaus 3y ago

Are there actually many real-life examples of large-scale microservices architecture operating successfully with a range of different languages in use? I did (briefly) work at such a shop, I can't say the experience was particularly rewarding, but I was expected to be on top of ALL said languages/stacks and their various idiosyncrasies etc., and much of the code was pretty poorly written. Arguably the biggest challenge was maintaining the build system!

anotherhue 3y ago
I haven't heard of any, the classic 'allowed languages' pages of tech companies come to mind. "You build it you run it", until the OCaml guy quits and now you need to support OCaml.
- scott_w 3y ago
  I do recall speaking to people at a betting company many moons ago who tried to recruit me with the claim they were so open with microservices that they had a key system written in Erlang that only one engineer in the company understood. I politely explained my position on why that seemed suboptimal.
  - lozenge 3y ago
    That's good, when I had to consume their API it was closer to zero engineers who understood it.
jamesfinlayson 3y ago
I've worked at a place where it was a case of choose what you want - there's lots of C#, Python and Javascript, some Go but there's still Scala and CoffeeScript lurking around, as well as some other more esoteric stuff that seemed like a good idea at the time.
- wizofaus 3y ago
  Would you describe it as a "large-scale microservices architecture operating successfully" though?

88913527 3y ago

Most (successful) paths lead to balkanization. Just one acquisition can do it, much less 2 or N more. And the pace of these changes can outpace your ability to respond to it, which makes fighting it a losing battle.

The_Colonel 3y ago
Yes, it is inevitable at some level, but supporting 2 different stacks (result from acquisition) is better than 20 (result from "pick the best tool for the job" culture).
- deleted 3y ago
  [deleted]
danjac 3y ago
That's a "nice to have" problem down the line. What I've seen is the insanity of microservices being adopted by one-pizza-team startups.
- StackOverlord 3y ago
  Been there, except I was the pizza being eaten by 5 microservices.