There's a difference between a microservices architecture and putting in services where they make sense. We build mostly monoliths at work but we still split things into services where necessary. Necessary meaning the benefit is both large and obvious for the company.
Not all systems that use services is a microservice architecture.
#2 makes sense if you're taking advantage of that. In contrast, I've seen lots of microservices code that does little to no error handling. And if it's unicorn code that has error handling, they haven't really tested all the ramifications of their services going down in all the ways they can go down. Instead of having a system with a single point of failure, they have a system with N single points of failure. Their microservices are less fault tolerant than a monolith.
The backlash against microservices on HN is unsurprising. Over the years a ton of articles have been written vaguely about microservices and people cargo culted the architecture based upon these vague articles. Even reading comments people talk vaguely about "scaling" - what do people really mean? Before this backlash there had been non-ironic articles posted AND upvoted on HN about using microservices to scale to... a hundred requests per minute!
Lots of people seem to think that your architectural choices are either a single threaded rails app vs an eventually consistent distributed transaction CQRS nanoservice system that needs 99.999999% uptime. Meanwhile that eventually consistent distributed transaction CQRS nanoservice system that needs 99.999999% uptime is, for some reason, only running in one availability zone and falls down and corrupts your database as soon as any of your services fall over.
Oh, and it serves pictures of cats and it has 10 users and they're all family members. But someday that architecture will come in handy.
> There's a difference between a microservices architecture and putting in services where they make sense. We build mostly monoliths at work but we still split things into services where necessary.
It seems that your problem has more to do with semantics than with what microservices are.
Arguably, the definition of a microservices architecture is "not a monolith", in the sense that it's a distributed system not only with regard to support and infrastructure services but also with regards to business logic.
Not all systems that use services is a microservice architecture.
#2 makes sense if you're taking advantage of that. In contrast, I've seen lots of microservices code that does little to no error handling. And if it's unicorn code that has error handling, they haven't really tested all the ramifications of their services going down in all the ways they can go down. Instead of having a system with a single point of failure, they have a system with N single points of failure. Their microservices are less fault tolerant than a monolith.
The backlash against microservices on HN is unsurprising. Over the years a ton of articles have been written vaguely about microservices and people cargo culted the architecture based upon these vague articles. Even reading comments people talk vaguely about "scaling" - what do people really mean? Before this backlash there had been non-ironic articles posted AND upvoted on HN about using microservices to scale to... a hundred requests per minute!
Lots of people seem to think that your architectural choices are either a single threaded rails app vs an eventually consistent distributed transaction CQRS nanoservice system that needs 99.999999% uptime. Meanwhile that eventually consistent distributed transaction CQRS nanoservice system that needs 99.999999% uptime is, for some reason, only running in one availability zone and falls down and corrupts your database as soon as any of your services fall over.
Oh, and it serves pictures of cats and it has 10 users and they're all family members. But someday that architecture will come in handy.