2018 was a banner year for the NATS.io ecosystem!

• NATS was accepted as a project into the CNCF organization
• NATS is being used in mission-critical production deployments around the globe and continues to grow
• And at almost 8 years old, 2018 saw the most features ever added to the project since its inception

At the start of 2018, the team set a course to provide additional security options, secure multi-tenancy, and larger network options for NATS to name just a few. The team succeeded in delivering all of these and more.

I think it was during early 2015 when I first heard the term message broker. I was pursuing my masters degree on P2P networking and had to simulate a steady throughput of incoming messages. I wasn’t a geek then - so the workaround was to do an infinite Thread.sleep() loop. Don’t groan - I was just 21.

RabbitMQ was my first tryst with the messaging systems lot. I was new to relationships and didn’t have much to compare with, so RabbitMQ seemed just fine. But hosting it myself was a bit of a pain and I was also growing weary of Java. That was when I found PubNub - and God was it beautiful. I didn’t need to handle anything; they had drivers lying around for virtually any environment you work with; and they had a free tier (this is when I disclose I’m from India and we hog free stuff better than anyone).

REST APIs are nice. Simple. Stateless. Scalable. But to keep client data updated in real time, things get more complicated. Streaming events is easy, but you start having to deal with questions like:

Which resources do I need events for?
How do I manage sending each client only the events they need?
Can I prevent subscription to some events for unauthorized clients?
Who keeps state of these event subscriptions?
How do I handle lost connections? Or service crashes?
Is it even possible to make search-, or pagination queries with realtime updates?
Does it scale?
Why can’t it be made simpler?!

How good is software if you don’t know how to use it? Documentation is needed no matter how simple to follow and easy to use you purport your code to be, and that is especially true with open source software.

The NATS Team has worked hard to improve and reorganize our documentation along with newly created code examples across six different client languages that illustrate how to use supported NATS clients. The new documentation will provide a better experience for those starting to use NATS by demonstrating usage of the client API and its best practices.

Ode to Node-NATS: Ts-NATS - the TypeScript native NATS for Node.

On December 23, 2011, Derek Collison gave us node-nats (Node.js v0.06). Node-nats is the second oldest client for NATS; only ruby-nats is older (10/30/2010). Node-nats is arguably one of the most popular NATS clients sporting over 64K monthly downloads.

Over the last year or so, we have been getting requests here and there to promisify the library. While on the surface these seem like syntactic sugar, changing node-nats to offer Promise and Async support requires a bit more. Because of its long history, node-nats was initially developed at a time where the standard callback patterns were not necessarily standard. Most arguments are optional, with the library performing shifting and testing that the argument order is correct. To complicate matters, node-nats offers additional options to support legacy request-reply patterns which further bloat the library and complexify its maintenance.

The latest release of the NATS Operator has alpha support to configure the authorization rules for an operated NATS cluster, via CustomResourceDefinitions , by using Kubernetes ServiceAccounts present in a namespace.

In this blog post, we will explain how to use this feature along with details of the internals on how it currently works.

Getting started

In order to use the ServiceAccounts mapped accounts for an operated NATS cluster, you will need at minimum, a Kubernetes v1.10 cluster with TokenRequest API and PodShareProcessNamespace flags enabled.

We Are Listening

We know the NATS Java library hasn’t seen a lot of love in the last year, but we are reinvigorated and the library has reached a new milestone. We wanted to let the community know we have taken your feedback from GitHub:

• Optional reconnect behavior on connect
• Excessive thread usage
• Disabling the reconnect buffer
• Notification on cluster discovery
• Improve robustness
• Improve robustness
• Better documentation

as well as comments in face to face meetings, and on Slack, to build a new compact library with:

From Kubecon in Copenhagen to Pagero in Gothenburg.

The NATS team was delighted to get an invitation from Pagero to attend two of the Gothenburg Tech Radar MeetUps in Sweden following Kubecon + CloudNativeCon EU 2018. NATS Engineer, Waldemar Quevedo did double duty at the events. Check out Robin Morero’s blog post about Wally’s visit and why they have been watching NATS.

https://blog.pagero.com/articles/tech-talk/simplicity-lies-at-the-heart-of-nats/

KubeCon + CloudNativeCon EU 2018 in Copenhagen, Denmark has come and gone and we are getting back to work but first, a recap!

This was our first conference for NATS under the stewardship of Synadia Communications, Inc. and the Cloud Native Computing Foundation (CNCF), and for this Synadian, my first technology conference ever. With a sold out conference of over 4,300+ attendees, this event buzzed with energy and excitement each and every day.

Fission is a framework for “Serverless” Functions or Functions-as-a-Service on Kubernetes. Fission allows you to take a function and easily turn it into a usable service on Kubernetes, without much of a learning curve. Fission supports a variety of source languages and triggers, which are bindings of events to functions.

Fission integrates with the NATS Streaming message queue. Users can map a queue topic to a function using a Fission Message Queue Trigger. Fission then sets up a subscription for that topic, and invokes the function once for each event. The result of the function is then pushed to another topic, also specified by the trigger.