Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make microservices look like monoliths

github.com

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Make microservices look like monoliths

#71

Post by [deleted] »

ranting-moth wrote: post #30
mabbo wrote: post #15

Earlier quoted context omitted.

I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!). I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made. If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Owne…

> Monoliths require alignment. So do microservices.

[deleted]

Re: Make microservices look like monoliths

#72

Post by The_Colonel »

88913527 wrote: post #52
anotherhue wrote: post #18

Earlier quoted context omitted.

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.

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

Re: Make microservices look like monoliths

#73

Post by azangru »

There are a couple of relevant recent talks on the subject:

- Top 5 techniques for building the worst microservice system ever - William Brander - NDC London 2023 (https://www.youtube.com/watch?v=88_LUw1Wwe4)

- Don’t Build a Distributed Monolith - Jonathan Tower - NDC London 2023 (https://www.youtube.com/watch?v=p2GlRToY5HI)

Re: Make microservices look like monoliths

#74

Post by The_Colonel »

bheadmaster wrote: post #22
anotherhue wrote: post #18

Earlier quoted context omitted.

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.

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.

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.

Re: Make microservices look like monoliths

#75

Post by [deleted] »

The_Colonel wrote: post #72
88913527 wrote: post #52

Earlier quoted context omitted.

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

[deleted]

Re: Make microservices look like monoliths

#77

Post by ilyt »

zerbinxx wrote: post #53
spicybright wrote: post #36

Earlier quoted context omitted.

I think GP's point on company culture is the right answer. My only thoughts to add is monoliths can be aligned as well as microservices, if not a bit easier depending on the team. You have to align microservices to talk to each other anyways, and there's no reason you can't make those boundaries work in one codebase instead of many. That said ownership is more important in a monolith, whether that be a single team of…

The worst thing is the many-monoliths/mini-monoliths problem that you get when each team thinks it has ultra special needs and absolutely must build everything from scratch, even if it’s a near duplicate of something someone else built 2 months ago.

building from scratch instead of using something that already fits pretty well is orthogonal to discussion as it happens both in monolith and microservices

Re: Make microservices look like monoliths

#78

Post by ketzu »

azangru wrote: post #73

There are a couple of relevant recent talks on the subject: - Top 5 techniques for building the worst microservice system ever - William Brander - NDC London 2023 ( https://www.youtube.com/watch?v=88_LUw1Wwe4 ) - Don’t Build a Distributed Monolith - Jonathan Tower - NDC London 2023 ( https://www.youtube.com/watch?v=p2GlRToY5HI )

It is such a weird feeling to come across a topic I haven't read on in a while, watch two videos on it out of random curiosity, hop on hackernews the next day, and get a recommendation for the exact same videos.

I very much enjoyed the 5 techniques and many of the tidbits. I also liked "Avoiding Microservice Megadisasters" but mostly for the entertainment value (https://www.youtube.com/watch?v=gfh-VCTwMw8)

Re: Make microservices look like monoliths

#79

Post by haspok »

So you are trying to build Erlang without Erlang and OTP. Nice try :) You are maybe 5% there. How about the rest? Error handling, handling network issues, latency, partitions, deployments, scaling etc...

I would also argue that because of the async calls (NodeJS is single-threaded, right?) you can easily run into weird and unexpected issues where two sequential service calls return out of order (which is impossible if they are just method calls, but very likely if they are sent over the network). How do you handle these cases? Do you just block on each call over the network and hope for the best?

Re: Make microservices look like monoliths

#80

Post by codedokode »

bheadmaster wrote: post #22
anotherhue wrote: post #18

Earlier quoted context omitted.

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.

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 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.
Post reply on HN