This post was written for www.liveanddev.de blog
Introduction
When I thought about writing about "AMQP vs HTTP" I thought on writing di...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
And service discovery is a breese with AMQP !
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.
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.”
Wwuuutt?then I got to
Ah ok, this guy is not so crazy after all 😀.
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.