Kafka vs. JMS: which one should you be using?
Two of the most popular message brokers used today are Kafka and those based around JMS. JMS is a long-standing Java API used generally for developing messaging applications, with its primary function of being able to send messages between two or more clients. Kafka, on the other hand, is a distributed streaming platform that provides a lot of scalability and is useful for real-time data processing.
While both offer their own advantages and are highly useful in their own right, which of the two should you be actually using?
JMS vs. Kafka
JMS came during a time when programs needed a way to implement asynchronous communication between different applications or different components of a system. According to Red Hat Reactive Architect Clement Escoffier, the message broker has aged relatively well.
“JMS has been successfully solving a lot of problems for the last 20 years. And we find it in banking systems, in smaller applications where asynchronous is important; like ordering systems or logistics, or even IOTs. It works relatively well on the cloud, on things like Kubernetes or in containers, because it doesn’t have any consumer limits when you have queues,” he tells us during his interview for Coding Over Cocktails.
Escoffier says that one of the advantages of JMS is that it’s Java-centric.
“You have these other protocols that you can use. But it’s a clear semantic that when you are in Java, you know exactly how it’s going to work,” he says.
And while Kafka may be receiving much hype in recent times, Escoffier says that JMS is still very popular.
“It’s still heavily used. We have lots of demand around JMS as a member of the Quarkus team. It’s quite popular. Kafka’s a very cool technology, but when people do migration, when people have more legacy kinds of systems, JMS is still where things happen.”
On the other hand, Kafka is a different technology. Confluent Field CTO Kai Waehner explains it as four things.
“It’s a messaging broker, so that’s the part you can compare to JMS. And in combination with that, it’s a storage system. JMS is partly like that, but much less so. And in addition to that, it’s also a data integration platform with Kafka Connect. And it’s also a stream-processing platform with Kafka Streams. And that’s all part of the single Apache Kafka download,” he says during a Coding Over Cocktails podcast Technology Smackdown.
Waehner adds that Kafka is different from JMS in that it’s an implementation rather than a standard.
“It’s not a standard where you have different vendors, it’s an implementation. And on top of that, it’s much more than messaging. And this is the difference. In the future, we will still see both because JMS and Kafka are for very different use-cases. For pub-sub messaging, if it does not extremely scale, at least, then JMS brokers are great for that. For anything else, people use Kafka more.”
Waehner says that Kafka has also strayed away from its original intent for big data 10 years ago, and is now used for analytics and transactional workloads, which was an original domain for JMS.
“Today, over 50% of use cases I see are about transactional workloads. There are people who say ‘I should always use JMS for transactional workloads,’ but that’s not true. You need to understand that you can also use Kafka for transactional workloads,” he explains.
Choosing the right technology
While both services have the same intent, Kafka and JMS have critical differences. Choosing between the two still depends on your use-case and there are considerations to be done in doing so. In some cases, you can even use them together, such as when your application calls for both messaging and message logging.
Learn more about JMS and Kafka and their other use-cases on Coding Over Cocktails — where we talk to the world’s leading experts on architecture, design, and the technologies that facilitate digital transformation, available on Apple, Google Podcasts, Spotify, Soundcloud, and Stitcher.
