Using NATS (Streaming) as a Backbone for Flexible Microservice Architectures
Last week I was happy to hear that NATS had been adopted by the Cloud Native Computing Foundation, following the example of other popular projects such as Kubernetes, Prometheus, gRPC, and many more. NATS is a powerful, scalable, asynchronous “pub-sub” message broker written in Go. It provides a simple protocol that allows us to build resilient and fast microservice architectures, which allows for easy scalability. In the last few years we have used it extensively and learned to love it.
Microservice architectures encourage the writing of services as ‘building blocks’. Having distinct services doing only one thing and passing messages in between simplifies development and debugging, since independent blocks are easier to understand and reason about. NATS encourages this design.
It can be used to ‘Fan Out’ messages, which can be useful to distribute Data from Production to both the latest beta version in staging and the currently deployed stable version of a service, allowing us to directly compare them. The ‘Queue Group’ feature allows for horizontal scaling and load balancing, where each message is passed to a single subscriber of a Queue Group. Adding a member to the group is as easy as subscribing with the group name. Given that, we’re able to leverage the full advantages of on-demand provisioning in VM and Cloud environments.
It also performs very well – for low-to-medium workloads with NATS running on the same machine as the microservices, we found measurable but unnoticeable differences compared to a monolithic service passing data in memory. And that’s not to speak of the possibility of easily adding new machines to take over part of the workload.
Given that all of our solutions using NATS are based on processing streams of data, NATS alone does not provide the guarantees we need to offer our services at the desired level of quality. Luckily, an ad-hoc solution is offered by NATS itself, called NATS Streaming. NATS Streaming is a slightly more complex protocol providing the needed guarantees for message persistence and delivery, and is itself just a thin wrapper around a plain vanilla NATS server.
Source: https://nats.io/documentation/streaming/nats-streaming-intro/
Our IoT Monitoring and ITOA Solutions rely heavily on NATS Streaming. Basically we’re pipelining the incoming data such that it flows through single (usually stateless) services with a NATS Streaming topic in between. With this architecture we can allow for additional services and data inspection at every step of the pipeline. Additionally, we’re able to scale each group of workers arbitrarily according to the current workload. Finally, the persistence layer of NATS Streaming lets us shut down or restart entire stages without losing a single message.
Resources:
Benjamin Gröber
Author
