Serverless Eventing: Cloud Native Messaging with NATS Streaming Server

We talked about the importance of an Eventing Bus earlier in the Serverless Eventing series. It is a generic term for a concept and doesn’t reflect a specific brand or technology. I previously showed you how can use Kafka as an Eventing Bus.

Kafka is a great solution that has been around since 2011. Don’t just take my word for it as it is estimated that 30% of Fortune 500 companies use Kafka. However, Kafka isn’t the right tool for every situation. Me saying Kafka (or any messaging system) is THE system to use would be as ridiculous as me saying that you should write every application in Python, including mobile. You need to evaluate your tools based on your project requirements. This is why you rarely see me take a strong stance on one solution or another. It just depends on your use case.

Introducing NATS

Today we will talk about NATS and how to use it as a Serverless Eventing Bus. Some of you reading this may be hearing about NATS for the first time. It is relatively new to the messaging landscape but I would like to point out that it’s a CNCF Incubating Project.

It was created by Derek Collison, CEO of Synadia. The goal was to simplify messaging in the cloud without sacrificing performance. To me, the goal makes sense. As the world started embracing Cloud Native architecture, there was this lingering question about messaging. Most people tried to retrofit existing busses into the architecture with various results.

They have created a comparison matrix for those who want to see how NATS stands up to solutions like RabbitMQ and Kafka. I recommend reviewing it as it will help you know when it makes sense to go NATS and what you may want to do something else. For the purposes of “Serverless Eventing”, I will highlight a few bullet points.

When building a Serverless Eventing bus, simplicity is key. We want to make things easier for our developers and platform teams, not harder. NATS was purpose built for Cloud Native Architecture.

• NATS isn’t bogged down with operational overhead such as brokers, zookeepers, and additional configurations.
• NATS Configuration is simpler. Creating NATS objects feels like creating Kubernetes objects
• NATS Core supports more known clients

Now NATS has a large ecosystem. There is the core NATS product that acts as a messaging bus. There is also the NATS Streaming Server. This is an extension that allows that NATS core servers support streaming events. You can learn more about the architecture here.

For this demo, we will be using the NATS Streaming Server. Now one thing I want to point out is that NATS has another project called JetStream. This project is the next generation of NATS Streaming and may very well replace it in the long run. JetStream is relatively newer so there isn’t much in the way of Knative integration today, but I will be happy to show a demo when more integrations are available.

Try it out

As always, I have created a tutorial in GitHub. To give a quick review of what you’ll see, you will deploy NATSS Streaming Server and create a KNative Eventing Channel that store the data. You will also have a subscription service that will pull the data from the channel and send it to the proper service to be consumed. As always, we use currency exchange rates in real time to simulate real time ingestion. Go ahead and give the tutorial a try and I’ll be here for you.

Alright, so that was easy right? This can scale from a handful of services to hundreds if not thousands. NATS is Cloud Native by nature so I really enjoy using it as an Eventing Bus. It isn’t yet as widely used as Kafka but I will definitely keep it in my toolbox. Remember, it is about using the right tool for the right project. If you don’t want a managed offering but also want a simple, Cloud Native, Eventing solution for your Kubernetes cluster, I would highly recommend NATS