Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Performance server for NATS.io, the cloud and edge native messaging system

github.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#41

Post by lyu07282 »

zmmmmm wrote: post #20

Struggling to figure out what "cloud native" actually means. Unfortunately their own web site doesn't say and the CNCF web site they link to leaves me none the wiser. At a guess they are talking about applications being built from the ground up to dynamically allocate resources using cloud providers APIs directly rather than relying on an assumption fixed resources are already provisioned and the application runs wit…

> applications being built from the ground up to dynamically allocate resources using cloud providers APIs directly

If that indeed is what cloud native means, it sounds interesting. But the problem is that all these APIs and especially "managed" services are super proprietary and you'll vendor lock yourself pretty hard. But I suppose that ship has sailed a long time ago.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#43

Post by KRAKRISMOTT »

re-thc wrote: post #33
xuancanh wrote: post #32

Earlier quoted context omitted.

That is not what cloud native means. It is an overloaded term, but the basic idea is that the application is designed to operate in the cloud environment, utilizing cloud's capabilities such as elastic and automated infrastructure management.

> That is not what cloud native means. > utilizing cloud's capabilities such as elastic and automated infrastructure management. Contradictory perhaps? So it's not what it means but it is what it means? In order to achieve what you've said in vague terms you definitely do need to try to be stateless, have fast startup and reduce memory. Clear examples are things like lambda and fargate. How can you be elastic if you…

It also means having instrumentation and observability as first class features. First party support for containerisation, the app needs to be robust and capable of handling shutdowns and multiple instances gracefully. In a cloud environment, when hardware fails or instances get resized, multiple containers may get spun up and everything is kept in sync through the database (or an external data store).

Authentication and integration with auth and secret providers are another distinguishing feature. I personally find "cloud native" software to be a pain to use locally because they usually come in the form of a docker-compose and kubernetes setup, and those absolutely gobble up ram and disk space.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#45

Post by sofixa »

jitl wrote: post #2

With all the message queue whatever thingies, as an outside I’m quite confused about ideal use cases. NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they all stack up?

> NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they all stack up

I'm curious why are RabbitMQ and AMQP no longer part of such comparisons (not only your comment, nobody else on this thread has mentioned them).

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#46

Post by pjmlp »

zmmmmm wrote: post #20

Struggling to figure out what "cloud native" actually means. Unfortunately their own web site doesn't say and the CNCF web site they link to leaves me none the wiser. At a guess they are talking about applications being built from the ground up to dynamically allocate resources using cloud providers APIs directly rather than relying on an assumption fixed resources are already provisioned and the application runs wit…

Cloud native usually means targeting the "Cloud OSes", while being agnostic from the underlying OS, or legacy stuff like POSIX.

Or to put it more clear, applications written in modern language runtimes, packaged in containers that can be run on top of whatever orchestration is available, and using provider APIs and resources.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#47

Post by vosper »

yes29922 wrote: post #26
vosper wrote: post #25

Earlier quoted context omitted.

Thanks, do you know if it's a good idea to use JetStream's KV or Object stores to implement a join? I'm thinking of "fan-in", where multiple streams carrying different pieces of data about the same object all meet in the same place, and the output is a unified object carrying all those bits of data. Seems the store could be used by the joining consumer to hold onto the various pieces of data related to an object unti…

At this point, where you are doing KSQL level stuff, isn't it better to just use Kafka, NATS is very appealing for it's simplicity but if I reach a point of re-implementing KSQL or spending 3 hours setting up zookeeper and understanding how to do Kafka distributed for a devops point then Im choosing the latter

Yes you may well be right, that's kind of what I'm wondering (not using either Kafka or NATS today). Correct me if I'm wrong, but Kafka itself doesn't do joins either, right? I would need something like Flink's Window Join?

https://nightlies.apache.org/flink/flink-docs-master/docs/de...

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#48

Post by evnix »

We have had pretty bad experience with NATS. Apart from core NATS which is just in memory, you need their sub modules to build any kind of serious business on top of it.

We initially built our code around NATSStreaming, they then went ahead and deprecated that.

But since we saw so many big companies using NATS, they thought it might be a good idea to stick with it and we did a year long migration to their shiny new NATSJetstream Push based approach, but from what I see now in the conversations they are going to deprecate that too in favour of Pull based approach which is architecturally very different, now we will have to somehow convince management for another rewrite. I am not sure if we should even rewrite or just move to another product at this point.

Dear NATS, please stop throwing away and rewriting protocols and products. Or make it such that the end client libraries would handle that upgrade automatically with a library upgrade.

We should have just stuck with the more traditional Kafka or RabbitMQ.

What I have also learnt is that when companies put big brand logos on their websites, it just means some random Dev from that company is using it for their side project or experimental mini project.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#49

Post by jonathanstrange »

Can someone tell me which transport protocols and ports this uses or can be configured to use? Moreover, do clients have NAT traversal capabilities (no pun intended)?

This is always so hard to figure out for B2B libraries.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#50

Post by SebastianM »

vosper wrote: post #8
pnpnp wrote: post #4

I have been a huge advocate of NATS. For anyone looking to support multiple message patterns on one message bus, this is what you want to check out. In AWS terms, it’s like SNS/SQS/Kinesis all rolled into one bus & very intuitive to work with.

Any thoughts on NATS' JetStream? Looks quite compelling, to me. https://docs.nats.io/using-nats/developer/develop_jetstream

Jetstream (includes Streams (better as in Kafka IMO), a powerful KV Store and also an Object Store to store files) is really powerful. It earns much more attention than it currently has.

Jetstream is also much easier to operate than Kafka IMO. Just a simple single binary with an easy to understand config.

Post reply on HN