Hey Jeremy, I absolute love your videos, nats is an incredible piece of software. however, I think for credibility it would be nice to have benchmarks and correctness checks (i.e jepsen or equivalent). kafka and co have their defaults (some I can't stand) but they are the IBM of our time. Nobody was ever fired choosing IBM (kafka). In the same vein, rabbitmq and redis are extremely mature software. Trust me as CTO, there is nothing I want more to use NATS / jetstream for everything... but to foster adoption, we need measurable, reproducible guarantees! So it would be nice to know where jetstream breaks or does not honor its guarantees. Knowing the tradeoffs will actually help build more trust! Keep up the great work
Excellent points! We do have quite a bit of testing internally, and there’s some effort involved in getting that out to the public. That said, I feel like it would be super valuable to publish our tests. Keeping this on my radar
@@timc.9703 I totally agree. The more I look at NATS, the more awesome ideas come. And as soon as I try implementing them, it is so easy and efficient that I keep wondering where's the catch, but there is none.
Nat's sounds amazing on paper. But I still haven't been told where it falls down. Kafka is battle tested at extremely high throughputs, I still haven't seen a video or walkthrough about how far nats/jetstream can be pushed before it begins to fall apart (if it even does). We need a video on pushing nats/jetstream to it's limits
I'm "playing" a lot with NATS these days at work. Currently I have 900 servers sending messages on a global cluster, including Prometheus scrapes which I transfer through my NATS cluster, and it is working like a charm. There are about 2500 messages/second on the cluster, with peaks of 300K messages/second (!!!) when my 900 servers each download a 12MiB payload from an object store. The 2500 message/second barely use CPU on my 6 servers cluster, and I am planning to send more and more data through the cluster.
I think I've stayed away from that topic in the past because it's a difficult topic to communicate. So many factors at play it can be hard to lay out the use cases around NATS and JetStreams limitations. That said, I do think there is space for an episode where I spin up a cluster in the cloud and scale up a bunch of traffic in various scenarios. Would be a fun watch for sure
@@BZValoche That's exactly the kind of video I want them to put together. Nat's has that too good to be true vibe, so I'm just trying to turn over stones to check.
@@thecodegangstaeven better than a canned demo would be interviews with case-study customers that are using NATS at scale in mission critical applications. I understand that could be difficult as it might expose sensitive business info, but a few of those would go a long way towards allaying these types of concerns!
thanks, that was really helpful! I'd also appreciate if you spoke about monitoring and the life time of a message - like how do you keep track of which all consumers procesed a message, how many errors were there and so on.
Video generalized a lot saying something in the lines of "none of the competition can do X". Two corrections for RabbitMQ in particular: 1. RabbitMQ has a notion of ephemeral and durable consumers just as you describe for NATS; 2. RabbitMQ has really flexible server-side filtering with topic and header exchanges. In fact, topic exchanges is as powerful as NATS subjects. More complex deliver policies for NATS are hard to replicate in RabbitMQ tho. NATS looks awesome for sure, but as many of the other commenters I'd also like to see more fair comparison with the alternatives.
Thanks for the clarification. It can be difficult to explain all the subtle differences between all of the platforms. Maybe in the future we can dive into a comparison to RabbitMQ specifically because there are some pretty major differences between how streams/consumers in JetStream work vs topic exchanges work in RabbitMQ that lend more flexibility and adaptability from a design perspective. The main thing I wanted to highlight is that, as a whole, NATS JetStream offers a ton more options in terms of expressing your distributed system, and that's where it has a leg up over all the competition
The biggest feature difference with Kafka is the capacity to filter, but this feature makes impossible to provide ordering efficiently as they are incompatible. Ordering is fundamental and Kafka provides it efficiently.
One thing to point out is that in JetStream, it is not an either/or. You can have the flexibility of total ordering alongside an implementation that delivers just the data you want. All from the same original set of data.
What is really missing in comparion to Pulsar is a way to customize how messages are stored. Until we have an option to move very old messages down to a cheaper storage like S3 while keeping a transparent way to consume them, for me, unfortunately is a no go.
@@lucianogreiner What derek is mentioning is that you can have your "hot" stream with a short retention policy thats maybe running on expensive SSDs, and you can mirror that stream onto a stream with a longer retention policy and on cheaper storage (spinning rust). Not quite the "Export to S3" options that exist in other technologies, but definitely an option for keeping messages around and in a stream for longer without having it eat up cost.
Can you delete messages on the stream? Or is this only possible in the kv-store? I could filter them out server side before consuming but for my case this is not legally sufficient
Nats is a piece of crap. When all consumers are stopped the data produced at that period is lost. Don't even compare it to Kafka and others. Describe architecture to people before promoting it.
This is only true when persistence (jetstream) isn’t enabled. 0mq works the same way, and it’s hard to see how it could work differently without storage. Maybe don’t diss what you don’t understand?
As mentioned in another comment. NATS JetStream was designed to persist data and temporally decouple consumers and publishers. Many companies we work with have switched from Kafka to JetStream because Kafka was too inflexible for their use case.
Hey Jeremy, I absolute love your videos, nats is an incredible piece of software. however, I think for credibility it would be nice to have benchmarks and correctness checks (i.e jepsen or equivalent). kafka and co have their defaults (some I can't stand) but they are the IBM of our time. Nobody was ever fired choosing IBM (kafka). In the same vein, rabbitmq and redis are extremely mature software. Trust me as CTO, there is nothing I want more to use NATS / jetstream for everything... but to foster adoption, we need measurable, reproducible guarantees! So it would be nice to know where jetstream breaks or does not honor its guarantees. Knowing the tradeoffs will actually help build more trust! Keep up the great work
Excellent points! We do have quite a bit of testing internally, and there’s some effort involved in getting that out to the public. That said, I feel like it would be super valuable to publish our tests. Keeping this on my radar
@@thecodegangsta thanks for the response. Jet-stream is a game changer. Programmable data topologies made simple!
@@timc.9703 I totally agree. The more I look at NATS, the more awesome ideas come. And as soon as I try implementing them, it is so easy and efficient that I keep wondering where's the catch, but there is none.
nats bench is native
@@thecodegangsta benchmarks would be amazing!! Has there been any update on this? A quick google search didn't bring up anything for me
Nat's sounds amazing on paper. But I still haven't been told where it falls down. Kafka is battle tested at extremely high throughputs, I still haven't seen a video or walkthrough about how far nats/jetstream can be pushed before it begins to fall apart (if it even does). We need a video on pushing nats/jetstream to it's limits
I'm "playing" a lot with NATS these days at work. Currently I have 900 servers sending messages on a global cluster, including Prometheus scrapes which I transfer through my NATS cluster, and it is working like a charm.
There are about 2500 messages/second on the cluster, with peaks of 300K messages/second (!!!) when my 900 servers each download a 12MiB payload from an object store.
The 2500 message/second barely use CPU on my 6 servers cluster, and I am planning to send more and more data through the cluster.
I think I've stayed away from that topic in the past because it's a difficult topic to communicate. So many factors at play it can be hard to lay out the use cases around NATS and JetStreams limitations.
That said, I do think there is space for an episode where I spin up a cluster in the cloud and scale up a bunch of traffic in various scenarios. Would be a fun watch for sure
@@BZValoche That's exactly the kind of video I want them to put together. Nat's has that too good to be true vibe, so I'm just trying to turn over stones to check.
@@thecodegangstaeven better than a canned demo would be interviews with case-study customers that are using NATS at scale in mission critical applications. I understand that could be difficult as it might expose sensitive business info, but a few of those would go a long way towards allaying these types of concerns!
+1 to question about where NATS will not work well. All these videos sound great but I would like to be equally informed about all cons as well
30:00 great talk.
Please make session about deterministic partitioning.
I need this for iot and dogital twins
thanks, that was really helpful!
I'd also appreciate if you spoke about monitoring and the life time of a message - like how do you keep track of which all consumers procesed a message, how many errors were there and so on.
how to monitoring nats metrics with prometheus and grafana dashboard ,please make a video regarding this
always love the videos - non-NATS question - what are you using for your slides?
All the drawings are done in Excalidraw
Replay Policy by Time Lapse or Slow Mo factor would be great, like the Speed settings in a YT Stream ;-)=
Video generalized a lot saying something in the lines of "none of the competition can do X". Two corrections for RabbitMQ in particular:
1. RabbitMQ has a notion of ephemeral and durable consumers just as you describe for NATS;
2. RabbitMQ has really flexible server-side filtering with topic and header exchanges. In fact, topic exchanges is as powerful as NATS subjects.
More complex deliver policies for NATS are hard to replicate in RabbitMQ tho. NATS looks awesome for sure, but as many of the other commenters I'd also like to see more fair comparison with the alternatives.
Thanks for the clarification. It can be difficult to explain all the subtle differences between all of the platforms. Maybe in the future we can dive into a comparison to RabbitMQ specifically because there are some pretty major differences between how streams/consumers in JetStream work vs topic exchanges work in RabbitMQ that lend more flexibility and adaptability from a design perspective.
The main thing I wanted to highlight is that, as a whole, NATS JetStream offers a ton more options in terms of expressing your distributed system, and that's where it has a leg up over all the competition
The biggest feature difference with Kafka is the capacity to filter, but this feature makes impossible to provide ordering efficiently as they are incompatible.
Ordering is fundamental and Kafka provides it efficiently.
One thing to point out is that in JetStream, it is not an either/or. You can have the flexibility of total ordering alongside an implementation that delivers just the data you want. All from the same original set of data.
What is really missing in comparion to Pulsar is a way to customize how messages are stored. Until we have an option to move very old messages down to a cheaper storage like S3 while keeping a transparent way to consume them, for me, unfortunately is a no go.
I hear you on the tiered storage front. It’s definitely one of the strong suits of Pulsar
You can do it manually today using mirrors with different limits etc and different underlying storage. But I hear you and we are exploring some ideas!
That would be killer. On the other hand I love that nats makes it trivially easy to rebuild if necessary
@@DerekCollison Can you elaborate on that?
@@lucianogreiner What derek is mentioning is that you can have your "hot" stream with a short retention policy thats maybe running on expensive SSDs, and you can mirror that stream onto a stream with a longer retention policy and on cheaper storage (spinning rust).
Not quite the "Export to S3" options that exist in other technologies, but definitely an option for keeping messages around and in a stream for longer without having it eat up cost.
Nats async publish is amazing fast.
Is there a way to do atomic publishing in async way so that the order is guaranteed like sync publishing?
Can you delete messages on the stream? Or is this only possible in the kv-store? I could filter them out server side before consuming but for my case this is not legally sufficient
Yes! You can call an API to delete any messages on the stream you'd like. We have a NATS cli command for it as well: th-cam.com/users/livevsv0WWb00sA
Is the message removed from the stream after it has been processed by the durable consumer?
You can configure that at the Stream level!
Jeremy is a Jedi. Just get confused about this. And here is he lol
❤
Nats is a piece of crap. When all consumers are stopped the data produced at that period is lost. Don't even compare it to Kafka and others. Describe architecture to people before promoting it.
This is only true when persistence (jetstream) isn’t enabled. 0mq works the same way, and it’s hard to see how it could work differently without storage. Maybe don’t diss what you don’t understand?
As mentioned in another comment. NATS JetStream was designed to persist data and temporally decouple consumers and publishers. Many companies we work with have switched from Kafka to JetStream because Kafka was too inflexible for their use case.