Ask HN: Why the hatred towards Microservices?

Why the hatred towards Microservices?

It's just where they are on the Fad Cycle. Nothing more, nothing less. New ideas come into vogue in this industry, get hailed and cherished and promoted left and right, then they lose favor, fall into disrepute, and start getting hated on with just as much fervor as they had previously been hailed. Then some new thing (or a repeat of an older idea that's being rehashed for another run through the cycle) hits, and the cycle starts anew. Lather, rinse, repeat.

Are microservices inherently bad

No.

would you enjoy working with them?

Quite often, yes. But like everything else, it's all about context. "Use the right tool for the job at hand" and all that.

Do you think, honestly, that it is just a trend that comes from the big companies and book sellers and eventually will dissapear and there is no a real need for it for the vast majority of cases?

I do think there's an element of that. Ideas that hit the "fad cycle" mentioned above do often get carried there by momentum which comes from their association with popular organizations, and then get misapplied or used when they aren't really needed. That in turn feeds into the back half of the cycle where people turn against $THING.

+1

Basically due to the Fad Cycle, microservices have turned from "useful for niche special cases" to "MUST DO AT ALL TIMES" and become a massive net-negative, similar to OOP. Thus the public sentiment is now that they are bad, although the original niche special cases still warrant their use.

Microservices just add a lot of overhead to development and infrastructure that is likely completely unnecessary.

Even in well run projects, over time stuff evolves and the new services have a new build pipeline and the old ones still use the old pipeline and now you have to maintain both and understand how to use both every day.

Monoliths sidestep a lot of problems like that imo. They have their own issues so it's definitely a tradeoff, but still. Overall I find microservice architectures much, much harder to work with.

I used to work at Pex, where microservices were done beautifully.

Pex's microservice architecture scaled tremendously. Their product crawls and processes all the audio and video produced on the entire internet in near-real-time.

> Are microservices inherently bad or your criticism might come from a terrible implementation you've had to suffer?

Microservices are not inherently bad.

> In an ideal scenario where said implementation and architecture is well designed and robust, would you enjoy working with them?

I think Pex's microservice architecture was as good as it gets... and I decided that I wanted to avoid distributed systems for the rest of my life haha

> Do you think, honestly, that it is just a trend that comes from the big companies and book sellers and eventually will dissapear and there is no a real need for it for the vast majority of cases?

Microservices seem to be great for giant backbone/infrastructure stuff like Netflix, AWS, Pex, Cloudflare, Squarespace, etc.

Sometime managers shout "conway's law" and decide they need hard network boundaries. I'm unsure what to tell those teams.

Many engineers trick themselves into thinking that their company is special and needs the extra scalability or whatever, when it's simply not true. If your problem can be solved by load balancers or caching or DB indexes, you are not even close to needing microservices.

In my experience, monoliths seem to be the right choice for 99% of cases.

>I used to work at Pex, where microservices were done beautifully.

Would love to read about this architecture. Is there a blog post you can link to?

>If your problem can be solved by load balancers or caching or DB indexes, you are not even close to needing microservices.

It's funny, do people not know about this stuff anymore? It's the low hanging fruit for scalability.

> Would love to read about this architecture. Is there a blog post you can link to?

I don't think they have any blog posts about it, but the CEO/architect doggedly pursued simplicity.

There was a single pub-sub messaging bus and a bunch of VMs in autoscaling groups. There were 2 databases optimized for different workloads. That's pretty much it.

> It's funny, do people not know about this stuff anymore? It's the low hanging fruit for scalability.

People tend to diagnose themselves with "special" diseases, whose treatments won't work for "common folk" :) I've done it myself plenty of times haha

Not sure 'hatred' is the correct word, more likely overused and solving a problem that most often doesn't exist (yet) or developers interested in playing with shiny new tools (resume-driven development).

It can also lead to extra complexity. i.e. how do they all these micro-services talk to each other? event-bus or http/profbuf calls? how do they deal with one of them being down? how is this failure handled on the front-end? How is support of production now handled?

Typically this can be the hard (and most boring) part of micro-services which is often neglected and reflects badly on the final product.

There can be a tendency for inexperienced developers to skip the v1 of a project (KISS) and go straight to 'plan for FAANG web-scale' from day 1. There be dragons...

I remember one time during an interview where I was explaining an architecture I had built in a previous startup (sole engineer/architect) and the interviewer got all angry (he raised his voice dramatically) that it was all badly designed because I hadn't gotten the full micro-services approach from the get-go.

Knowing that the interview was blown (there wasn't a chance in hell I wanted to work for someone like that), I explained that maybe architecture recommendations should be based on knowing runway (not funded startup, so limited), engineering resources (just me, so really pushed for time), whether PMF had been achieved yet (it hadn't, I had rewritten it multiple times beforehand) and the number of users and the potential choke-points/bottlenecks in load (none really as user acquisition is always a problem pre PMF)

Generally I go via the monolith approach (at least initially). It's KISS and tends to lead to faster dev time.

Because sometimes the cost of complexity doesn't pencil out with the benefits it offers.

As always, it's a tool to be used for the right job, or skipped on the wrong job. Discernment is more valuable than microservices (shocking, I know).

There's always that part about never finding true love and dying alone.

https://youtu.be/y8OnoxKotPQ