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 s

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.