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