Since its commencement, cloud computing has definitely made developing, deploying, scaling and monitoring applications far easier, accessible and affordable to developers. Startups that hit the front page of major media publications or popular forums easily survive the traffic spike thanks to the cloud.
That said, the cloud can also be a bit confusing to many a developer. Many products sound the same, perhaps even cost the same, but have subtle differences that can greatly affect your application. For example Cloud Storage, sometimes you’ll see various types; hot storage, cold storage, replicated, vault, and so on. They can all store the same files, the same way, many times with exactly the same API, but with cold storage, the cost of retrieving a file is much greater both in terms of time and money, storing it is cheaper. With hot storage, the reverse is true.
While the storage example above if pretty simple to understand, others might not be so clear and this article strives to explain one of them.
You might have already come across the term message queues, if not I suggest you take a quick read over how they can greatly improve application reliability and scalability in a previous post Improving Reliability with Alibaba Cloud Message Service.
There are very many message queues out there, from RocketMQ, RabbitMQ, Apache Kafka, ZeroMQ, MosquitoMQ, and many more. Many Cloud providers also offer managed message queues as a service and Alibaba Cloud has two of them namely the Message Queue and the Message Service.
From their online descriptions.
Message Queue is a distributed message queue service that supports reliable message-based asynchronous communication among microservices, distributed systems, and serverless applications.
Message Service is a message queuing and notification service that facilitates smooth transfer of messages between applications
They almost sound like a paraphrase of each other, don’t they? Well, as we’ll see shortly, it’s mostly because they are very similar products. To understand this, let’s briefly look at the architecture of a message queue.
At the very heart of both the Message Queue and Message Service is the design above. They both use and can execute this model with similar efficiency. However, the major difference I’ve found is in how the message can be sent by the producer and consumed by the receiver.
The Architectural Difference
The older, battled tested Message Queue has been integrated into the infrastructure of Alibaba Group for over 11 years and servicing Alibaba’s 11–11 e-commerce sales event for over nine years. In September 2017, RocketMQ, the kernel engine of Alibaba Cloud Message Queue, became an Apache top-level project.
With those many years of development, the Message Queue had more community experience and expertise behind it, but it also comes with more legacy methods and restrictions. For example, the Message Queue can only speak over TCP or MQTT protocols. This means you’ll most likely require specific extensions enabled on your server to access these protocols. It also means you will most likely require an officially supported SDK to use it. Currently, Alibaba Cloud supports Python, PHP, .NET and Java programming languages. This means that both your producers and consumers must be written in one of those languages if you want official support.
The newer Message Service product differs from the Message Queue in that it can speak HTTP. This is a crucial differentiator implying that, so long as you can send a HTTP request, your application can use the Message Service. This opens the door to almost each and every programming language out there. There are official SDKs of course, but these are mostly to add synthetic sugar to make using it easier. Another decisive differentiator is that the Message Service has the ability to push out message to consumers instead of waiting for them to pull the messages out of the queue. The consumer can be any HTTP server, a browser via websockets, a mobile phone, an email address or even another Message Queue service!
What this means is that the newer Message Service removes the restrictions on what programming languages or frameworks you can use. Which can be vital for the competitiveness of any application, for example Uber rewrote their Geolocation component from Python to Go while One Signal rewrote their entire application in Rust. Both saw great gains, companies in similar shoes would find that difficult or impossible to do if those components depended on the Message Queue. On the contrary, it would be a rather trivial affair if they were using the Message Service.
The Performance Difference
Both the Message Queue and the newer Message Service are blazing fast and globally scalable across the many Alibaba Cloud data centers. They both provide 99.9999999% reliability and ensure successful message delivery within the valid period.
However, for pure performance comparisons, the Message Queue probably wins here, due to its maturity and that fact that its protocols operate at a lower level. To quote Alibaba Cloud, “From years of experience servicing Alibaba’s annual 11–11 e-commerce event, the technical team at Alibaba Cloud have developed methods to resolve slow request response time jitter problems caused by system overload due to super-high concurrency. Among the flow of the trillion messages sent during the 11–11 event held in 2017, the recorded latency of 99.6% of message write requests was less than 1ms, and less than 10ms for the recorded latency of 99.996% message write requests.”
That said, it should be noted that by using the Message Service, application developers can now be free to rewrite critical components in the language most suited to it as with the examples above. Therefore, while the Message Queue is probably a slightly faster queuing system, the Message Service has greater potential to help develop faster applications.
Both products are robust, reliable and scalable. The Message Queue has been used at the largest e-commerce site in the world, has tons of articles and expertise behind it and performs really well. However, the Message Service can do what the Message Queue can but it also has a greater feature set and allows for smoother interoperability between applications written in different languages. For this reason, if you are starting out with message queues or looking to switch, I’d highly recommend the Message Service over the Message Queue.