- Are microservices inherently bad or your criticism might come from a terrible implementation you've had to suffer?
- In an ideal scenario where said implementation and architecture is well designed and robust, would you enjoy working with them?
- Might be the case that your "hate" comes from the fact that this approach presents a lot of unknowns where a monolith provides a well known solution that you are familiar with?
- 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?
Disclaimer: I've had to manage microservices architecture as part of my job and also developed some side projects, so, I am not speaking from just purely a theoretical POV.
Thank you in advance for your answers.
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.
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.
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.
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.
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).