Cloud Messaging Protocol: AMQP vs HTTP

We saw a recent post from GitHub about removing the AMQP service from GitHub Services and passed it around the team as an item of interest. Got to talking later on that evening away from the keyboard and realized it has bigger meaning than just a side note.

Recent GitHub Blog Post

 
It’s not surprising that an AMQP binding might not be something to keep up for web services. The situation is similar to SOAP bindings in a sense. REST just started to take over, and the shift happened relatively organically. At some point with protocols, there’s a shift to an easier approach. Even a solid protocol will eventually get passed over for something lighter weight and more in keeping with current developer patterns (exceptions apply, especially if Microsoft is involved.)

That’s not unlike what’s happening here in our minds. AMQP is certainly not going anywhere. It’s a strong messaging standard that has a lot of backing and inertia behind it. Unfortunately, it’s built for a different time – one that is pre-cloud and behind the firewall.

Everyone Can Speak HTTP

One thing about AMQP that makes it difficult for cloud apps and web services (aside from its general complexity) is that it’s a separate application layer protocol than the one developers are used to using on a daily basis. Another key distinction is that it uses a less common default socket as part of the transport layer.

Certain cloud application hosts don’t allow most socket connections from within their sandbox but do allow HTTP requests. HTTP and HTTPS are always open on most enterprise firewalls, but special ports may not always be. Everyone can easily speak HTTP, but it takes special effort to speak AMQP. This greatly limits the environments into which AMQP can be deployed.

With something like the GitHub API services – where it can be a simple matter of posting an event to an API endpoint – the process should be as simple as possible and shouldn’t entail having to take a course in messaging protocols.

By using the same protocol the rest of the web relies on, REST and HTTP-based protocols gain all these benefits, plus the robust and well-tested optimizations, strategies, and tools that have been developed for the web.

Big Believers in HTTP as the Transport Protocol

Don’t get us wrong. AMQP is a comprehensive messaging protocol and its not going anywhere soon. We’re just not believers it’ll be the messaging protocol for the cloud. It’s still early in cloud messaging, but it’s becoming more clear what’s needed for simple, secure, and reliable messaging on a distributed, Internet-wide level.

It’s not a stretch to think the future of cloud messaging will include HTTP as the transport protocol, OAuth for authentication and security, and JSON as the primary message format.

From there, add in other web approaches and patterns and you get the messaging protocol that will be at the center of the next wave in connecting systems – although instead of just point-to-point or within a closed system, it’ll be on a globally connected scale.

Stay tuned.