Ask HN: Why do message queue-based architectures seem less popular now?

Re:Ask HN: Why do message queue-based architectures seem les... by tstrimple on Tuesday June 18, 2024 @09:56PM (#40724029)

Microservices necessarily add more complexity and overhead when compared to a monolith. Just the fact that you have to orchestrate N services instead of just pressing run on a single project demonstrates some of the additional complexity.

[ Parent | on HN ]

Re:Ask HN: Why do message queue-based architectures seem les... by erulabs on Tuesday June 18, 2024 @11:06PM (#40724354)

Counterpoint: a monolith usually contains a complex init system which allows multiple ways of running the codebase. Microservices can avoid at least that one complexity.

[ Parent | on HN ]

Re:Ask HN: Why do message queue-based architectures seem les... by devoutsalsa on Tuesday June 18, 2024 @11:20PM (#40724426)

Another advantage of microservices is that you can avoid the overhead of multiple services by having one really big microservice.

[ Parent | on HN ]

Re:Ask HN: Why do message queue-based architectures seem les... by The_Colonel on Wednesday June 19, 2024 @01:05AM (#40725042)

You mean like profiles? Monolith can run like a front service or background worker depending on the config?

In a technical sense it is a complexity, but IME pales in comparison with the alternative of having to manage multiple services.

I actually really like this model, it's pretty flexible. You can still have specialized server instances dedicated for certain tasks, but you have one codebase. What's very sweet is that for local development, you just run a single application which (with all enabled profiles) can fulfill all the roles at the same time.

[ Parent | on HN ]

Re:Ask HN: Why do message queue-based architectures seem les... by rurban on Wednesday June 19, 2024 @12:53PM (#40730041)

Thanks no. I rather wait 10ms for a rebuild and 1s on gdb init, than 25m for a monolith rebuild, and 2m on gdb init.

Seperate processes, yes.

[ Parent | on HN ]