Java's biggest strength is that "the worst it can be" is not all that bad, and refactoring tools are quite powerful. Yes, it's wordy and long-winded. Fine, I'd rather work with that than other people's Bash scripts, say. And just because a lot of Java developers have no concept of what memory allocation means, and are happy to pull in hundreds of megabytes of dependencies to do something trivial, then allocate fucking shitloads of RAM for no reason doesn't mean that you have to.

There is a difference in microservices between those set up by a sane architect:

• clear data flow and pragmatic service requirements
• documented responses and clear failure behaviour
• pact server set up for validation in isolation
• entire system can be set up with eg. a docker compose file for testing
• simple deployment of updates into production and easy rollback

... and the CV-driven development kind by people who want to be able to 'tick the boxes' for their next career move:

• let's use Kubernetes, those guys earn a fortune
• different pet language for every service
• only failure mode is for the whole thing to freeze
• deployment needs the whole team on standby and we'll be firefighting for days after an update
• graduate developers vibe coding every fucking thing and it getting merged on Claude's approval only

We mostly do the second kind at my work; a nice Java monolith is bliss to work on in comparison. I can see why others would have bad things to say about them too.

Can be more efficient, but it's not always. You can scale those services more too. Do you need all 16 running on idle? Lazy load then as needed. Also does it really need a whole 500mb? Why? If its just a cache made that's better handles with another shared service (redis, etc). If it's software, why? A full "fat" Suse Base Container image uncompressed is 94.8mb and not all of that will be loaded in RAM. Going down to a micro at 23mb. All this and now you can deploy it on the shared infra, no separate OS, Management/security/logging/networking solution.