►
From YouTube: Connect All the Things! Using NATS To Simplify Communication Everywhere - Jeremy Saenz & Todd Beets
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Connect All the Things! Using NATS To Simplify Communication Everywhere - Jeremy Saenz & Todd Beets, Synadia
Speakers: Jeremy Saenz, Todd Beets
NATS is an open source, high performance messaging system and connective fabric. It aims to simultaneously simplify the number of technologies you use for your services to communicate, while also empowering you to build systems that are globally available, multi-cloud, multi-geo, and highly adaptive to change and scale. In this session you'll receive a brief introduction to NATS, then dive in to some of the many features of NATS like communication patterns, streaming/persistence, key/value and more. This session is highly interactive so come ready to participate and have fun!
A
I
would
be
napping
right
now
if
I
wasn't
giving
a
talk
because
I
don't
know
lunch
does
that
to
you,
but-
and
it's
like
the
last
day
of
the
conference.
So
well
thanks
for
coming
to
our
talk,
my
name
is
Jeremy,
and
this
is
Todd,
we'll
introduce
ourselves
a
little
bit
more,
but
we're
going
to
be
talking
all
about
Nats.
A
This
is
going
to
be
really
interactive
sessions,
so
I'm
not
going
to
just
be
blowing
through
a
bunch
of
slides,
we're
actually
going
to
play
with
gnats
together
and
hopefully
we'll
get
everybody
connected
in
the
room.
So
we'll
do
some
quick
intros.
My
name
is
Jeremy
I'm,
a
long
time
gopher
and
so
I,
like
writing,
go
I'm
a
developer
and
I've
worked
in
a
ton
of
different
Industries,
but
I've
also
worked
on
a
lot
of
projects
in
the
go
Community.
A
So,
if
are
there,
if
there
are
any
Gophers
in
the
crowd,
you
might
recognize
some
of
these
projects
and
currently
I'm
working
at
a
company
called
cenadia,
where
we
maintain
the
gnats
project,
which
is
a
cncf
project.
There's
also
a
lot
of
cncf
projects
that
use
Nats
under
the
hood,
which
is
great,
so
you
know
I'm
sure
you
can
go
to
the
floor
and
see
a
bunch
of
different
projects
like
cosmotic
and
and
to
it
with
a
lot
of
their
projects
using
gnats
under
the
hood.
A
I
recently
moved
back
to
engineering
from
a
big
product
role
that
I
was
in
for
six
years,
because
I
just
missed
building
things,
and
so
I'm
really
glad
to
be
here
and
talking
with
you
guys
about
Nats,
because
not
only
is
it
a
really
fun
technology
to
talk
about,
it's
also
really
fun
technology
to
demo.
So
we're
going
to
have
a
lot
of
fun
today,
Todd
you
want
to
introduce
yourself.
B
A
Awesome
so
friends,
Nats
is
an
adaptive
technology
and
we'll
go
more
into
that.
But
so
is
this
talk
because
I
didn't
know
what
to
do
for
kubecon.
There's,
probably
plenty
of
you
that
are
using
Nats
and
production.
I!
Don't
want
you
to
raise
your
hands
instead,
I
want
everybody
to
take
out
their
phones.
Take
out
their
laptops.
Get
real
distracted,
go
to
this
URL
right
over
here.
I'll.
Give
you
guys
just
like
a
minute
to
go.
Do
that
it's
going
to
have
you
fill
out
your
name?
A
If
you
do
not
want
to
be
somewhat
featured
in
this
presentation,
then
just
fill
out
a
random
handle
or
or
whatever
don't
fill
it
out
at
all,
but
this
is
going
to
be
our
fun
kind
of
audience,
participation,
part
of
the
talk
and
we'll
roll
through
it
throughout
the
talk,
so
go
to
kubecon22,
forcell.app
I'm,
going
to
roll
on
over
here
as
well.
You
should
seem
to
see
a
screen
like
this
I'm,
going
to
put
my
name
in
here:
Jeremy
I'm,
just
going
to
fill
out
a
couple
questions.
A
This
is
going
to
be
kind
of
our
road
map,
for
the
talk.
I
only
have
35
minutes
and
I
have
way
too
many
too
many
slides,
so
we're
going
to
pick
a
subset
of
them
and
go
through
them
based
on
where
you
guys
are
at
as
an
audience
so
I've
I'm,
using
nascent
production
I,
probably
want
to
hear
about
microservice,
architectures
and
obviously
the
most
important
question,
who
is
more
likely
to
win
an
arm
melting
match
is
Jeremy,
let's
hope,
all
right
cool.
So
we
have
some.
A
We
have
some
results
coming
in,
which
is
great
to
an
overwhelming
amount
of
folks
who
are
here
and
have
never
heard
of
nats
before
which
is
great.
We're
going
to
talk
a
lot
about
what
Nats
is
and
how
to
use
it,
and
it
actually
seems
like
a
lot
of
people
are
interested
in
that
for
microservices
architectures,
which
is
fantastic.
We've
been
seeing.
A
This
trend
happening
a
lot
with
the
companies
that
we've
been
working
with
that
are
using
that
and
there's
a
lot
of
really
cool
tools,
some
that
you
just
can't
do
with
Technology's
most
Technologies.
Today
it
looks
like
it's
a
pretty
close
out
a
pretty
close
tie
on
the
arm
wrestling
match,
but
Todd
is
kind
of
inching
ahead.
We'll
see
what
happens
by
the
end
of
this
by
the
end
of
this
conversation
that
we're
having
together,
you
guys
will
also
see
that
there's
some
logs,
we
sent
your
survey
information.
A
A
Think
many
of
us
who
have
done
that
have
learned
that
there's
actually
new
problems
that
come
with
that,
especially
when
you're
going
to
go
outside
of
the
scope
of
your
VPC,
whether
it's
for
policy
reasons,
whether
it's
for
partnership
reasons
or
whether
it
just
makes
sense
to
be
able
to
have
separate
networks
in
those
cases,
we've
also
gotten
so
used
to
location,
dependent,
back-ends
right.
Our
typical
kind
of
cloud
approach
is
to
say
cool.
A
We
have
these
horizontally
scalable
stateless
services
and
then
a
centralized
like
database
or
backend
to
that,
and
as
soon
as
you
try
to
spread
some
of
these
stateless
Services
closer
to
the
requester.
Now
you
have
the
problem
of
latency
back
to
the
actual
database
or
data
store
itself,
and
so
these
are
some
new
problems
that
we
have
to
solve.
When
we
start
moving
our
compute,
we
also
have
to
consider
what
does
it
look
like
for
us
to
move
and
distribute
our
data?
A
And
again,
all
this
stuff
is
kind
of
built
on
this,
like
HTTP
one-to-one
communication,
making
the
assumption
that
you
know
machines
can
only
talk
to
each
other
directly
right.
It's
like
almost
like
you
know:
we
have
cell
phones
today
and
I
can
go
out
on
Twitter
and
I
could
say
you
know
Twitter's
kind
of
like
this
town
hall,
where
I
can
say:
hey
I'm,
putting
something
out
into
the
world
whoever's
interested
who's
ever
subscribed
to
me
can
can
go
see
that
information
and
do
what
they
want
with
it.
A
But
in
a
lot
of
ways
these
Technologies
are
kind
of
stuck
back
with
phones
and
address
books
and
me
remembering
what
people's
phone
numbers
are
looking
up
in
an
address
book
and
calling
them
one
by
one.
No
group
calls
no
Zoom
no
more,
like
collaboration
just
one
to
one,
and
so
this
is
where
I
want
to
introduce
Nats
right.
So
what
is
gnats
now?
A
I
know
that
seems
like
a
lot,
but
what
we've
actually
done
with
Nats
is
really
hone
in
on
what
it
looks
like
to
communicate,
we're
not
trying
to
handle
orchestration
or
compute.
A
lot
of
those
are
solved
problems
and
a
lot
of
you
guys
have
already
adopted
much
of
that,
but
we
want
to
handle
the
communication
bit,
which
we
think
gets
kind
of
thrown
under
the
rug
a
little
bit
and
not
really
discussed
Okay.
A
So
what
does
Nas
do
well,
one
of
the
things
that
it
solves
for
is
this
idea
of
location,
independent,
addressing
meaning
you
don't
use
DNS
you
don't
use.
Ip
addresses
to
be
able
to
have
your
services
communicate
with
each
other
right.
We
we
can
now
use
these
kind
of
subject,
strings,
which
I'll
show
you
in
a
sec
and
they
can
communicate
with
each
other
and
not
have
to
know
where
these
particular
services
are
in
the
world.
A
We
also
introduced
this
idea,
or
we've
implemented
this
long-standing
idea
of
end-to-end
communications,
meaning
we're
not
just
necessarily
talking
about
one
to
one,
but
the
flexibility
of
everything
in
between
everything.
Talking
to
everything
and
everything
talking
to
some
things
and
I'll
show
you
how
that's
kind
of
expressed
inside
of
nats.
A
A
We
also
have
this
idea
of
decentralized
and
secure
multi-tenancy,
so
we
really
wanted
to
design
Nats
to
be
truly
multi-tenant,
meaning
that
different
completely
different
organizations
can
co-exist
on
a
single
Nat
system
and
and
still
have
this,
their
security
requirements
met,
and
this
works
really
really
well
for
organizations
where
you
know
you
don't
have
to
necessarily
tune
your
Nats
deployment
to
your
specific
use
case.
You
deploy
Nats,
you
know
in
in
one
way,
and
it
works
for
all
sorts
of
different
use
cases,
all
sorts
of
different
tenants
that
can
do
whatever
they
want.
A
And,
lastly,
and
we'll
touch
on
this
a
lot
more.
Is
this
idea
of
intelligent
persistence
that
that
we
can
you
know
if
we
store
our
messages
in
a
globally
ordered
set
of
messages?
We
can
actually
do
some
very
interesting
things
around
how
we
replicate
those
across
the
globe
and
how
we
express
different
types
of
data
structures
high
level
on
top
of
that
things
like
key
value
stores
and
object
stores.
All
from
this,
like
Atomic
unit
of
a
message
being
stored
and
persisted.
A
Lastly,
Nats
operates
very
easily
mind
you
on
a
global
scale,
meaning
that
you
can
run
in
multiple
clouds.
You
could
run
in
multiple
data,
centers,
multiple
regions
and
have
all
these
things
connected
and
acting
as
one
system
punching
through
and
all
these
kinds
of
different
networks
and
your
public
clouds,
extending
all
the
way
to
the
edge
where
you
can
run
this
thing
on
a
Raspberry,
Pi,
zero
and
and
be
able
to
have
that
operate
as
a
single.
A
So,
on
the
more
practical
side,
before
I
kind
of
show
you
guys
what
Nat
is
Nats
is
a
simple
client
server
architecture,
meaning
we
have
an
app
server
that
you
pull
up,
that
you
can
cluster
and
super
cluster
and
all
kinds
of
fun
stuff
and
that's
written
in.
Go
it's
really
easy
to
deploy.
We
have
containers,
we
support
kubernetes,
obviously,
and
and
but
we
also
support
putting
it
on
bare
metal.
A
So
I
wanted
to
show
you
guys
kind
of
an
outscore
demo
and
what
it
is
again
I
said:
NASA
is
really
fun
and
easy
to
demo
and
let's
hope
that
that's
true
we're
going
to
pray
to
the
demo
gods
for
a
second
and
see
if
this
conference
Wi-Fi
can
really
work
it.
So
it
looks
like
Todd's
still
well.
No,
it
looks
like
I've
inched
out
Todd
a
little
bit
on
the
on
the
arm.
Wrestling
match.
That's
great!
So
let's
go
over.
What
Nat's
core
is.
A
We
actually
have
a
CLI
that
we've
built
and
go
called
Nats
where
you
can
interact
with
a
Nat
server
as
a
client,
and
this
is
really
fun
for
doing
pocs
and
just
kind
of
showing
you
the
attributes
of
how
Nas
works.
Now?
Can
everybody
see
that
all
right?
Are
we
good?
Okay,
I,
don't
put
another
survey
if
you
can
see
the
screen
or
anything,
okay,
okay,
so
the
way
Nats
works
is
right.
A
Nats
has
kind
of
this
core
Atomic
unit
of
a
message,
and
you
can
publish
And
subscribe
to
these
messages,
but
you
could
also
do
other
patterns,
like
request,
reply,
fan
and
fan
out
message,
persistence
and
streaming
so
I'm
going
to
show
you
guys
what
it
looks
like
to
subscribe
to
a
message,
I'm
just
going
to
say,
Hello
dot
star.
This
is
subject-based
addressing
meaning
the
star
is
a
wild
card,
for
that
particular
token,
and
so
I
could
put
anything
I
wanted
there.
A
But
it's
going
to
match
to
that
particular
subject
and
then
I'm
going
to
reply
or
I'm
not
going
to
reply
to
anything
I'm
just
going
to
subscribe
to
the
hello
subject
over
here,
I'm
going
to
say:
Nat's,
Pub,
hello,
Dot,
Jeremy
and
let's
just
throw
a
bunch
of
them
in
there
count
I,
don't
know
a
thousand
whoops
I
need
to
actually
publish
a
payload.
Now
payloads
in
Nats
is
anything
that
you
want
to
send.
A
I
think
that
you
might
need
one
more
zero
I,
don't
know
that
was
too
fast.
Let's
put
another
zero
on
there.
There
we
go
okay,
so,
as
you
guys
can
see
we're
publishing.
This
is
locally
on
my
on
my
M1
MacBook,
but
it's
7.3
messages
a
second,
it's
pretty
good
and
again
you
can
cluster
these
for
slightly
more
performance
and
everything
and
durability,
and
things
like
that.
Nats
also
has
this
idea
of
request
reply.
So
I
can
say
Nats
reply.
A
A
So
that's
kind
of
a
high
level
demo
of
Nat's
core.
Now,
let's
jump
into
why
nuts
is
good
for
microservices
and
then
we'll
close
out
with
some
naps
jet
stream,
just
because
it's
really
cool
and
I
I
want
everybody
who's
developing
microservices,
to
be
able
to
kind
of
adopt
something
like
a
durable
message,
queue
or
persistence,
or
anything
like
that.
Actually,
before
we
move
on
from
that's
core,
does
everybody
still
have
their
window
up
by
the
way?
A
If
you
just
go
back
to
that
URL,
you
can
hit
refresh
it's
local
storage,
so
I'll
pop
you
right
back
up
everybody
whip
whip,
your
phone
or
laptop
out
again,
we'll
have
some
fun
here,
so
I'm
going
to
say,
Nats
context.
Select,
you
guys
were
all
interacting
with
an
app
server
in
Austin
Texas.
It's
our
demo
server,
so
I'm
going
to
actually
log
into
this
demo
server
and
I'm
going
to
say
just
to
kind
of
show.
A
You
guys
one
more
thing,
which
is
this
kind
of
idea
of
Q
groups
and
load
balancing
and
everything
like
that,
as
well
as
end-to-end
communication,
so
I'm
going
to
quickly
say
that's
kubecon,
dot,
roll
call
and
I'll
publish
that
and
I'm
going
to
say
replies
say
how
many
replies
I'm
expecting
back
now.
Http
can't
really
do
this.
They
can't
say
give
me
an
endpoint
and
then
give
me
all
the
people
who
care
about
this
endpoint
they're,
just
not
how
it
works
right,
but
an
end-to-end
communication.
A
You
can,
when
you
guys,
are
logged
into
that.
You're
actually
subscribed
to
this
topic
and
I
can
say:
zero
and
I'll.
Just
wait
for
a
timeout
whoops
would
I
do
wrong.
Let's
see,
let's
go
over
here,
see
what
I
did
wrong.
Oh
yeah,
whoops
gnats!
Thank
you.
That's
request,
kubecon.roll
call
reply,
zero,
look!
It
I
got
everybody's
name
some
people
more
than
once,
but
yeah
everybody's
name
in
here,
which
is
pretty
cool,
and
you
probably
saw
it
in
your
log,
but
you've
received
that
message
and
then
you
responded
to
it.
A
If
you
scroll
down,
I
can
go.
Do
that
again
just
to
show
you
guys,
but
we
have
a
lot
of
people
in
the
room
that
are
logged
in
which
is
pretty
cool
and
because
it's
going
through
that
demo
server,
that's
why
you
see
that
rtt
is
at,
like
you
know,
sometimes
one
second,
sometimes
a
milliseconds,
but
if
an
app
server
is
very
close
to
you-
and
this
is
a
perfect
example
of
what
it
looks
like
to
be
at
the
edge.
These
would
actually
be.
You
know
very
much
sub
millisecond
response
times.
A
I
could
do
one
more.
Let's
do
an
idea
of
load
balancing,
so
you
guys
are
all
still
subscribed
to
the
same
subject,
but
I
want
to
load
balance
it
between
all
of
you
guys
now,
typically,
you'd
have
to
fire
up
a
load.
Balancer
put
everybody
behind
a
load
balancer,
but
Nats
actually
does
that
automatically
I
could
say
kubecon.lottery,
because
I
only
want
one
person
but
I
want
it.
Randomly
chosen
I'm
going
to
get
rid
of
this
reply,
we're
going
to
say:
okay
M,
whoever
m
is
that's
in
the
room
won
the
lottery.
A
What
do
you
see
on
your
screen?
You
don't
have
to
raise
your
hand
or
anything
like
that,
but
hopefully
some
confetti
should
fall
from
the
screen.
Congratulations,
you've
run.
You've
won
the
Nats
Lottery
awesome
cool,
so
that
is
a
high
level
overview
of
nats.
Let's
get
back
into
Nats
for
microservices,
so
just
as
a
high
level
overview
again
of
nats
core
fire
and
forget
message
publishing
it's
really
fast.
A
We
all
saw
that
in
in
the
bench
and
this
idea
of
flexible
subject-based,
addressing
with
wild
cards
being
able
to
kind
of
mux
and
all
of
your
all
of
your
different
subjects
and
create
a
subject
hierarchy
that
makes
it
really
great
for
being
able
to
discover.
You
know
what
you
need
to
do
with
that
data
and
again
payload
agnostic.
So
whatever
format
you
want
to
use
I
just
threw
strings
around
here,
but
you
could
use
whatever
kind
of
format
you
want.
A
A
Okay,
so
now,
let's
Choose
Your
Own
Adventure
Time
and
since
everybody
was
interested
in
microservice
architectures,
let's
talk
a
little
bit
about
that
now.
What,
when
I
think
about
what
makes
a
good
architecture
you
know
when
I
was
a
developer,
it
almost
always
seemed
to
be
like
oh
yeah.
It
needed
to
be
extensible.
We
need
to
be
able
to
maintain
it,
but
there's
all
these
other
properties
that
really
matter
and
I
feel
like
this
resonates
a
lot
with
of
the
you
know,
kubernetes
and
cncf
crew.
A
Is
that
there's
so
much
more
to
application,
development
and
architectures
than
just
making
it
maintainable,
making
it
resilient
and
secure
observable
extensible
and
adaptive
to
change
and
I
want
to
talk
a
little
bit
about
how
Nats
approaches
each
of
these.
So
in
terms
of
resilience,
we
talked
about
this
client
server
architecture.
A
The
coolest
part
is
and
I
didn't
demo.
This
I
really
should
have
but
clients
self-heal,
meaning
if
a
server
goes
offline,
especially
if
you're
in
a
clustered
mode.
The
client
already
knows
about
the
server's
peers
and
automatically
connects
to
that
peer.
It
does
it's
done
so
very
transparently
for
you.
We
actually
fail
over
like
entire
clusters
as
well.
I
wish
I
had
a
million
minutes
for
a
demo,
but
I
I,
I
I,
can't
I
probably
could
show
you
guys
at
some
point.
A
If
you
come
up
to
me
or
anything
like
that,
how
we
failover
entire
clusters
like
if
an
entire
region
goes
down,
all
those
clients
move
over
automatically
to
the
closest
region
based
off
of
rtt
and
that's
just
something
that
Nats
handles
automatically
for.
You
servers
also
protect
themselves
at
all
costs.
A
One
of
the
challenges
with
building
messaging
systems
is
having
bad,
not
bad
actors,
but
slow
consumers
that
eat
up
all
of
your
resources,
and
so
Nat
servers
are
really
trying
to
be
a
messaging
server
that
that
protects
itself
at
all
costs
to
keep
resiliency
up
so
it'll
boot
out,
slow
applications,
which
means
think,
is
they're,
actually
a
really
good
trade-off,
because
we
don't
want
to
eat
up
too
many
resources
on
the
server
side.
Like
I
said,
failover
is
automatic
and
load
balancing
comes
for
free.
A
What
about
this
idea
of
security?
Well,
we've
created
a
security
model
in
apps.
That's
what
we
call
decentralized,
meaning
that
we
use.
We
use
some
cryptography
to
be
able
to
verify
a
trust
chain,
which
means
there's
very
little
that
needs
to
exist
on
the
server.
We
don't
store
any
private
keys
or
anything
like
that,
and
we
isolate
these
Nats
environments
via
accounts.
So
you
can
have
an
entire
Nats
cluster
for
your
organization.
A
Have
multiple
teams
on
that
cluster,
doing
whatever
the
heck
they
want
in
their
world,
but
also
having
the
ability
to
send
data
over
account
boundaries,
which
is
great
so
sharing
the
ideas
of
streams
and
persistent
streams
and
services
between
accounts,
also
enforcing
resource
limits
for
tenants
so
very
much
in
the
world
of
kubernetes
saying
we
want
to
operate
this
kubernetes
cluster
as
kind
of
a
public
utility
for
our
organization.
You
can
do
the
same
with
your
Nats
cluster
and
creating
permissions
for
each
service
without
server
changes,
which
is
really
really
cool.
A
Let's
talk
about
location
transparency,
I
talked
about
this
a
little
bit
inside
of
our
when
we
were
talking
about
our
subjects
but
location
transparency
is
a
key
characteristic
of
service
oriented
architectures.
This
is
kind
of
where
it
came
up
with
when
SOA,
with
all
the
rage.
The
the
idea
of
location,
transparency
really
got
got
big,
but
it's
this
idea
of
temporal
decoupling
and
the
consumers
of
a
service.
A
Don't
really
know
what
a
Services
location
is
until
they
located
a
registry,
so
the
the
ability
to
kind
of
have
a
late
binding
to
to
a
service
without
knowing
its
address
or
anything
like
that,
and
it
gives
you
this
flexibility
that
allows
you
to
kind
of
swap
out
Services
rebalance
traffic.
Everything
like
that,
all
the
things
that
you've
really
liked
about
a
load
balancer
but
just
baked
in
to
the
construct
itself.
A
So
because
we
have
location
transparency,
you
get
free
service
Discovery
with
subject-based
addressing
you
can
easily
move
Services
between
Cloud
providers,
given
that
they're
stateless
and
they
just
kind
of
really
care
about
Nats
and
you
automatically
get
routed
to
the
closest
responder.
So
if
I'm
asking
a
question
on
a
particular
topic
and
I'm
over
here
in
Detroit
and
Mike,
the
the
person
who
is
closest
to
me
is
all
the
way
in
California
I'll
get
routed
to
that.
A
A
A
Nats
is
just
a
message
broker,
so
I
could
say:
I
want
to
subscribe
to
everything,
give
me
everything
and
then
I
can
go
put
that
in
a
data
store
somewhere
put
it
in
a
stream
and-
and
you
know,
eventually
transform
it-
something
that's
like
Prometheus
Prometheus
compatible,
which
we
actually
you
know,
can
do
with
a
tool
that
we've
created
called
surveyor.
So
you
can
gather
things
like
latency
metrics
on
each
of
your
services,
which
is
really
really
neat,
and
you
can
filter
all
these
metrics
again
via
subjects,
so
we're
taking.
A
Some
of
these
constructs,
like
you
know
some
of
these
Atomic
units
like
subject-based
addressing
and
we're
kind
of
putting
it
everywhere
like
what,
if
you
could
do
your
metrics
this
way
and
your
observability
this
way.
What,
if
you
could
do
your
services
this
way
or
your
streams,
so
we're
really
trying
to
stretch
a
lot
of
the
basic
concepts
of
this
into
something
that
makes
a
lot
more
sense
as
a
whole.
A
We
also
have
this
idea
in
terms
of
extensibility
of
this,
like
multi-pattern
development.
So
again
our
synchronous
request
reply
and
then
our
asynchronous
patterns
of
publish
And
subscribe,
and
if
you
want
to
persist
your
data
or
you
want
to
be
able
to
catch
up
with
your
data
or
you
want
to
be
able
to
do
something
like
service
mesh
does
where
it's
like
Auto
retries.
A
You
could
do
all
of
that
with
being
able
to
persist
those
messages
and
and
create
a
policy
that
works
for
your
particular
use
case,
which
is
awesome,
so
I
haven't
talked
about
jet
stream
yet,
but
you
also
have
the
ability
to
you
know,
create
things
like
key
values
and
object.
Stores
I
can
be
a
nerd
and
talk
about
Nats
all
day
long,
but
this
is
kind
of
what
I
think
about
when
I
think
about
naps
for
microservice
architectures.
A
We
want
to
really
stretch
Beyond,
just
request
reply
and
going
through
proxies
for
everything
to
talk
to
each
other
and
instead
say
can
we
Embrace
more
patterns
and
instead
of
saying
well
on
the
back
end.
We
have
you
know
this,
this
kind
of
persistent
message,
bus
and
on
the
front
end.
We
just
do
grpc
everywhere,
like
what,
if
we
mix
some
of
those-
and
we
really
tried
to
pull
things
off
this
shelf
and
use
one
system
to
broker
all
of
this
information.
A
How
much
better
would
something
like
collecting,
observability
metrics
be
okay,
so
I
don't
have
time
to
look
through
all
these
other
slides,
because
that's
not
what
we
picked,
but
there's
one
thing
that
I
want
to
close
with,
and
then
we
can
move
on
to
questions
because
I'm
sure
I
hope.
Some
of
you
guys
have
some
questions.
A
So
let's
talk
a
little
bit
about
jet
stream,
so
Nat's
jet
stream
is
a
next-gen
persistence
layer,
that's
built
on
top
of
nats,
and
it
allows
you
to
have
this
temporal
decoupling
between
Publishers
and
subscribers,
which
basically
means
the
if
I'm
publishing
a
message
that
subscriber
doesn't
need
to
be
online
in
order
for
the
subscriber
to
eventually
get
it
and
the
way
we
solve.
That
is
by
persisting
the
message,
either
in
memory
or
on
disk.
A
A
It
is
globally
scalable,
so
we
get
to
piggyback
off
of
a
lot
of
the
attributes
that
coronats
brings
us
to
be
able
to
bring
us
this
type
of
multi-tenant
persistence,
and
so,
instead
of
talking
to
you
guys
about
what
jet
stream
is
I
want
to
show
you
guys
what
jet
stream
is,
and
so
you
guys
can
visit
this
natswhiteboard.onrender.com
room
is
kubecon22.
If
you
guys
are
also
staying
on
that
page
I'll,
just
navigate
it
to
you
automatically.
A
A
And
I'll
paste
this
in
nope,
that's
Pub
I!
Don't
remember
that
there
we
go.
Some
of
you
guys
should
be
already
moved
over
there
by
now
feel
free
to
draw
on
this
little
whiteboard
that
we
have
I
want
to
see
everybody's
beautiful
drawings.
Here
we
go
cool
awesome
now.
The
fun
part
about
this
is
this
is
all
in
jet
stream,
meaning
it's
all
persisted.
You
can
refresh
the
page
and
it
will
load
it
all
up
again.
This
is
again
using
our
demo
server
in
in
the
Whiteboard.
A
But
sorry
our
demo
server
in
Texas,
but
one
thing
I
can
do
is
like
I
said:
I
could
say:
Nats
sub
and
I
can
subscribe
to
this
whole
stream,
I'm
going
to
say,
I
think
this
is
called
whiteboard
or
let's
see
stream
whiteboard,
and
this
could
give
me
all
of
the
rooms.
I
don't
want
all
of
the
rooms,
so
I
can
filter.
On
that
subject,
I'd
say:
whiteboard,
Dot,
kubecon,
22.
A
I.
Think
that's
what
I
called
it
see
how
it
works
is
pulling
in
all
of
the
data
locally.
For
me,
so
I
can
put
this
on
a
local
stream.
I
could
replicate
it
into
a
different
cluster
run
to
a
different
Leaf
node
I
wish
I
could
talk
about
all
of
those
things,
but
we're
running
out
of
time,
but,
as
you
can
see,
I'm
getting
your
guys
drawings
in
real
time
as
well,
which
is
really
cool,
and
this
is
kind
of
the
ability
to
observe
state
I'm
pulling
from
a
stream
right
now.
A
It
doesn't
really
matter,
there's
a
lot
of
options
here,
but,
as
you
can
see,
we're
kind
of
graduating
from
this
kind
of
core
notion
of
like
what
does
it
look
like
to
just
send
a
message
around
and
what
does
it
look
like
to
do
that
at
scale
and
that
what
does
it
look
like
to
store
those
things
at
scale
and
that's
the
very
basics
of
of
nats,
so
I
hope
you
guys
had
fun
drawing
over
this
fun
conference.
Wi-Fi.
A
Of
course,
if
I
brought
a
server
over
here,
closer
we'd
have
much
better
performance
but
looks
like
some
people
are
also
deleting,
which
is
great
so
anyway.
Thank
you
guys
so
much
for
the
time.
I
know
we
have
about
five
minutes
and
I
wanted
to
make
sure
I
can
answer
any
questions.
So
thank
you
so
much.
C
So
this
this
solution
kind
of
Falls
within
a
whole
bunch
of
actual
other
solutions
that
are
out
there
you
mentioned
Kafka.
This
does
some
of
what
Kafka
does
right
I
see
some
of
the
things
you
know
you
could
do
with
redis.
It
falls
into
that
right.
Mqtt
protocol
does
is
almost
identical
to
this
yeah.
Where
do
you
see
gnats
in
that
whole
range,
I
mean
why?
Why
would
I
use
Nats
over,
say,
Kafka
yeah.
C
A
Yeah
so
using
streams
we
have
a.
We
have
a
concept
called
a
work
queue
stream,
which
is
very
much
like
a
just
a
durable
queue
and
one
thing
picks
it
off
at
a
time
under
the
hood.
They
still
use
one
consumer
to
kind
of
keep
track
of
it,
but
multiple
subscribers
can
interact
with
it,
and
so
it's
just
a
type
that
you
configure
I
didn't
get
to
show
how
configurable
streams
are.
D
A
Yeah,
and
so
so
the
question
was:
how
do
we
load
balance
when
we're
using
a
kubernetes,
node
pool?
Well,
the
fact
of
the
matter
is
we're,
so
each
one
of
those
each
one
of
those
pods
essentially
would
be
a
client
that
subscribes
to
a
to
a
Nats
instance
and
Nats
will
be
doing
the
load
balancing,
and
so
since
Nas
is
getting
the
message
and
essentially
brokering
it
for
request
reply,
you
get
all
of
that
load.
Balancing
for
free,
okay,.
A
Is
the
maximum
TPS
yeah
that's
highly
dependent
on
your
use
case
and
and
everything
like
that?
But
what
I
like
to
say
is
you
know
and
that's
easily
push
pushes
like
60
or
floods,
60,
gigabit,
gigabit
links,
if
you
want
it
to
especially
for
cornets
on
a
per
stream
basis,
we're
seeing
a
lot
of
people
get
about
like
250,
300,
000
messages
per
second
persisted,
and
that
gets
punched
down
to
the
disk
for
every
message
and
but
for
coronets
for
just
like
request
reply
stuff,
that's
not
being
persisted.
A
E
A
So
you
can
order
it.
We
also
have
the
con
a
similar
concept
to
like
ordered
partitions
in
Kafka,
just
slightly
different
but
same
basic
concept,
but
you
that's
not
out
of
the
box,
so
you
don't
have
to
adopt
that
complexity
if
you
don't
want
to,
but
you
can
configure
a
lot
of
what
retries
look
like
for
messages.
You
have
a
retry
window
that
you
can
configure
on
a
per
consumer
basis
as
well
as
a
back
off
policy.
A
So
if
you
wanted
to
like
actually
manually
configure
per
consumer,
what
kind
of
back
off
policy
you
get
and
how
many
retries
that
you
you
allow
it
to,
then
you
know
that's
pretty
easy
to
do.
We
also
get
this
question
a
lot
like.
Do
you
have
a
dead
letter
Q?
We
don't
officially
support
a
dead
letter
q,
but
we
do
have
advisories
for
when
something
maxes
out
on
its
retries,
so
you
can
easily
create
your
own
dead
letter
queue.
A
F
So
it's
been
compared
to
Kafka
a
lot.
So
what
I?
Of
course,
what
I
have
to
ask
is
if
there's
any
migration
plan
from
using
Kafka
to
using
Nets
like
any
sort
of
automation,
that's
been
done
to
kind
of
streamline
that
migration,
or
is
this
like,
maybe
a
bit
too
difficult
and
more
suited.
If
you
just
have
a
like
a
Greenfield
project,
yeah.
A
That's
a
great
question,
and
so
we
do
have
a
Nats
Kafka
connector,
so
you
can
kind
of
draw
the
line
on
where
you
want
to
pick
up
some
of
the
applications
that
are
using
Nats
and
then
some
that
are
still
using
Kafka
and
that's
kind
of
where
we
try
to
guide
people
who
are
doing
it
either
they're
replacing
Kafka
in
a
lot
of
ways,
but
there
might
be
Kafka
still
living
somewhere
and
that's
where
they'll
use
that
connector.
We
have
one
question
over
here:
oh
okay,.
F
A
Yep
yeah
I
wrote
that
little
react
demo
on
the
plane.
It's
actually
super
easy
to
write,
it's
like
100
lines
of
react,
and
so
it
but
you're
right.
So
as
far
as
like
exactly
once
guarantees,
we
do
support
that.
So
we
support
a
bunch
of
different
qualities
of
service
and
exactly
ones
obviously
comes
with
a
lot
of
trade-offs
as
well,
because
it's
it
involves
a
lot
of
acknowledge,
acting
and
knacking
and
making
sure
the
message
really
does
get
through.
A
But
that's
all
pretty
easy
to
set
up
on
a
when
you're
configuring,
a
stream
and
it's
consumer,
and
by
the
way
we
divorced
streams
and
consumers
a
little
bit
from
each
other.
So
you
can
set
up
a
stream
and
have
like
you
know
exactly
once
delivery
for
this
consumer
of
this
stream
over
here
and
a
different
quality
service
for
this
kind
of
Street
this
this
consumer
over
here
and
it's
all
still
the
same
data
set,
which
is
really
neat.
A
Yeah,
so
those
are
all
that
was
just
part
of
the
react
app
so
I,
just
it's
a
very
easy
subscribe
to
this
topic
and
then
go
do
something.
The
client
applications
are
very
easy
to
write
if
you're
used
to
writing
like
anything
any
sort
of
web
application
with
handlers,
it's
very
similar
to
that
yeah,
it's
very
easy
to
build
reactive
applications.
In
that
way,
all
right,
I
think
we
are
at
time
feel
free
to
come
up
to
me
if
you
guys
have
any
more
questions.