AMQP vs HTTP

Federico Sörenson on July 14, 2017

This post was written for www.liveanddev.de blog Introduction When I thought about writing about "AMQP vs HTTP" I thought on writing ... [Read Full]
markdown guide
 

For me the determining factor is whether you need some kind of broadcast or routing to multiple subscribers. If it's point-to-point, HTTP will be much simpler to work with, even if async. Use AMQP when you would otherwise reinvent features like tracking subscribers, topic- or header-based routing, etc.

 

My first thought when I read the title was WAT?, but it turned out really interesting. Sometimes you have to trust that what's been decided was the right thing even if you don't remember all the reasons at the moment.

It happened a few times that we ended arguments with “Look, we've given it a lot of thought at the time, and we decided this was a bad idea. We don't remember all the arguments, but we clearly remember that this was the right decision, so it's time to stop discussing it again.”

 

No MQTT? IoT applications have caused a resurgence in MQTT recently. On the basis of having looked at AMQP a bit, and used MQTT a lot – I'm a big MQTT fan. Lightweight, lots of QoS options, and easy to use.

 

You are right, MQTT could have been a good solution too, but somehow we decided to go for AMQP handled by RabbitMQ. The way we integrated that in our services gave us the possibility of adding extra semantic to our communications, helping us in the maintenance of the code.

 

I did a Microservice architecture on http and then started another on amqp. To make it short: If you go with microservices you need an inherently asynchronous mechanism to fulfill the concepts of eventual consistency, aggregate synchronisation etcetera. I started summarising my experiences on: fordfocus1.wixsite.com/microservices

 
 

I would add monitoring as a clear advantage of Messaging over HTTP. By the way, why not implementing both endpoints types to secure need fulfillment? I would use HTTP as the out-of-the-world endpoint and messaging as the internal one. I gather performance of messaging makes it unavoidable but still it's not the "one fit all" solution especially from an integration point of view. So both should be considered complimentaries and unseparable.

 

Wwuuutt?then I got to

We are comparing shoes with t-shirts here, and that is a mistake that we have been doing for a long time.

Ah ok, this guy is not so crazy after all 😀.

 
code of conduct - report abuse