Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 376 posts

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

#131

Post by jupp0r »

wg0 wrote: post #68
kypro wrote: post #41

Earlier quoted context omitted.

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…

I think lots of microservices can be replaced with a monolith which in turn can be replaced with a set of composable libraries versioned separately. If anyone doubts that, this very browser used to read and write is built all the way up with dozens of libraries from compression, network, image encoding, decoding, video encoding decoding, encryption, graphics, sound and what not where each library is totally separate…

If you are using Chrome, it's also a combination of multiple well separated processes talking via RPC with each other, which is pretty similar to microservices, although the separation boundaries are more influenced by attack mitigation requirements than your typical microservice architecture would be.

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

#132

Post by 1oooqooq »

willturman wrote: post #95

I implemented RabbitMQ based messaging queues as a mechanism to coordinate execution among discrete components of a handful of ambitious laboratory automation systems ~4-8 years ago. Given a recent opportunity to rethink messaging based architectures, I chose the simplicity and flexibility of Redis to implement stack and queue based data-structures accessible across distributed nodes. With even a handful of nodes, it…

sounds like you're about to reinvent a queueing system on top of redis. in a very painful way.

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

#134

Post by jupp0r »

wvenable wrote: post #91
fouc wrote: post #79

Earlier quoted context omitted.

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.

Libraries are a great way to manage separation of concerns. Any dependency you add has to be explicit. There's nothing stopping you from adding that dependency but you can't just do it accidentally. The graph of dependencies between components makes for explicit separation of concerns just like you would have a graph of dependencies between different network services.

Or you just use a language with support for clear module API boundaries (vs something like Ruby where without bolt on hacks, every piece of code can call any other in the same process).

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

#135

Post by berkes »

I think the premise is wrong. That "we" are still using it en masse and in ever increasing amounts.

We just call it different. Or use different underlying products. Nearly all web frameworks have some worker system built in. Many languages have async abilities using threads and messaging built in.

The only popular language and ecosystem I can think of that doesn't offer "worker queues" and messaging OOTB is JavaScript.

We are using it more than ever before. We just don't talk about it anymore, because it has become "boring" tech.

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

#136

Post by 1oooqooq »

aspyct wrote: post #110

We have a new project (~ 6 years now) where we implemented a queue with RabbitMQ to temporarily store business events before they are stored in a database for reporting later. It's awesome! It absorbs the peaks, smoothes them out, acts as a buffer for when the database is down for upgrades, and I think over all these years we only had one small issue with it. 10/10 would recommend.

looks like you could have had a blue/green DB setup which would give you one less system to maintain and other benefits that a simple queue don't provide.

also, what do you do when the queue is down?

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

#140

Post by sofixa »

k8sToGo wrote: post #124
steve1977 wrote: post #115

Earlier quoted context omitted.

That‘s nice, but the question is if you (i.e. your company) needs this ecosystem.

Need no. But it’s nice especially since I have the know how. Creating a new deployment is just super fast. Developers can deploy their own apps etc. And then there is Helm. If we only decide by “need” then most of the time we also wouldn’t need object oriented programming.

> And then there is Helm

Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").

Post reply on HN