Because it’s massive over engineering of dubious value, unless you are Uber etc
Ask HN: Why do message queue-based architectures seem less popular now?
71–80 of 376 posts
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#72Most MQs had architectural side effects. Lost/re order, some required duplication for multiple listeners, lacked history (and complected debugging), introduced/required messy reconciliation and remediation processes.
Distributed logs such as Kafka, bookkeeper, and more stepped in to take some market share and most of the hype.
MQs retain their benefits and are still useful in some cases but the more modern alternatives can offer fewer asterisks.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#73There is a constant flow of HN posts about how people have built their own message queues.
I personally have built three. It's the latest thing to do.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#74My, perhaps overly cynical view, is that Message Queue architecture and blogging was all about "Resume Driven Development" - where almost everybody doing it was unlikely to ever need to scale past what a simple monolith could support running on a single laptop. All the same people who were building nightmare micro service disasters requiring tens of thousand of dollars a month of AWS services. These days all those pe…
It's simply that the complexity rises and more people are employed which then create fiefdoms to simplify and deliniate responsibilities.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#75I miss the days of Microsoft’s Robotics Studio, a message passing architecture for controlling robotics and other hardware. If only they had continued development instead of stopping halfway before it reached maturity.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#76We’re in the process of shifting an entire business from db stored state driven by large (Java and .net) apps to an AMQP based system.
I can’t really say I’m enjoying it. But it does help with scale
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#77I think this: "* The technology just got mature enough that it's not exciting to write about, but it's still really widely used." Messaging-based architecture is very popular
I think that's definitely part of it. Two roles ago my team was invested heavily in SQS and Kinesis. The role before that and my current role are pretty heavy with Kafka still.
I wouldn't call their use super interesting, though.
The last role was simply because the business required as close to real time message processing as possible for billing analytics. But if I tell someone that, it's not incredibly interesting unless I start diving into messages per second and such.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#78Earlier quoted context omitted.
I'm sure this happens. But ... most websites I load up have like a dozen things trying to gather data, whether for tracking, visitor analytics, observability, etc. Every time I view a page, multiple new unimportant messages are being sent out, and presumably processed asynchronously. Every time I order something, after I get the order confirmation page, I get an email and possibly a text message, both of which should…
One word: scale. The services you mention above do require scale if commercial. OP argues and I somewhat agree that lots of resume driven tech was oversold and overused making things more complicated and expensive than they should have. Once tech gets more mature it’s harder do misuse and it is used where real needs arise.
"MongoDB is web scale"
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#79I can offer one data point. This is from purely startup-based experience (seed to Series A). A while ago I moved from microservices to monolith because they were too complicated and had a lot of duplicated code. Without microservices there's less need for a message queue. For async stuff, I used RabbitMQ for one project, but it just felt...old and over-architected? And a lot of the tooling around it (celery) just was…
In my experience monoliths don't reduce complexity, they just shift it. The main issue with monoliths is that they don't have clear and explicit separation of concern between domain concerns, therefore it's very easy for your monolith codebase to devolve into a mess of highly interconnected spaghetti code with time. This is especially true if you're building something large with a lot of developers who don't necessar…
Who says monoliths don't have clear and explicit separation of concern between domain concerns? I think that just comes down to how the codebase is organized and how disciplined the team is, or possibly breaking out core parts into separate libraries or other similar strategies - technically it's still a monolith.
Re: Ask HN: Why do message queue-based architectures seem less popular now?
#80I can offer one data point. This is from purely startup-based experience (seed to Series A). A while ago I moved from microservices to monolith because they were too complicated and had a lot of duplicated code. Without microservices there's less need for a message queue. For async stuff, I used RabbitMQ for one project, but it just felt...old and over-architected? And a lot of the tooling around it (celery) just was…
In my experience monoliths don't reduce complexity, they just shift it. The main issue with monoliths is that they don't have clear and explicit separation of concern between domain concerns, therefore it's very easy for your monolith codebase to devolve into a mess of highly interconnected spaghetti code with time. This is especially true if you're building something large with a lot of developers who don't necessar…
The lower cost of a function call versus any microservice network call is a good performance advantage of a monolith. Monoliths also make refactoring code a lot easier. While in theory I agree about the spaghetti issue, in practice I haven't seen much of a difference. In part because microservices seem to encourage proactive overdesigning, and then the designs don't age well.
I also find monoliths a lot easier to debug. You have the whole call stack, and you get rid of a lot of potential sources of latency problems. You don't have RPC calls that might sometimes get forgotten.
Given the choice, I'd choose monolith every time. Unless, of course, microservices are needed for various other reasons. (Scale, the ability to distribute, etc.)