►
From YouTube: Easy, Secure and Fast - Using NATS for Data Streams and Services - Colin Sullivan, Synadia
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Easy, Secure and Fast - Using NATS for Data Streams and Services - Colin Sullivan, Synadia
Distributed systems architecture has been disrupted via decomposition as cloud technology has matured - we’ve seen a migration from monolithic applications to microservices coordinating across large scale deployments. This has created a need for flexible deployments, secure and transparent data sharing, multiple communication patterns, location transparency, and the decoupling of data producers and consumers. NATS is a cloud-native messaging project that addresses these needs. While cloud-native, NATS and can also run on-premise, edge and even endpoints. In this discussion, we'll introduce you to NATS: how NATS came to be, its DNA and cover some of the problems that it solves. We’ll describe common messaging patterns, when to use them, and design principles to create NATS enabled cloud-native applications. For more information be sure to follow this up with the NATS deep dive!
https://sched.co/Zewv
A
A
First
off
what
is
nantz
nance
is
a
10
year
old
production
proven
cloud
native
distributed
communication
system,
nats
was
made
for
developers
and
operators
who
just
want
to
do
their
jobs.
You
don't
want
to
think
about
managing
a
messaging
system.
So,
what's
important
to
us
is
performance,
simplicity,
security
and
availability.
A
A
For
that
we
joined
cncf
as
an
incubation
project
in
2018
and
we're
part
of
the
messaging
and
streaming
projects,
and
we
have
over
a
thousand
contributors
over
the
last
10
years,
with
a
hundred
or
more
with
more
than
10
commits.
We've
got
quite
a
few
public
repositories,
we're
hoping
to
break
20,
000
github
stars
across
all
the
repositories.
This
year
we've
got
about
130
million
doctor
pulse
between
nat
server
and
that
streaming
server,
a
very
healthy
slack
community
and
a
good
cadence
of
net
server
releases
since
2014.
A
A
A
Now
don't
get
that
confused,
that
we
can
send
any
type
of
payload,
but
the
very
simple
protocol
makes
it
easy
to
write
clients
and
that's
why
we
have
so
many
of
them.
Nance
is
low
configuration
when
a
client
connects
to
the
server.
It
doesn't
need
to
know
anything
about
the
topology.
It
just
needs
a
url
and
credentials
servers
can
auto
discover,
you
can
share
configuration
files
among
servers
and
nas
is
very
easy
to
code
to
it's
a
very
simple
and
straightforward
api.
A
A
Now,
let's
talk
a
bit
about
message
patterns
and
this
is
these-
are-
are
how
your
applications
communicate
with
each
other,
and
we
tend
to
like
to
think
of
these
in
two
buckets
streams
and
services.
A
stream
is
a
flow
of
data.
It's
just
a
number
of
messages
going
out
and
streams
can
fan
out.
You
might
have
a
stream
of
data
you
fan
out
to
a
thousand
or
ten
thousand
or
a
million
subscribers.
A
Then
we
have
the
concept
of
services.
Services
are
where
I
want
to
ask
an
application
to
do
some
work
and
then
return.
The
result.
Services
are
by
far
the
most
common
that
we
see
and
services
can
be
load,
balanced
streams
and
services
at
the
application
level,
when
you
go
to
code
really
fall
into
a
couple
patterns
which
is
request
reply.
These
are
your
services.
A
Before
we
talk
about
patterns,
let's,
let's
talk
about
subjects
and
how
data
gets
from
one
application
to
another
nat
routes,
data
based
on
interest,
so
an
application
will
register
a
subscriber
with
a
subject
indicating
interest
in
something
so
there's
a
very
simple
subject:
your
everlasting
foo
example,
or
let's
take
something
more
concrete,
I'm
interested
in
weather,
so
I
create
a
subscriber
for
weather.
These
can
be
hierarchically,
tokenized,
so
food.r
or
weather.us.colorado.denver.
A
Streams
are
pretty
simple:
nats
will
fan
out,
published
messages
to
all
interested
subscribers.
It
might
be
one
subscriber,
it
might
be
a
million,
but
nats
takes
care
of
that,
and
you
can
add,
or
remove
subscribers
anytime
at
runtime,
with
no
configuration
nats
will
just
do
the
right
thing
and
start
routing
information
to
them.
A
The
code
to
set
up
a
stream
today
is
is
very,
very
simple:
you
connect
to
a
net
server.
You
subscribe
to
a
stream
in
this
case,
I'm
interested
in
data
arriving
on
foo.
When
that
data
arrives,
I'm
just
going
to
print
it
out.
That's
that
log
print
line
and
then
the
corresponding,
publish
to
get
that
data
out
onto
foo
is
just
the
publish
api
there.
Extremely
simple.
This
is
actually
could
be
a
working
application
right
here.
A
A
Here's
the
service
api
code,
so
you
connect
in
this
case
to
a
local
net
server.
You
subscribe,
I'm
going
to
be
offering
a
service
on
the
subject
of
help,
and
then,
when
someone
says,
can
you
help
I'm
going
to
say?
Yes,
I'm
going
to
respond
with
a
message
that
says
I
can
help
on
the
requester
side,
I
below
I
issue
a
request
for
help
say
that
I
need
some
help.
Wait
a
second
up
to
a
second
for
a
response
and
then
just
print
the
response.
A
A
It
essentially
creates
a
pre
competing
consumer
pattern,
but
what
happens
is
the
nat
server
will
then
randomly
distribute
messages
to
these
subscribers,
and
this
allows
you
to
set
up
a
service
and
set
up
a
number
of
services
that
will
automatically
scale
as
if
it
were
a
layer,
7
load.
Balancer
again,
you
can
add
these
services
anytime,
remove
them
anytime,
and
that
just
does
the
right
thing.
No
additional
configuration
this
allows
you
to
very
very
easily
scale.
A
So
now
that
we've
covered
our
patterns
in
the
at
the
application
level,
let's
talk
about
topology
topology
is
the
plumbing
or
you
know,
think
of
it
like
the
electrical
grid.
For
your
messages,
this
is
where
messages
may
arise
and
nats
has
a
number
of
building
blocks
for
topology
the
lowest
common
denominator.
The
simplest
thing
is
your
server.
That's
like
a
network
element
servers
can
be
grouped
together
to
form
one
cohesive
unit
called
a
cluster
that
provides
higher
availability
and
lets
you
scale.
A
A
The
very,
very
simple
setup,
which
is
what
most
developers
will
do
on
their
on
their
machines,
is
a
single
server
with
a
couple
of
net's
clients
connected
to
it
clusters.
When
you
cluster
net
servers,
are
full
hop
or
a
full
mesh.
One
hop
that
means
nat
servers
will
always
route
messages
in
the
shortest
number
of
hops
that
that
are
available
clusters
clustered
together.
Our
super
clusters.
Again,
we
use
what
are
called
gateway.
Connections
between
the
clusters.
A
Gateway
connections
are
optimized
for
a
wan
optimized
for
low
late
or
optimized
for
higher
latency,
lower
bandwidth
connections
and
any
number
of
clusters
can
be
grouped
together
in
a
super
cluster.
At
synadia
we
have
a
massive
super
cluster
spread
out
across
various
cloud
vendors
over
the
whole
over
the
globe.
A
A
These
are
ideal
for
edge
computing,
iot
hubs,
data
centers,
anything
that's
remote.
That
needs
to
be
connected
into
a
central
central
deployment
and
then
they
can
also
transparently
bridge
on
premise
and
cloud
deployments.
Remember
that
nat's
clients
don't
care
about
the
topology
at
all.
They
just
know
that
they're
connected
to
nets.
A
Here's
a
global
deployment,
an
example
of
a
global
deployment
where
you
might
have
a
nas
cluster
running
in
kubernetes
in
san
diego,
a
nas
cluster
running
on
vms
in
berlin
and
another
one
in
london
on
kubernetes,
you
have
a
remote
data
center,
that's
clustered
together
with
some
services
streams
connected
into
san
diego
and
then
a
leaf
node.
That
might
be
like
a
set-top
box
with
devices
connected
to
it.
A
A
You
can
set
permissions
on
what
applications
or
what
users
can
send
and
receive,
and
what
subjects
you
can
change
these
at
any
time
with
zero
downtime
you
can
adjust,
the
config
have
the
next
server.
Re-Read
it
at
runtime
and
it'll.
Do
the
right
thing
and
then,
with
operator
mode
in
that's
2.0
which,
which
is
about
been
out
for
about
a
year
and
a
half
nat
supports
multi-tenancy
with
operator
mode.
A
A
And
nats
allows
you
to
set
up
this
chain
of
trust
between
operators,
accounts
and
users
within
a
deployment
and
operators,
the
root
of
trust
for
the
system.
So
that's
like
an
enterprise
underneath
the
operator
you
create
accounts
for
account
administrators
an
account
represents
an
organization,
it
might
be
a
team,
it
might
be
a
group
of
microservices,
it
might
be
an
it
group.
That's
monitoring
the
entire
nas
deployment,
an
account
creation
would
likely
be
managed
by
a
central
group
and
then
underneath
accounts.
A
Our
accounts
can
expose
streams
and
services
and
underneath
accounts
you
have
users
that
have
specific
credentials
and
permissions,
so
accounts
are
isolated.
Communication
context.
What
what
accounts
do
are
when
you've
got
multiple
accounts
on
a
server
applications
connect
into
those
accounts.
Those
messages
will
never
cross
those
account
boundaries
that
allows
you
to
bifurcate
technology
from
business,
driven
use
cases
that
allows
you
to
create
data
silos.
A
Based
on
these
accounts,
it's
secure
and
cost
effective,
so
onenet's
deployment
is
managed
by
an
operator.
Yet
teams
can
be
decentralized
and
self-managed,
but
when
data
does
need
to
be
shared
between
these
accounts,
you
can
share
them
with
secure
streams
and
services.
So
one
account
might
offer
a
service
on
subject
foo,
another
account
might
say
hey.
I
want
that
service.
It
will
import
that
service
on
foo
and
suddenly
that's
available,
and
only
with
mutual
agreement
will
data
flow
between
accounts.
A
We
used
ed25519
because
it's
fast
and
resistant
side
channel
attacks,
we
use
those
to
sign
and
verify
and
we
use
them
in
such
a
way
that
nat's
system
will
never
see
private
keys
without
getting
into
details.
That
server
sends
a
non-stern
connect.
The
client
signs
the
notes
with
its
private
key
and
then
the
server
verifies
that
the
client
belongs
to
an
account
known
by
the
server
long
story
short.
This
is
letting
ads
approach,
a
zero
trust
system
and
all
this
stuff
is
managed
by
by
the
nsc
command
line
interface.
A
A
When
you
combine
topology
and
security
with
your
application
patterns,
we
create
the
adaptive
edge
architecture.
So,
over
time
we
found,
as
many
companies
have
come
to
us
and
users
have
come
to
us.
We
found
a
pattern
emerge
and
if
you
squint,
they
all
look
the
same.
Where
you
have
this
central
central
deployment,
with
some
streams
and
services
attached
to
it,
that's
available
for
everything
and
then
remotes,
they
might
have
their
own
services
their
own
streams,
some
of
which
might
be
shared.
Some
which
might
be,
might
not
and
depends
on
policy.
A
But
then
you
have
these
remote
deployments
that
are
all
linked
together
to
create
a
massive
global
deployment.
This
is
essentially
the
iot
or
the
edge
use
case,
and
we
found
that
through
a
combination
of
leaf
nodes
clusters
and
super
clusters.
Nats
can
handle
this
very
well
and
if
you
look
at
how
this
can
be
applied
to
different
verticals,
this
pattern
is
very
powerful,
so
very,
very
powerful.
So
example
in
retail
you
might
have
a
regional
headquarters.
A
It
will
have
some
ad
reward
programs,
coupons
logistics,
centralized
inventory
where
the
remotes
are
the
stores,
and
then
you
have
pos
devices
connected
into
the
remote
that
then
utilizes
these
streams
and
services,
or
maybe
even
provides
their
own
streams
coming
of
stores
coming
back
to
the
central.
This
is
repeated
over
and
over
again
for
different
use
cases,
and
we
found
that
you
know
again.
It's
the
it's
a
similar
pattern
in
terms
of
topology.
What
changes
are
your
streams
and
services
and
your
security.
A
Here's
an
example
where
multiple
airlines
or
airports,
multiple
airports
are
super
clustered
together
in
the
eu
and
extending
out
of
the
super
cluster
are
leaf
nodes
inside
terminals
and
concourses
even
planes.
This
is
your
plumbing.
This
is
your
wiring,
but
then,
in
terms
of
data
flow,
you've
got
a
weather
service
where
different
airlines
and
airports
can
use
this
weather
service,
but
the
airlines
themselves
will
never
talk
to
each
other.
These
are
all
set
up
by
accounts
and
streams,
streams
and
service
sharing.
A
Now,
let's
segue
into
performance
and
scalability
nats
performs
extremely
well
with
about
18
million
messages,
a
second
and
one
server,
one
data
stream,
80
million
messages,
a
second
with
multiple
services.
Some
of
this
is
is
a
vanity
metric,
but
it
translates
into
scalability
and
resource
utilization.
So
if
a
single
net
server
can
handle
18
million
messages
a
second
that
means,
if
you
only
need
a
few
thousand
messages,
a
second
or
twenty
thousand
messages,
a
second,
a
single
net
server
is
going
to
do
you
well
for
a
long
time.
A
Traditional
messaging
systems
would
would
spend
resources
on
trying
to
make
sure
that
a
poorly
behaving
application
always
got
the
message
that
doesn't
work
in
cloud.
So
to
that
end,
the
nat
server
performs
selfish
optimization.
If
there
is
a
poorly
behaving,
client
or
poorly
behaving
server,
then
that
server
will
cut
it
off
and
then
at
that
point
an
operator
will
look
at
it.
We've
got
full
mesh
clustering
in
the
net
servers
and
the
server
and
client
connection
cell
field.
This
creates
a
low
maintenance,
always
on
always
available
deployment.
For
that.
A
Nets
also
has
auto
discovery.
What
this
means
is,
as
you
scale
up
or
scale
down,
net
servers
in
a
cluster.
This
information
is
shared
with
the
other
nat
server,
so
you
don't
have
to
do
additional
configuration.
You
don't
have
to
bring
anything
down
or
bring
it
back
up
again
to
change
your
topology,
and
this
information
is
also
shared
with
clients.
That
means
clients
can
fail
over
to
servers.
They
were
never
originally
configured
with,
and
these
are
great
for
rolling
upgrades
or
you
know,
even
swapping
out
your
back
end
with
different
machines.
A
If
you
need
to
upgrade
machines,
do
whatever
you
need
to
do
your
clients
can
remain
running.
We
have
a
couple
different
message:
guarantees
at
its
core.
We
support
at
most
once
where
there's
no
guarantee
of
delivery
or
messages
can
be
lost.
This
sounds
harsh,
but
it's
how
the
internet
works
today,
and
then
we
have
at
least
once
which
are
where
a
message
will
always
be
delivered
in
certain
cases,
certain
air
conditions.
It
can
be
delivered
more
than
once.
A
Jet
stream
is
the
next
generation
of
net
streaming.
It
supports
there's
a
lot
of
overlap
with
that
streaming,
but
it
also
supports
wild
card
support
and
that's
2.0
security.
So
it's
screen.
It's
account
aware:
it's
got
data
at
rest,
encryption.
You
can
clean
specific
messages,
so
this
was
a
request
that
really
helps
out
with
gdpr
and
horizontal
scalability.
So,
as
you
need
to
scale
you
just
launch
more
jet
stream
servers
and
like
nat
streaming,
you
can
replay
messages
by
timer
sequence,.
A
A
A
We
have
nat
surveyor,
so
surveyor
can
monitor
your
entire
entire
deployment
from
one
entry
point
into
nas.
It
provides
a
comprehensive
view
of
the
entire
announced
deployment.
So
if
I've
got
surveyor
running
on
my
laptop,
I
just
connect
to
my
nat's
deployment,
and
I
can
see
everything
so
long
as
I
have
the
right
credentials.
A
And
we
use
grafana
as
a
dashboard.
We
provide
centralized
visualization,
but
you
can
also
drill
down
into
and
look
at
individual
servers
and
then
we
work
well.
In
kubernetes,
we've
got
a
single
command
line
to
install
a
full
nats
cluster
in
a
kubernetes
deployment.
It
defaults
and
installs
gnats
as
a
stateful
set,
and
along
with
that,
we
give
you
a
surveyor
installation,
so
you
can
see
what's
going
on
and
our
roadmap
moving
forward
in
the
latest
release.
We've
got
websocket
support
in
the
nat
server.
We've
got
a
websocket
client
number
of
leaf
nodes.
A
A
A
A
A
Okay,
so
some
questions
that
I've
been
asked
is:
does
nasa
count
for
a
client
dropping
away
in
this
in
the
load
balance
setup,
we'll
retry,
another
client.
It
really
depends
on
whether
you're
using
cornets
or
streaming
with
cornets
that
that
happens
at
the
application
layer.
So
you
make
a
request
into
a
service
and
that
request
might
time
out
and
then
you
would
try
retry
the
request
on
the
back
side,
if,
let's
say
you're,
responding
to
the
request,
your
application
drops
crashes.
What
have
you
that
request
will
simply
remain
unfulfilled?
A
It's
up
to
the
requester
to
retry
with,
if
you
do
use
persistence
and
it's
it's
kind
of
an
anti-pattern
with
request
reply,
but
persistence
will
retry
q
subscribers.
So
if
you
use
jet
stream
or
not
streaming
it'll
retract,
you
subscribers
one
more
note
about
low
balance.
Q
subscribers
is,
we
do
have
an
api
to
gracefully
exit.
Where
you
drain
a
connection,
you
let
the
net
server
know
hey
I'm
going
away,
and
then
you
continue
to
process
the
rest
of
those
messages.
A
Another
question:
what's
the
difference
between
nets,
jetstream
and
kafka,
this
is
a.
We
could
spend
a
lot
of
time
on
this
at
a
high
level.
I'll
say
that
they're,
both
log-based
persistence,
jetstream,
has
pull
models
and
push
models,
but
what
I,
what
I
would
encourage
you
to
do
is
join
our
slack
group
and
you
know
and
ask,
and
we
can
go
in
depth
and
learn
more
about
your
use
case.
To
to
further
just
differentiate
is
jet
stream
already
available.
A
Next
question:
when
a
new
subscriber's
created,
can
it
retrieve
historical
messages
from
a
stream
or
only
messages
from
that
point
and
time
going
forward?
It
can
do
either.
So
you
can
create
a
new
subscriber
and
say:
hey
replay
me
everything
you
have
and
whether
it's
from
the
beginning
of
history
or
the
last
hour
or
you
can
create,
what's
called
a
durable
subscriber
and
a
durable
subscriber,
just
picks
up
where
it
left
off.
So
that's
that's!
Really!
A
Your
choice
and
with
jetstream
one
really
cool
feature
is
that
you
can
replay
messages
with
a
temporal
context
in
that
it
will
replay
messages
in
the
same
burstiness.
If
you
will
at
the
same
rate,
it
was
originally
the
messages
originally
arrived,
which
is
really
good
for
for
stress
testing,
for
qa
and
just
in
case
that
you
do
need
to
know
the
the
rate
that
messages
are
coming
in.
A
No,
it's
not
so
when
you
scale
up,
let's
talk
about
two
cases.
First,
you're
scaling
up
servers
when
you
scale
up
servers,
the
servers
talk
to
each
other
and
they
they
gossip
and
they
they
share
their
topology
with
each
other.
This
topology
is
also
shared
with
the
clients.
So
a
client
can
receive
this
information
about
the
new
server
and
it
knows
how
to
connect
to
it
then
so
the
client
can
originally
could
fail
over
to
a
server.
It
was
never
originally
configured
with
in
terms
of
clients.
A
All
the
client
needs
to
do
is
connect
to
to
net.
So
let's
say,
I'm
scaling
up
a
service.
I
wrote
when
the
service
connects
there's
location,
transparency
in
nets,
so
you
only
really
care
about
the
subject,
not
necessarily
where
that
service
is
located.
In
fact,
that
service
might
not
even
be
in
kubernetes,
if
you
have
a
leaf
node
deployment
outside
of
kubernetes
leafed
in
it
can
be
there
all
that
is
entirely
transparent
to
your
applications.
A
A
Could
you
shed
more
light
on
what
applications
need
to
do
to
ensure
no
event
is
lost,
so
in
jet
stream?
It's
as
simple
as
enabling
jet
stream
turning
it
on,
and
what
will
happen
is
jet
stream
will
re-deliver
messages
that
are
not
acknowledged
by
the
application.
So
that's
really
your
decision,
whether
to
use
cornets,
which
is
fire
and
forget,
or
to
use
jetstream,
which
provides
persistence.
A
How
does
gnats
compare
to
kafka?
In
your
opinion,
this
is
a.
This
is
a
very.
This
could
be
a
very
long
conversation
in
in
at
a
high
level.
Kafka
is
really
just
a
public
subscribe
system.
Nats
has
the
request
reply
on
top
of
that,
so
nance
is
a
little
different
there
in
terms
of
persistence,
kafka's
log
based
gnats
is
log
based
when
you
enable
persistence,
so
they're
they're,
very
similar.
A
There
there's
some
feature
differences
here
and
there
generally
kafka
has
more
features
right
now,
as
we
add
web
assembly,
we're
going
to
be
able
to
match
those
features,
just
in
a
very
in
a
different
way
and
be
able
to
provide
the
same
business,
be
able
to
solve
the
same
business
problems
just
in
a
slightly
different
way,
but
generally
in
terms
of
kafka
and
gnats.
We
tend
to
like
to
think
of
things
as
it's
an
and
conversation,
so
users
can
choose
to
use
gnats
on
their
own.
A
A
A
Well,
basically,
that's
if
you
already
have
a
solution,
that's
using
cloud
events,
then
you
can.
You
know
you
have
that
schema
by
default.
Nance
is
payload
agnostic.
It
will
just
send
a
series
of
bytes
it's
up
to
your
applications
to
agree
upon
what
format
those
come
in
cloud.
Events
provides
a
really
really
nice
way
to
define
hey
here's,
what
an
event
looks
like
here's,
what
it
means,
here's,
what
these
fields
mean
and
when
you
add
cloud
events
into
nets,
you
enrich
gnats
to
provide
that
that
schema,
that
meaning
behind
messages.