How NATS, a REST Alternative, Provides Messaging for Distributed Systems
There’s no doubt that microservices are the solution for many companies that are looking to scale their business rapidly by releasing services independent of structural or language needs. But, like any trend, there are so many services — open source and proprietary — that are being created to serve that need. But how do all of these best of breed services work together to look like one application? They need to talk to each other.
Supported by Apcera, NATS.io is an open-source, cloud-native messaging system for distributed systems. NATS was originally written in Ruby and has since been ported to Go (gnatsd). Running on a Golang-based server, NATS can send more than seven million messages per second.
For the past three years, NATS has functioned as a microservices transport, acting as the nervous system for some modern distributed systems. Some of the integrations NATS supports are basic messaging patterns like Publish-Subscribe, Queueing and Request-Reply. NATS Clients are available in many of the most widely used languages, including Go, C and C#, Java, PHP, Python, and Rust.
“Performance and simplicity — this is really important in microservices,” given the number of systems involved at scale, said Brian Flannery, Community and Ecosystem Manager for NATS, at a recent NATS meetup in Barcelona. NATS is not attempting to replicate enterprise messaging because the developers “don’t want to overcomplicate” the messaging layer, and maintain their focus on speed and simplicity.
NATS provides an “always-on dial tone,” Flannery said. NATS achieved this by having the gnatsd server software “protect itself” at all costs, and not assume anything about the audience, rather than degrading performance for the network as a whole if there a problematic subscriber.
But who uses NATS?
Aside from supporting large-scale environments run by companies such as Huawei, Workiva and Baidu, NATS also counts users in rapidly growing companies like Avoxi, LittleBits, Pressly, and Happyco. YieldBot uses consul and consul-template for auto-scheduling NATS clusters. YieldBot’s Fatih Cetinkaya is also the maintainer of NATSboard, a dashboard for monitoring NATS.
Carrenza Cloud Services decided to use NATS to build Ernest, the company’s IaaS and PaaS hybrid cloud platform with microservices because it is quick to rewrite and replay, simple application can be handled by less developers, and developers don’t need to know the entire platform to be productive. He says that usually companies say you will be able to be productive in six months.
“With microservices, this is not a problem because from day one you can be productive in a new company,” said Raül Pérez, Carrenza’s lead software engineer. “A developer knows where it is going to fail and he knows how to fix it,” he said.
“What is NATS in our case? It is a cloud-native message platform designed to support modern cloud architectures. It is fast!” Pérez said. “At Carrenza when we were looking at different messaging systems, when we found NATS in a simple test on my laptop — and I have a good laptop — let me tell you, you have to be careful because if you try to push, try to push NATS, you could melt your whole laptop.”
Pérez particularly chose NATS because the binary is a lightweight single file that you put on your server and “you’re done,” which he says is nice-to-have when you are deploying a complex platform.
Pérez also chose NATS because it supports various messaging models and use cases, like Request/Response, Pub/Sub, and Distributed Queuing. He believes NATS gives developers clarity into product. “And, of course, this is also very important, it’s a simple text protocol. You can debug, you can sniff, you can monitor all the communication between microservices because it’s just text messages,” he continued.
Raül Pérez explains Carrenza’s NATS usage at Barcelona NATS meetup.
NATS now acts as the central communication system for Ernest, executing workflows defined by the user to build environments. Users post a workflow written in YAML file, and a finite state machine handles the state for the platform. Each action is executed is a single microservice, of which now there are 57.
“In all these microservices, we use the pattern of Publish/Subscribe because we need asynchronous communication,” for their team of three developers and one QA. “Each developer owns a component or microservice. This is great because the developer becomes an expert in this part,” Pérez said. “We really follow the Unix philosophy of do one thing and do it well,” spending more time running tests that writing code.
“We use NATS because it is really fast to develop with, you do one thing and you do it well. You don’t need to learn the whole Internet.” Pérez went on to say that “NATS allows us to not make any assumptions for what you are doing with the message platform.”
“Here developers want to know everything, so we log everything. But here getting the log easily because NATS can log millions of messages,” Pérez said.
