Comment by jokethrowaway | Hacker News Reader

Comment by jokethrowaway | Hacker News Reader

Parent Full thread

I've been through similar transformation (just 250 microservices) and I'm not sure the end result was actually better. Microservices are ok if things go well and you can maintain a large army of developers - which you didn't really need in the first place.

In my case: Fast forward 5 years and the business growth didn't materialize; the board made working in the content unpleasant enough so that all the good and expensive developers left and outsourced the rest to India. These poor contractors have to deal with 20 microservices per team (while we were juggling 5-10, already to much, I think 1-2 services per team).

The old monolith were fine. Microservices - and transitions to new languages - create a lot of new problems (performance of joins over network, rabbitmq dead letters handling, services ddosing each others, updating a shared library and having to bump it in every service in the entire company)

I feel like it was basically spinning wheels.

For what it's worth, what you are describing is a pretty well known failure mode. It was known in the days of CORBA and DCOM, and then again in the days of SOAP web services. Microservices as a distributed monolith is not how you partition things if you want to gain productivity and be successful. Literally everything you mention other than updating shared libraries are problems that our team does not have and yet we have around 100 autonomous back end components and over 20 web applications maintained with a team of around 15. We've never felt like there were too many, because usually you don't have to touch most of them. You only have to touch the one or ones that are relevant to your work.

Imagine eliminating network joins (make sure all the data is where it needs to be and/or share a database for reads, which is totally doable)... and eliminating dead letter queues (make sure your service goes offline/retries indefinitely if there is a failure and fix it. Don't tolerate failures. See jidoka)... and don't let services talk to each other (see pub/sub and event sourcing). Oh, and also limit the number of times updating a single library must be applied to all services by getting things as close to right as you can and respecting the physics of software design (see afference and efference).

Reply on news.ycombinator.com