Learn how simple it can be to build adaptive and scalable
Powered By OpenSource
Virtual | November 10 | 9am - 1pm PT
A quick "hello" and orientation of the event.
Rethinking connectivity from cloud to edge
Systems that require a global presence continue to push the boundaries of what it means to be "global". Data sovereignty, resilience, and new levels of scale require a microservices architecture that can span multiple clouds, geographies, and can be extended to the near and far edge. How does NATS enable and simplify building these globally distributed systems leveraging location transparent messaging and data streaming?
Transcending microservices with NATS
Deploying one or more services to a single cloud provider or platform, in a single region, has never been easier. Multi-region on the same provider is becoming more accessible, however, even Kubernetes distributions are generally limited to a single region. What if you need the freedom to deploy anywhere and connect everything, in the cloud or at the edge?
Seamless evolution across geos and clouds
Traditional microservices, even with well-defined boundaries, can bring unnecessary complexity both operationally and at runtime. How does NATS alleviate these complexities?
Service monitoring with Helix and Surveyor
No matter the system, monitoring and observability are necessary to operate a system successfully. NATS provides a rich set of monitoring information for your services that is easy to collect and send to various monitoring services.
Versioning and canary deployments with subject mapping
Systems are never static. They are always evolving to improve, whether it is refactoring or testing out new capabilities with real traffic. Using NATS built-in support for subject mapping and traffic shaping, deploying and testing new versions is straightforward.
Extending stateful services to the edge
Microservices are commonly thought of as a heterogenous set of services deployed in a cloud environment with the luxury of low-latency and fairly reliable network links. What does it mean to run a stateful service at the edge? What challenges does that present and how does NATS address these?
Using JetStream KV for dynamic microservice configuration
Managing runtime configuration for a fleet of globally distributed microservices with varying degrees of availability can be a huge challenge especially with current KV technologies that aren't accessible beyond a single cluster or geography. With JetStream's KV abstraction built on a stream, configuration updates are guaranteed consistent, while availability of these options can be localized across geographies using mirrors.
Short break and Q&A!
Where are we now and where to next?
Much of the industry's focus is on faster and simpler ways to deploy and manage user applications. Synadia, enabled by NATS, is focused on connectivity, initially with messaging, and now with persistent streams, key-value stores, and object storage. Edge-first design has been a guiding principle which is differentiated from any cloud-first solution.
What might a native NATS service API look like?
Historically, NATS has provided easy-to-use, but fairly low-level client APIs without much guidance on modeling services. As the use case of microservices in the cloud and at the edge has increased significantly in the past 12 months, the NATS team has prototyped a simple API for creating services.
Using NATS JetStream as a Kine backend for k3s
k3s is a Kubernetes distribution designed for edge and IoT environments where maintaining a highly available control plane can be challenging. Support for NATS as a Kine backend was contributed in the beginning of 2022.
Effective debugging using the NATS CLI
The NATS CLI provides, not only, subcommands to perform publish-subscribe, request-reply, and JetStream management operations, but it also supports a suite of server management, introspection, and debugging tools.
Comparing and contrasting NATS and Kafka
Kafka was a first-mover in the market of scalable message streaming ingestion and processing. Being written in Java, it fit right into the early "Big Data" ecosystem and had developed a significant number of integrations with distributed filesystem and stream processing frameworks. NATS began as a stateless messaging system that later added persistence. Although there are use cases that can be satisfied by either system, NATS and Kafka have very different origin stories and how the value of simplicity plays a role.
Proof-of-concept inline Wasm execution on messages
WebAssembly has piqued curiosity and interest in a lot of people in the past couple years. In the last six months, a number of new platforms have been developed betting on Wasm modules as the future of computing. What if Wasm modules could be dynamically pushed and used in the message hot-path?
Lightweight relational databases at the edge
Although NATS streams solves the globally replicated and ordering problem, a sequence of messages isn't exactly queryable. What might it look like to derive a relational database from one or more streams?
Resources and good bye.