Nothing but NATS - Going Beyond Cloud Native

At KubeCon North America 2024, Kevin Hoffman and Byron Ruth from Synadia presented their vision for simplifying modern application architectures - and going beyond Cloud Native - with nothing but NATS.

Current mainstream tech used for building and operating distributed systems is limiting and overly complex for engineering teams.

The “modernˮ OSS stack that’s so familiar to us is individually full of great technology

gRPC - 1:1 request-reply and streaming
RabbitMQ - M:N messaging and queues
Kafka - scalable data streaming
Redis - key-value
Minio - object storage
Envoy - proxy, routing, load balancing
Istio - security, policy, observability

But when you step back, it’s a complicated recipe. You wind up with a complex web of tech and inherently limited tech stack—especially if your application has edge, dynamic, multi-cloud, or multi-geo requirements.

Some of those limitations or stumbling blocks:

Cumbersome discovery with HTTP/DNS
Limited 1:1 communication patterns
Perimeter-based security models
Routing via gateways and load balancers
Centralized and location dependent
Architectural and operational complexity
Multiple technologies to learn

NATS enables coherent and secure application connectivity and communications of services and data spanning clouds, geographies, and edges.

Why do teams love NATS? To the tune of 300M+ Docker pulls and a 10K+ member public Slack community?

NATS is a highly performant open-source messaging and connectivity layer that can replace RabbitMQ, Kafka, Redis and more - all in ~18mb Go binary. NATS provides publish subscribe (and request-reply)messaging, subject based addressing, persistence for streaming, key-value and object storage, and service mesh capabilities.

How does it work for different audiences of NATS users?

Developers

Build progressive distributed applications with location transparent messaging, streaming, key-value, and object storage APIs using a single client SDK, supported in all major languages.

Architects

Design and dynamically adapt topologies spanning multiple clouds, geographies, and extending to the edge without interrupting existing workloads.

Operators

Leverage built-in server multi-tenancy, security, and monitoring enabling complete visibility and control over the entire system.

Introducing Nex: The OSS NATS Execution Engine

Store your artifacts anywhere: JetStream, OCI, etc. Then deploy your apps anywhere you have NATS connectivity:

Native
JavaScript
MicroVM (Firecracker)
WebAssembly
OCI (Docker)

All with a single binary, nex. Dive into nex here.

The Dev - Prod Disparity

Without (or before) NATS

The disparity between dev and prod is real, and difficult. The promise of containerization… has mostly not delivered. Today most developers face some or all of these challenges:

Build locally, hope it works in prod
Install a full prod environment locally
Simulate so much of prod in local dev that we lose confidence
“Test in prodˮ
Sacrifice ideal architecture to accommodate easier dev-prod loop
Point to point comms is brittle
Need service discovery and client-side load balancing libraries
Spend most of your time debugging your dev environment, not your app

The NATS way

Build locally, know it works the same in prod
Rely on NATS to communicate with external services
Easy mocks for testing and local simulators
Hard work is in API definitions and maintaining boundaries
You donʼt need to install any “realˮ prod services
https://12factor.net/backing-services
Just Use NATS for persistence: durable streams, server-side consumers, key value buckets, object stores
Design the architecture you want, not the one youʼre forced to use

Whether you’re running your application in the cloud, or whether you’re running it on a Raspberry Pi to run edge based workloads (or anything in between), it’s all still the same stuff when you use NATS and NEX.

Need to scale or build your own custom, arbitrary topology? No problem. If you start more than one NEX node, they automatically form a cluster of nodes, and you can stitch together your compute infrastructure the same way you can your NATS messaging infrastructure. You have full control to design your application in whatever way suits your use case and constraints.

Need more on NATS Execution Engine (NEX)?

Jump into the video above at timestamp to watch Kevin’s demo, including the latest developments, like a web server embedded directly in a NEX node.

Have questions as you’re exploring NATS or NEX? Join us in the public Slack community