Hacker News Reader

Comment by anotherhue | Hacker News Reader

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.

View on HN

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.

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).

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.

Been there, except I was the pizza being eaten by 5 microservices.

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!

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.

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.

That's good, when I had to consume their API it was closer to zero engineers who understood it.

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.

Would you describe it as a "large-scale microservices architecture operating successfully" though?

Yes and no - it definitely runs and makes a lot of money, but sometimes things mysteriously go wrong and no one quite knows why (service x is running slowly because service y is running slowly because service z is running slowly and no one knows why service z is running slowly), and it's reached a point where most new work is done in yet another microservice, so headcount keeps slowly growing (usually throwing more offshore contractors at it) to deal with the problem.

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.

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.

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

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.

> 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.

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.

> 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.

I wrote the quoted comment.

You'd probably notice that if you were to spend more time reading and less time writing.

He’s mocking you

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.

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.

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.

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.

Reply on news.ycombinator.com