SIMPLICITY LIES AT THE HEART OF NATS
FROM KUBECON IN COPENHAGEN TO PAGERO IN GOTHENBURG
At Pagero, we constantly evaluate new technologies and software products. Sometimes, they turn out to be dead ends, but quite often, they help us speed up our development, or provide a better service to our customers. One project that we have been watching for a while, is NATS.
We already have an event-driven architecture, using RabbitMQ; a battle-tested message broker. While RabbitMQ is working pretty well for us, NATS is really interesting for us. We’ve already tried it as an embedded queue in some prototype Go (programming language) application, where it a great experience to work with.
When we heard that the NATS team were visiting Kubecon 2018 in Copenhagen, it was exciting news. Many of our developers were interested in NATS but not all could attend Kubecon. Thus, we contacted Synadia and asked if anyone would be willing to come to speak at a couple of meetups in Gothenburg. Renown NATS core contributor Waldemar Quevedo graciously accepted, and we were thrilled.
From doing a keynote in front of 4.500 people at Kubecon Copenhagen, Wally arrived in a warm and sunny Gothenburg to speak at two meetups at Pagero. Continue reading my article or check out Wally’s entire presentation below:
THE HISTORY BEHIND NATS
Wally began by explaining a little of the history behind NATS. A Cloud Native (CNCF) messaging system NATS was developed in 2010 by industry veteran, entrepreneur and pioneer in large-scale distributed systems and cloud computing, Derek Collison.
Collison, a messaging developer for some twenty-five years began to develop the system as a side project. Originally written in Ruby and built for Cloud Foundry it was later rewritten in 2012 in Go.
Open-source, NATS is currently available under Apache License (2.0) and is deployed in some of the largest cloud platforms, including VMware, Cloud Foundry, Baidu, Siemens, and GE. It is recognised by the industry for several specific strengths over its competitors such as Kafka.
“From doing a keynote in front of 4.500 people at Kubecon Copenhagen, Wally arrived in a warm and sunny Gothenburg to speak at two meetups at Pagero.”
WAY, WAY FASTER!
Speed is one of the central pillars to its success. When the system underwent its re-write in Go, or upgrade, it became pretty quick. “It’s way, way faster!” Wally explains.
In fact, the speed of the system is something he was keen to underline during the meetup: “If I have to tell you one single thing about NATS is that it’s very fast” he says, and he backs up his confident statement with some solid facts.
Wally explains that “Even in the days of Ruby it could push 150,000 messages a second,” but that’s nothing compared to the turbo-charging it went through thanks to Go. Now a single server can push approximately 11milion messages a second.
Wally explains that it achieves this thanks to its agile architecture. NATS is designed to be as operationally simple and reliable as possible while maintaining a high performance. Performance, simplicity, security and availability are the real DNA of NATS. Simplicity, Wally says, is key to effective and agile functionality.
THE TWO NATS: NATS AND NATS STREAMING
NATS is offered in two interoperable modules:
The first is the core NATS platform known simply as “NATS”.
The second is NATS Streaming, originally known as STAN (as the opposite of NATS, though the name didn’t stick).
NATS Streaming is an event streaming service that can be used to add event streaming, delivery guarantees, and historical data replay to NATS. In addition to the features of the core NATS platform, NATS Streaming provides several extra features such as enhanced message protocol – NATS Streaming implements its own enhanced message format using Google Protocol Buffers.
NATS Streaming messages can contain the following fields:
Subject – The NATS Streaming delivery subject
Reply – The optional “reply-to” subject
Data – The message payload
Timestamp – the received timestamp, in nanoseconds.
Redelivered – A flag signifying whether this message has been redelivered by the server
“NATS is designed to be as operationally simple and reliable as possible while maintaining a high performance.”
THE DARK SECRET OF NATS
Having given an extensive and authoritative rundown on the design and background to NATS and NATS Streaming, Wally draws his presentation to a close.
However, there is one question left unanswered: What does the apparent acronym “NATS” stand for?
Even on the NATS website, there is a reference to the “lore” of the NATS name but there are no answers. Unfortunately, we are still in the dark about this and can only hope that Wally returns for another meetup and an explanation soon.
OUR TAKEAWAYS
Our takeaways from Wally’s presentations are the following:
In software, complexity is dangerous. What we love about NATS is the simplicity. This goes for NATS-streaming as well.
NATS has no place in the ballroom. It doesn’t do elegant, it’s a simple, gritty beast that does exactly what it advertises.
It does not bring any dependencies, while Kafka requires Zookeeper (not to mention the JVM ). In fact, both NATS and NATS Streaming are very straightforward to embed into your Go applications, and with a very small footprint.
While Kafka is positioned as the enterprise-ready, battle-tested option, NATS Streaming can be described as a hungry contender.
It does not offer exactly-once-delivery; but do you really need it?
Also, on this topic, another project that might interest you is Jocko – a Kafka rewrite in Go.
PRACTICAL NATS: FROM BEGINNER TO PRO
For further reading on the problems which come along with microservices and cloud-native application development, do not miss Waldemar Quevedo’s newly published book “Practical NATS: From Beginner to Pro“.
GOTHENBURG TECH RADAR
Join Pageros’ meetup Gothenburg Tech Radar for more information and invitations to future events about the latest software, technology and methodologies!
