MQTT vs. Kafka: An IoT Advocate's Perspective
influxdata.com
MQTT vs. Kafka: An IoT Advocate's Perspective
1–10 of 122 posts
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#2This article appears to be comparing MQTT and Kafka + Schema Registry. Using Schema Registry is not required to use Kafka, so OP overcomplicated their own set up for this comparison. There's no argument that Schema Registry is valuable, but it's not something that MQTT seems to provide out of the box, so the comparison seems flawed.
I'd be interested in a comparison that is actually apples-to-apples instead of introducing complexity with Schema Registry.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#3An important question not mentioned in this article - and may not have been known by the author - is how much (Dev)Ops burden do each of these add?
In the places I've worked that use Kafka, it's 100% always a source of issues and operational headaches.
That's in fairly high throughput environments though, no idea if it "just works" flawlessly in easy going ones.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#4An important question not mentioned in this article - and may not have been known by the author - is how much (Dev)Ops burden do each of these add? In the places I've worked that use Kafka, it's 100% always a source of issues and operational headaches. That's in fairly high throughput environments though, no idea if it "just works" flawlessly in easy going ones.
I wonder... how many issues was Kafka "soaking up" by dealing with concerns that applications and services didn't have to even consider?
As in, I wonder how much application developer burden would be present if using MQTT instead.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#5I jumped onto https://mqtt.org/ to try to answer my usual use-case question about non-Kafka messaging, which is: "Do the messages get saved anywhere so you can come back and read them later?" Still not entirely sure about it.
But I did see:
This is why MQTT has 3 defined quality of service levels: 0 - at most once, 1- at least once, 2 - exactly once
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#6An important question not mentioned in this article - and may not have been known by the author - is how much (Dev)Ops burden do each of these add? In the places I've worked that use Kafka, it's 100% always a source of issues and operational headaches. That's in fairly high throughput environments though, no idea if it "just works" flawlessly in easy going ones.
I wonder... how many issues was Kafka "soaking up" by dealing with concerns that applications and services didn't have to even consider? As in, I wonder how much application developer burden would be present if using MQTT instead.
It's an interesting question. No idea how to go about quantifying it though.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#7Earlier quoted context omitted.
I wonder... how many issues was Kafka "soaking up" by dealing with concerns that applications and services didn't have to even consider? As in, I wonder how much application developer burden would be present if using MQTT instead.
It's an interesting question. No idea how to go about quantifying it though.
Fair.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#8I jumped onto https://mqtt.org/ to try to answer my usual use-case question about non-Kafka messaging, which is: "Do the messages get saved anywhere so you can come back and read them later?" Still not entirely sure about it. But I did see: This is why MQTT has 3 defined quality of service levels: 0 - at most once, 1- at least once, 2 - exactly once I'm a big fan of advertising the impossible on the front page.
[deleted]
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#9A better comparison with Kafka is redis streams. Similar semantics, a fraction of the operational overhead.
Re: MQTT vs. Kafka: An IoT Advocate's Perspective
#10Earlier quoted context omitted.
I wonder... how many issues was Kafka "soaking up" by dealing with concerns that applications and services didn't have to even consider? As in, I wonder how much application developer burden would be present if using MQTT instead.
It's an interesting question. No idea how to go about quantifying it though.
[dead]