►
From YouTube: Intro: NATS - Colin Sullivan & Wally Quevedo, Synadia
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: NATS - Colin Sullivan & Wally Quevedo, Synadia
Join members of the NATS team to learn about NATS Messaging! Distributed systems architecture has been disrupted via decomposition as cloud technology has matured - we’ve seen a migration from monolithic applications to microservices. This has created a need for multiple communication patterns, location transparency, and the decoupling of data producers and consumers. NATS is a cloud-native messaging project that addresses these needs and others. 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!
To Learn More: https://sched.co/Grbt
A
Well,
it's
about
time,
we'll
get
started.
Hey
I
want
to
thank
everybody
for
coming
appreciate
your
time,
and
this
is
introduction
to
Nance.
My
name
is
Colin
Sullivan,
I'm,
product
manager
of
Nats
and-
and
we
actually
have
Derek
here
who
can
answer
questions
after
the
presentation,
Derek's
a
creator
of
Nats.
So
let's
get
started.
So
what
is
messaging
just
to
start
at
a
higher
level
messaging
is
message
Orion
middleware,
which
is
software
hardware?
A
That's
it's
an
infrastructure
that
supports
sending
or
receiving
messages
between
distributed
systems
or,
as
some
of
described
it's
the
intersection
of
the
stuff
that
network
engineers
don't
want
to
do
with
the
stuff
that
application
developers
don't
want
to
do.
Why
do
we
need
messaging
well,
developing
and
deploying
applications
in
distributed
systems?
It's
really
hard.
It
is
very
complex.
Master,
join
and
middleware
vendors
provide
a
set
of
basic
features
to
make
this
easier,
and
these
can
include
multiple
message
patterns,
bundled
in
one
tack,
location,
transparency
and
the
decoupling
of
data
producers
and
consumers.
A
This
means
I,
don't
need
to
know
exactly
where
the
application
that's
sending
me.
Data
is
I,
don't
even
need
to
know
what
that
application
is,
and
vice-versa
I
don't
need
to
know
where
I'm
sending
the
data
or
who's
going
to
consume
it.
In
fact,
I
should
never
even
assume
who's
going
to
consume
the
data
and
built-in
load
balancing,
so
messaging
systems
have
been
really
successful
over
the
last
thirty
years
in
providing
features
like
these,
some
messaging
systems
have
a
subset
of
these
features.
A
Some
have
all
of
them,
but
messaging
has
been
designed
to
meet
the
needs
of
the
day.
It
was
originally
developed
for
static
systems
where
you
knew
exactly
what
was
running
where
software
ran
on
servers
with
long-lived
addresses.
Configuring
endpoints
was
onerous
and
infrequent,
and
that's
because
scaling
required
manual,
positioning
of
hardware
and
software
you
had
to
go
put
a
machine
in
a
server
room
that
also
meant
deployments
were
smaller
and
systems
were
file
siloed.
A
These
static
systems
were
very
predictable
and
that
allowed
resiliency
to
be
built
by
shoring
up
the
weak
parts
of
the
system,
but
with
an
emphasis
on
individual
servers
and
individual
clients.
Most
messaging
products
today
carry
this
legacy,
but
things
have
changed.
Technologies
matured,
these
these
old
monolithic,
apps
that
you
haven't
been
decomposed
into
micro
services.
A
Lightweight
communications
are
needed
now
for
micro
services,
edge
and
endpoint
devices.
We
need
a
resiliency
with
an
emphasis
on
the
health
of
the
system
as
a
whole,
not
individual
components.
We
need
ease
of
use
and
ease
of
deployment
for
CI
CD.
We
need
really
really
easy
and
low
touch
operations.
We
need
to
be
highly
scalable
with
built-in
load,
balancing
and
very
little
configuration,
and
we
need
identity
and
security.
That's
consistent,
end-to-end
from
edge
devices
to
back-end
services.
Nats
was
created
specifically
to
meet
these
needs.
A
So
what
is
net
Nance
is
an
eight
year
old
production
proven
cloud
native
messaging
system.
Nance
was
designed
to
be
easy.
It's
for
developers
and
operators
so
just
want
to
spend
their
time
doing
their
jobs.
They
don't
want
to
spend
their
time
having
to
learn
about
messaging
or
manage
messaging.
So
the
DNA
of
Nats
is
simplicity,
performance,
security
and
availability.
It
was
built
from
the
ground
up
to
be
cloud
native.
Nat
supports
multiple
qualities
of
service,
at
least
once
and
at
most
once
messaging
support
from
multiple
communication
patterns
and
we've
got
over
30
client
languages.
A
Nats
was
created
by
Derrick
Collison
Derek's
been
solving
these
hard
problems
and
distributed
computing
for
over
25
years.
He
was
SVP
&
chief
architect
at
TIBCO,
a
technical
director
at
Google.
He
Derick
architect
at
cloud
foundry.
That
was
actually
where
NASA
was
born.
He
was
CTO
and
chief
architect
of
VMware,
founder
and
CEO
of
Apps
era,
and
currently
founder
and
CEO
at
cinavia.
Derek
has
built
a
highly
experienced
messaging
team
around
NAT,
so
we've
got
over
a
hundred
years.
A
Experience
specific
to
messaging
and
we
have
a
very
engaged
user
community
I
was
I,
was
really
surprised
to
discover
this.
When
I
looked
on
dub
stats
for
CN
CF
that
over
the
last
eight
years,
we've
had
over
a
thousand
different
contributors
and
there's
over
a
hundred
with
more
than
ten
commits.
We've
got
thirty
over
thirty
public
repos
we're
getting
close
to
36
million
nat
server,
docker
hub
pulse
and
25
million
that
streaming
server
pools,
I'm,
really
hoping
after
Kubb
con
will
break
a
thousand
Nets.
A
A
Nets
is
used
in
cloud
messaging
as
a
micro
service
is
transport
or
control
plane
for
serve
service,
discovery
and
event
sourcing.
We
also
find
Nats
being
used
in
IOT
and
edge
mobile
and
big
data
masses
used
for
high
fan-out
messaging
and
we're
finding
that
people
want
to
augment
or
replace
their
legacy
messaging
with
Nats.
We
get
a
lot
of
requests
for
bridging
to
other
technologies.
A
We
have
really
great
integration
with
kubernetes.
Through
our
Nats
operator.
The
Nats
operator
will
be
installed
that
automatically
creates
network
services
automatically
clusters
NAT
servers
which
isn't
hard
to
do
to
begin
with,
but
it
does
a
lot
of
other
things
as
well.
It's
got
authorization
with
service
accounts,
so
you
can
tie
into
kubernetes
authorization.
Any
sort
of
configuration
is
stored
as
secrets
and
anytime.
You
update
the
configuration
the
Nats
operator
will
reload
the
NAT
servers
for
you.
It's
a
hot
reload.
A
A
Let's
talk
a
little
bit
about
messaging
patterns
where
we've
got
publish/subscribe
load
balance
cue
subscribers
and
request
to
reply.
But
before
we
understand
these
messaging
patterns,
we
need
to
understand
what
subjects
are
a
subject
is
simple:
it
just
it's
a
string
that
represents
interest
in
data,
so
a
simple
subject:
foo,
if
I
publish
a
message
on
foo,
any
subscriber
who
says
I'm
gonna
subscribe
to
foo
will
receive
that
data.
A
It
can
be
hierarchically
tokenized,
where
you
can
string
tokens
together
in
a
subject
and
that
allows
you
to
create
wildcard
subscriptions
where
this,
the
star
operator
and
the
in
a
subscription
will
match
a
particular
token
or
greater
than
will
match
any
token
anything
beyond.
So,
for
example,
food
at
star
will
match
food
at
bar
and
food.
A
pass
foo
star,
dot
bar
will
match
foo
dot,
something
dot
bar
and
food
at
bar
matches.
A
So,
with
the
publish/subscribe
pattern,
you
publish
a
message
to
a
subject
in
one
to
end
subscribers.
However
many
you
have
will
receive
that
message.
This
is
used
for
high
fan-out,
it's
used
for
specialization
or
parallelization
of
work.
So,
for
example,
you
might
have
one
subscriber
that
updates
a
log
another
one
that
will
upon
receiving
the
same
message
will
update
a
UI
and
a
third
one.
A
Let's
say
it's
sensor:
data
might
trigger
an
alert
of
some
sort,
and
then
we
take
that
and
we
we
tweak
it
a
little
and
we've
got
a
load
balance
cue
pattern,
so
you
poke
when
you
create
subscribers,
you
can
optionally,
add
them
to
a
group
and
when
a
message
is
published
to
these
subscribers,
one
of
that
group
will
receive
it
and
this
this
happens
randomly
in
cornets
and
that
streaming
uses
a
little
bit
of
intelligence
and
which
message
it
sends
it
to.
But
this
is
used
for
low,
balancing,
auto
scaling
and
lame-duck
mode.
A
We
also
have
a
request
reply:
API
and
those
are
available
to
most
clients,
but
because,
under
the
hood,
everything
in
Nats
is
a
subject.
When
we
do
request
reply,
it
operates
over
unique
subjects,
but
that
lets
us
use
some
of
these
optimizations
to
to
build
some
really
interesting
request
reply
patterns,
so
you
can
request
reply
to
mini
and
you
tell
the
NAT
server
I
only
want
one
response.
A
The
first
response
that
comes
in
will
be
handled
and
passed
back
to
the
client
and
the
net
server
will
unsubscribe
circuit
breaking
preventing
that
message
from
propagating
any
further
that
gets
you
the
lowest
latency
response.
You
can
respond
with
cue
subscribers
to
load
balance.
So
if
my
reply
err
my
message,
my
replying
application
isn't
performing
and
isn't
giving
me
the
the
response
times.
I
need
all
I
have
to
do
is
scale.
All
I
have
to
do
is
launch
another
instance
of
this
it'll
subscribe.
A
Well,
let
the
net
server
know
it's
part
of
this
group
and
start
receiving
messages.
What's
really
important
here
is:
there's
no
config
changes.
This
is
automatic.
You
just
launch
another
instance
and
supported
clients
also
provide
a
drain
API.
This
allows
you
to
do
graceful
shutdown
to
eliminate
any
sort
of
data
loss,
it's
great
for
downward
scaling
and
great
for
upgrades.
So
you've
got
your
load
balance
cue
subscribers
and
instead
of
just
closing
your
connection,
you
drain
and
drain
unsubscribes
processes,
the
rest
of
the
messages
and
then
closes
your
connection
allowing
for
a
graceful
shutdown.
A
A
We
get
there
by
by
being
smart
and
what
decisions
we
make
in
the
design
decisions.
So
we
designed
for
scale
anytime
we're
looking
at
making
a
change
say
what
happens
if
we
multiply
this
by
million
or
and
also
we
take
a
very
careful
analysis
of
the
fast
path.
So
as
we
watch
how
messages
will
flow
through
the
server
say,
are
we
adding
a
lock?
Are
there
going
to
be
additional
members
these,
and
then
we
also
performance
test?
A
Every
change
to
make
sure
we
maintain
this
speed,
but
just
as
important
as
these
decisions
to
make
things
fast
are
what
we've
decided
not
to
implement
and
people
have
asked
for
these.
You
feel
kind
of
bad
saying
no,
but
it's
not
part
of
cornets.
It's
not
part
of
our
tenants.
So
we
don't
have
any
message:
guarantees
and
cornets.
A
We
don't
support
transactions,
we
don't
support
message.
Schemas
things
like
last
will
and
testament
or
JMS
message
groups,
because
that
doesn't
fit
into
the
performance
characteristics
characteristics.
These
are
things
that
can
happen
outside
of
Nats
in
your
application
or
at
a
higher
level
and
NAT
streaming.
A
Nats
is
really
lightweight
and
scalable.
We've
had
one
user,
actually
RI
pannier
actually
he's
a
maintainer.
Now
he's
joined
us
and
it
took
him
90
seconds
to
pull
50,000
nodes
with
Nats
and
get
responses
back.
We
worked
with
him
and
we
got
that
down
to
1.8
seconds,
to
pull
50,000
nodes
and
get
all
the
responses
back.
A
I'm.
Sorry,
oh
yeah,
it's
under
a
second
now
and
Nats
prioritizes
the
health
and
availability
of
the
system
as
a
whole
over
any
individual
client
or
server
and
and
I
call
this
selfish
optimization.
So
when
a
client
is
not
consuming
fast
enough,
a
coronets
client,
the
NAT
server
will
actually
cut
that
client
off
because
in
the
cloud,
what
do
you
want?
You
don't
want
a
service
and
unhealthy
client.
You
want
to
cut
it
off.
Have
an
operator
take
a
look
at
it.
Maybe
it's
restarted.
A
We
have
full
mesh
clustering
of
Nats
servers,
which
means
any
server
can
go
down
and
the
rest
just
take
over
clients
will
automatically
failover
to
new
servers
and
servers
and
clients
their
connections
self-heal
in
that
they
try
to
recreate
the
connections
to
them
to
existing
servers
or
even
new
servers
they
might
have
discovered
Nats
is
extremely
resilient.
This
simplicity
allows
us
to
be
very,
very
resilient
at
scale,
even
though
we
plan
for
the
worst.
A
Nantz
is
simple:
it's
a
single
binary
with
about
under
10,
megabyte
docker
image,
no
external
dependencies.
We
have
a
text-based
protocol
with
just
a
handful,
verbs
and
and
just
to
clarify.
While
the
protocol
itself
is
text
base,
it's
really
simple,
so
you've
got
pub/sub
message,
connect
info,
the
payloads
are
binary
and
what
this
allows
you
to
do
is
send
a
message
of
any
sort
of
type,
but
with
the
text-based
protocol
it
makes
it
extremely
easy
to
develop
clients.
That's
why
we
have
over
30.
A
We've
got
a
lot
of
contributions
and
clients,
I
mean
someone
just
started
a
dart
client
for
us,
it's
very,
very
low
config,
so
clients
only
need
at
your
own
credentials.
Servers
will
auto
discover
and
you
can
share
your
configuration
files
amongst
servers
in
the
cluster
so
that
you've
got
one
source
of
truth
for
things
like
authorization
or
policy
and
a
very,
very
simple,
straightforward,
API
I
mentioned
Auto
discovery
a
bit
earlier,
so
Auto
discovery
is
where
the
NAT
servers
will
detect
topology
changes
and
share
this
with
each
other.
A
So
let's
say
you
have
a
cluster
of
three
servers
and
you
want
to
scale
up.
You
add
another
server,
you
direct
it
to
any
one
of
those
three
running
servers.
They
all
exchange
information
about
each
other
and
suddenly
you've
got
a
full
mesh
with
four
you've
got
four
in
your
cluster.
This
happens
transparently
to
clients
they
don't
they
don't
have
to
have
any
configuration
updates.
This
actually
happens
transparently
to
servers.
They
don't
need
any
configuration
updates
as
well,
but
there's
more
so.
This
topology
information
is
also
passed
to
the
clients.
A
That
means
the
clients
can
then
connect
to
servers.
They
were
never
originally
configured
with
now.
Imagine
this
in
a
situation
with
a
rolling
upgrade
or
you
want
to
move
regions.
You
can
simply
launch
new
servers,
build
your
cluster
across
across
regions
and
drop
your
old
servers
and
the
clients
just
simply
reconnect
to
the
new
new
cluster.
They
don't
even
really
notice
a
difference.
A
We've
got
a
very,
very
simple
API
where
we
connect,
we
publish,
send
a
series
of
bytes
flush
and
the
flush
is
just
in
this
example.
Just
to
show
that
you
can
flush
a
message
to
get
lower
latency
and
here's
the
Java
API.
That
would
receive
this
message.
So
you
subscribe
on
demo
net
simple
subject
just
print
out
a
message
after
you
create
a
connection.
That's
it
NAT
supports
two
different
delivery
modes,
so
I've
been
speaking
a
lot
about
Coronets,
which
is
the
basic
installation
and
apps
that
provides
that
most
once
delivery.
A
So
there's
no
there's
no
guarantee
messages
can
be
lost.
Applications
have
to
detect
and
handle
messages
sounds
fragile.
It's
really
not
it's!
How
the
internet
works
today,
but
then
some
people
need
more.
On
top
of
that,
we
provide
at
least
once
delivery,
which
is
NAT
streaming,
where
a
message
will
always
be
delivered
and
in
certain
cases
that
will
be
delivered
more
than
once.
Generally
I
mean
those
are
always
failure
cases.
A
A
So,
with
NAT
streaming
is
a
data
streaming
system
that
sits,
sits
on
top
of
Nats.
It
provides
at
least
once
delivery.
You
can
replay
messages,
so
you
can
replay
the
last
hours
worth
of
data.
That's
been
received
or
give
me
everything
since
sequence
number
10,000.
It
can
also
provide
a
last
value.
Cache
an
application
comes
up,
hey
I
just
want
the
last
message
that
was
sent.
You
have
durable
subscribers
where
subscribers
are
receiving
a
stream
of
data.
If
anything
bad
happens,
whenever
things
were
turned
back
to
normal
you'll.
A
Just
pick
up
right,
where
you
left
off,
we've
got
rape
matching
per
subscriber
different
types
of
storage,
including
memory
file
and
database.
We've
got
a
couple
different
ways
to
configure
fault
tolerance
through
full
clustering
or
a
fault
configuration,
and
you
can
scale
through
partitioning
now
we're
going
to
talk
about
some
of
the
newer
features
with
Nats
global
deployments.
So
this
is
new.
Actually,
the
changes
here
are
in
master
branch
right
now,
we'll
be
cutting
a
release
pretty
soon
so
we've
got
super
clusters
imagined
clusters
of
clusters
of
Nats.
It
uses
a
spline
based
technology.
A
We
use
optimistic
sense
and
interest
graph
pruning
and
also
provide
intelligence
support
for
geo
distributed
cue
describers.
That's
that's
actually
really
interesting.
So
remember,
I
was
talking
about
the
cue
subscribers
where
you
send
a
message
and
I'll
randomly
send
to
one
of
the
subscribers
to
load-balanced.
Well,
it
can
be
smart
geographically.
A
So
what
this
does
is
this:
this
separates
this
bifurcates
technology
from
business
driven
use
cases,
people
used
to
silo
data
because
of
software
and
hardware
limitations.
This
is
no
longer
the
case.
You
can
silo
data
if
you
want
geographically
or
you
can
silo
data
with
accounts
horizontally
across
the
global
deployment.
It's
easy,
secure
and
cost-effective,
because
one
Nats
deployment
there's
one
Nats
deployment
for
operators
to
manage,
and
it's
decentralized,
so
we've
built
accounts
to
be
decentralized,
so
different
account.
A
Administrators
can
self
manage
and
I'll
talk
a
little
bit
more
about
that,
but
you
can
share
data
between
accounts
with
secure
streams
and
services,
and
only
mutual
agreement
between
these
accounts
will
allow
this
data
to
flow.
So
services
are
secure,
RPC,
endpoint,
RPC
again.
A
request
to
reply
is
that
one-on-one
conversation
a
phone
call
and
you
can
have
two
accounts.
You
want
to
open
up
a
service,
the
other
one
will
import
the
service
and
then
they
can
talk.
A
You
have
streams
as
well,
which,
instead
of
a
request,
reply
pattern.
That's
your
published
pattern.
That's
published
subscribed,
so
the
stream
of
data
can
flow
through.
But
what's
what's
really
really
cool
about?
This
is
within
an
account.
The
subject
namespace
is
isolated.
So
if
I
have
two
applications
in
account,
a
that
are
publishing
on
foo
no
subscriber
and
account
B
will
receive
foo
unless
you
create
a
stream
to
allow
that
to
flow
through.
All
this
is
transparent
to
clients.
There's
no
client
configuration
or
client
API
API
changes
to
get
this
Nance
is
secure.
A
We
have
authentication
and
Cripps
encryption.
You
can
set
some
policy
and
we've
got
subject
based
authorization.
You
can
update
these
in
the
server
anytime,
with
a
hot
with
a
hot
reload
and
clients.
Don't
really
notice
the
difference
unless
they're
affected
by
the
policy
change.
We
support
TLS
with
CH
certificate
support,
client
certificate
support.
Tls,
one
three
is
coming
soon.
We
have
n
keys
that
you
can
use
as
identities.
These
are
82
five,
five,
one,
nine
keys
that
we've
made
very
easy.
They
serve
as
identities
in
the
net
server
and
will
continue
to
support
user
password.
A
You
can
be
crypt
password
than
storage,
so
shouldn't
administrator
look
at
a
config
file.
They
still
won't
know
what
the
password
is
so
n
keys
are
a
new
Nats
identity
and
authentication
and
authorization
system
are
actually
just
a
authentication
system,
but
they
can
be
used
with
authorization.
So
again
there
edie
two
five:
five
one:
nine
keys,
they're
very
fast
and
resistant
to
side-channel
attacks.
A
You
can
sign
and
verify
with
these,
which
allows
a
new
form
of
authentication
where
a
client
where
a
client
connects
to
the
server
the
server
sends
a
nonce
back,
which
is
just
random
bytes
that
are
salted,
and
then
the
client
signs
that,
with
this
private
key,
sends
that
back
to
the
server
and
the
server
checks
to
make
sure
that
the
client
identity,
the
client
is
who
they
say
they
are.
And
what
this
does
is
this.
This
allows
the
net
server
to
operate
and
never
have
to
maintain
private
keys.
A
Only
the
public
keys
of
the
client
you
can.
You
can
encapsulate
these
JW
TS
that
will
associate
users
and
accounts
and
permission
sets
with
this
N
key
identity.
We
support
encryption.
You
encrypt
through
TLS,
we
default
to
the
most
secure,
cipher
suites.
You
can
override
encryption
to
define
a
list
of
ciphers,
elliptical,
curves
and
NAT
streaming
in
key
one
is
going
to
support
encrypting
data
on
disk.
A
We
have
subject
based
authorization,
which
is
who
can
control?
You
can
control,
who
can
publish
and
who
can
subscribe
to
different
subjects,
and
you
can
use
wildcard
support
and
we
also
have
allow
or
deny
clauses
which
provides
a
lot
of
flexibility.
You
can
actually
generate
some
pretty
complex
authorization
scenarios
with
very
terse
configuration.
This
way
like
everything
else
in
Nats,
we
go
for
simplicity,
monitoring
is
very,
very
simple:
each
server
is
monitored
independently,
it
returns
JSON
and
the
simplicity
allows
you
to
build
really
complex
tools.
A
On
top
of
it,
we've
got
integration
with
Prometheus
that
allows
aggregating
and
alerting
on
Nats
for
various
server
events,
where
Prometheus
we've
got
a
Prometheus
exporter
that
just
takes
us
JSON
and
serves
it
up
in
a
way
that
Prometheus
likes.
We
also
have
an
ATS
top
tool
that
was
written
by
Wally
right
here
in
the
audience,
which
is
a
really
really
handy
tool
that
that
takes
this
JSON
presents
it
in
a
way.
That's
that's
very
familiar
to
Linux
users
in
production
monitoring.
A
We
advocate
that
you
use
the
Prometheus
exporter
of
Prometheus
server
to
generate
alerts,
and
then
you
can
put
a
dashboard
in
front
of
it.
This
is
what
one
looks
like,
so
we'll
go
run
through
some
upcoming
features.
We
we
get
a
lot
of
requests
for
other
messaging
product
integrations,
so
we're
looking
at
integrating
with
MQ
series,
but
then
we're
also
looking
at
an
integral
integrating
with
Kafka.
We've
got
data
at
rest,
encryption
and
streaming
we've
got
project,
we
call
it
project
jet
stream,
it's
an
app
streaming
version.
A
2.0,
it's
gonna,
bring
some
more
tightly
integrated
streaming
solution
to
Nats
and
some
some
really
cool
features.
Mq
cheechee
is
ubiquitous,
I
mean
it's.
Nasa
is
a
great
use
case
for
IOT
being
as
lightweight
performing
as
it
is,
and
we
are
going
to
support
MQTT
natively,
we're
gonna,
add
WebSocket
support
and
we're
gonna
develop
some
microcontroller
clients.
A
We
welcome
contributions
of
all
kinds.
Some
ways
to
contribute
are
blogs.
You
can
fix
a
bug
if
you
find
anything
in
our
documentation,
please
let
us
know,
and
even
some
more
submit
a
PR
for
us.
You
can
propose
features
or
present
your
Nats
product
project
at
meetups.
If
you
do,
let
us
know
well,
send
you
swag.
So
let's
do
a
quick
demo
whoops.
A
A
It
starts
up
in
this
case.
50
simultaneous
requests
that
is
trying
to
pound
on
a
reply
err,
and
it
sends
this
request
and
just
record
how
long
it
takes
I
have
a
reply,
err
that
connects
to
Nats
and
it
simply
queue
subscribes
and
then
sleeps
for
a
period
of
time
simulating
a
50,
millisecond
workload.
A
I've
had
this
running
and
kubernetes
with
the
Nats
operator
and,
let's
let
me
refresh
this
I've
had
this
in
kubernetes
with
the
Nats
operator,
so
here's
the
Nats
operator,
we've
gotten
for
free
refine
on
Prometheus.
Just
so
I
can
visually
show
you
what's
going
on,
we've
got
a
requester
and
one
reply
right
now.
If
we
look
at
our
statistics,
this
is
what
is
being
returned.
A
You
can
see
we're
handling
about
20
requests
per
second
we're
averaging
or
we're
getting
about
two
and
a
half
second
average
response
time,
which
is
about
right,
50
milliseconds
by
50
requests
at
the
same
time,
and
you
can
see
pretty
steady
with
latency
between
two
and
four
thousand
two
and
four
seconds.
So
what
we're
going
to
do
is
without
any
config
changes
we're
going
to
scale
the
reply.
Err.
A
So
we
scale
the
reply.
Err
up,
if
you
remember
when
I
was
talking
before
what
we've
done
is
just
launched,
10,
more
or
nine
more
instances
of
this
reply
err
so
now,
when
the
requester
is
sending
its
requesting
the
servers
randomly
sending
these
requests
to
requires.
So
if
we
look
at
what's
happening.
A
A
You
can
see
with
the
latency
histogram
here
you're
now
in
the
128
to
256
millisecond
response
time,
even
down
as
low
as
32
milliseconds
in
some
cases
on
average.
These
are
these
are
some
of
the
off
hits,
and
all
this
was
done
with
a
very,
very
simple,
cue,
subscriber
and
a
click
of
a
button
to
scale.
A
B
When
you
start
up
and
form
a
connection,
you
can
unconnect,
you
can
tell
the
server
if
I
go
away.
Send
this
message
on
my
behalf,
saying
I
work
ladybug
is
something
that
the
first
time
I
heard,
which
says
instead
of
just
taking
a
server
out,
take
it
out,
say:
hey,
stop
accepting
new
stuff
but
bring
everything.
B
So
a
lot
of
these
techniques
I
think,
are
extremely
effective
and
keep
you
had
at
most
once
deliveries
panels,
so
that
firing
forget
that
attack
supportive,
so
lightweight
with
brain
mode.
We
can
run
crazy
tests
or
Auto
unsubscribing
me
killing
me
going
down
up
and
everything
and
not
a
single
messages.
Every
drop,
that's
not
to
say
that
it
can't
happen
or
something
underneath
of
us.
It
changes,
but
it
makes
extreme.
B
B
It's
a
good
story
together,
Colin
and
I
have
done
a
couple
trips
already
this
year.
People
who
have
large
investments
know
what
happens
is
whenever
you
pick
a
technology
and
kind
of
go
all
in
on
it.
One
of
two
things
happen:
one's
a
very
small
sense,
which
is
the
other
which
usually
happens,
is
like
well
we're
pretty
good
for
this,
but
then
we
decided
to
so.
What
we
were
seeing
is
a
lot
of
people
said
we
like
the
concepts
of
streaming
and
location
replay.
B
C
B
B
Who
copy
as
far
as
I
know,
we
hear
a
lot
and
what
we
tried
very
hard
not
to
do
is
we're
gonna,
make
a
change
on
the
server
and
you're
going
to
change
all
your
clients
now
with
figuration
and
upgrade
like
that,
so
even
with
the
new
technology
that
Colin
was
talking
about
with
what
we
call
NGS
your
conscious,
still
work.
This
is
the
codes.
Don't
just
doesn't
see
much
messages
now.
B
Very
intelligent
replication,
but
not
on
the
gist
google,
gfs,
/r
5
or
whatever
type
thing,
which
is
usually
kind
of
wasteful,
so
we're
trying
it
and
they
got
much
better
at
it
after
I
left.
But
we're
trying
to
do
some
really
interesting
things
there
and
stay
committed
to
the
the
philosophy.
That
is
just
easy,
but
it
does
everything,
predictably,
but
the
things
you're
supposed
to
be
doing
like
security
and
things
like
that.
B
B
So
the
question
is
on
Io
te
and
do
you
want
all
of
the
data
I
think
that's
a
great
question.
I,
don't
know
if
it's
a
specific
Nats
question.
What
I
think
it
is
is
what
type
of
data
are
you
generating?
How
big
is
it?
What
is
the
cost
to
transport
it?
Let's
say,
for
example,
from
an
endpoint
to
the
cloud
versus
an
edge
IOT
gateway
versus
gossiping
between
themselves.
We
want
Nats
to
be
the
enabler
of
that.
B
So,
if
you
notice,
when
Colin
was
talking,
the
net
server
already
runs
on
like
raspberry
pies
and
arms
and
stuff
and
we're
gonna
push
into
microcontrollers,
especially
for
clients,
but
I
think
those
types
of
questions
are
more
about.
How
do
you
design
a
system?
You
know
a
full
end
and
distribute
system
to
achieve
what
you
want,
and
we
just
want
to
be
part
of
the
story.
Now,
we've
all
done
these
systems
before
so
we
have
opinions.
B
B
Everything
is
just
keep
pushing
further
out,
so
right
now
and
I
think
of
very
end
point
type
things
I'm,
actually
starting
to
think
of
extremely
restricted
communication
channels
and
probably
battery-powered,
which
might
not
be
what
you
would
say
was
you
know,
as
IOT
I'm
saying
that
a
lot
of
the
consumer
electronics
is
in
your
house
actually
probably
or
more
edge,
not
necessarily
IOT
anymore
right,
I
mean
they're
running
on
processors,
faster
than
I
went
to
school
with
you
know
in
the
80s.
Oh
yes,.
C
B
Using
things
like
Kafka
and
streaming
to
represent
a
global
state
so,
for
example,
what
we
always
used
to
put
in
the
database
now
people
are
saying:
oh
replay,
all
the
messages
and
the
events,
and
then
you
come
up
with
the
same
state
and
it
was
not
applicable
for
that.
You
know:
I
see
sometimes
architectures
that
I
kind
of
go
yeah
that
that
kind
of
makes
sense,
I
get
it
more
often
than
not.
I
look
at
it
and
I
go
I.
B
Just
wouldn't
do
it
that
way,
not
to
say
that's
right
or
wrong,
and-
and
we
have
these
conversations
all
the
time
and
it's
always
a
transition
from
development
to
to
operations
which
sounds
like
it
should
make
a
lot
of
sense.
But
what
I
mean
is
is
most
times
when
you
talk
to
developers,
you
know,
and
we
say:
oh,
we
do
blah
blah
and
they
go.
Why
all
I
need
to
do
is
ask
him
a
question.
B
I
just
need
RPC,
you
know,
step
away,
I
don't
need
any
of
your
crazy
stuff,
but
then
you
get
into
production
right
and
you're
gone
well.
Okay
and
the
golden
rule
that
all
of
us
who
have
been
doing
messaging
for
so
long
and
just
learned
it
not
it's
not
an
IQ
thing,
it's
just
the
scars
on
your
back
thing
is
never
make
an
assumption
today
when
you
send
a
message
what
the
message
can
be
used
for
tomorrow,
and
so
what
we
see
is
when
you
transition
to
ops.
B
It's
like
I'm,
still
asking
you
a
question
and
I
as
a
developer.
I
know
I'm
asking
you
a
question,
but
now
sudden
he's
moving
he's
coming
in
and
he
needs
to
do
compliance.
So
he
needs
to
see
my
request
and
his
answers
and
I
don't
want
to
change
and
he
doesn't
want
to
change
now.
Suddenly,
we
need
ten
of
him.
I
don't
want
to
be
installing
load,
balancers
and
moving
stuff,
and
now
we
want
to
move
into
a
different
cloud
and
all
geez.
B
You
know
and
everybody's
throwing
their
keyboards
nats
takes
care
of
all
of
that.
So
it
allows
you
to
transition
from
a
simple
request,
reply,
RPC
model
and
dev
into
a
production
system
where
you
can
change
that
whole
system
without
ever
changing
him
and
I
and
I
like
those
patterns
and
again
the
system
is
extremely
predictable.
So
when
you
you
make
changes
to
it,
you
know
exactly
what
it's
going
to
do.
You're
not
going
I
hope
this
works.
You
know
what
I
mean,
which
we've
all
been
there
now.
B
That
being
said,
we
are
going
to
invest
a
good
amount
of
effort
into
where
we
feel
we've
seen
those
patterns,
and
they
make
a
lot
of
sense
and
we're
trying
to
take
that
plus
a
lot
of
the
feedback
that
the
community
gave
not
streaming
and
roll
that
into
jet
stream
and
a
lot
of
the
feedback
was
it's
not.
You
went
too
far
away
from
Nats
come
back,
you
know,
I
mean
we
like
this.
B
C
B
So
the
question
is
about
Kafka's
attractiveness
and
if
I
say
it
wrong,
tell
me
I'm
wrong,
but
Kafka's
attractiveness
is
that
there
isn't
a
mat,
a
massive
ecosystem
and
a
massive
amount
of
built-in
integrations
in
connector
technologies.
Already
we
haven't
gone
down
that
path,
but
our
ecosystem
has,
and
all
of
us
on
the
team
live
that
in
the
90s,
where
all
we
did
was
tip
Co,
adaptors
and
stuff
for
like
years
on
end
and
stuff,
so
yeah
we're
definitely
we're
looking
at
that
we're
trying
to
pick
and
choose.
B
We
got
about
a
thousand
slack
members
now
and,
and
it
feels
like
a
great
ecosystem.
People
are
always
willing
to
help
each
other
out.
It
just
feels
right.
Can
it
compete
with
Kaka's
ecosystem
today?
Probably
not
but
I,
don't
know
if
I
want
to.
You
know:
I,
don't
even
like
Java
anymore,
so
I
don't
know.
Yes,.
B
Yeah,
so
the
question
is
in
superclusters
houses
the
concept
of
locality,
playing
a
role
in
the
distributed
queuing,
algorithms.
So
the
way
it
works
is
clusters
today.
So
if
anyone
is
using
ATS,
they
probably
know
about
the
clusters
that
existed
a
full
mesh,
one
hop
I've,
always
done
those
the
internet
actually
is
based
on
those
as
well,
even
though
they
don't
scale
so
they
logically
underneath
they're
full
mesh
one
hop
BGP,
and
then
you
try
to
do
weird
stuff
on
top.
Our
super
clusters
are
the
same
way.
B
B
I
know
if
there's
any
interest
locally
on
a
q
group,
and
so
if
it's
like
you're
listening
on
foo
and
you're
part
of
far,
we
do
that
when
we
fail
and
there's
nobody
home
in
that
local
cluster,
the
super
cluster
technology
that
it
bifurcates,
inbound
and
outbound,
it
does
a
spline
based
technology.
So
that
there's
no
single
point
of
failure,
there's
no
one
blessed
guy,
that's
the
one
sending
all
the
data
over.
B
B
Yeah,
so
the
question
is:
do
I
know
there's
a
scriber
over
there,
so
this
is.
This
could
be
like
a
three-hour
conversation,
but
I'll
try
to
make
it
really
short
in
in
local
clusters.
Small
clusters,
the
ones
that
exist
today-
interest
propagation
always
happens.
So
if
he
listens
to
foo
everyone,
the
cluster
knows
he's
listening
the
foo.
Now
we've
optimized
it
in
the
latest
version.
That's
on
master
such
that.
B
If
there's
a
thousand
people
listen
on
foo
the
owner
goes
over
the
wire
once
saying:
hey
someone
over
there
is
listening
on
foo,
so
it's
gotten
better
there.
That
actually
doesn't
work,
though
very
well
with
clusters
of
clusters,
and
you
know
tens
of
thousands
hundreds
out
of
millions
of
accounts,
hundreds
of
millions
of
users
to
say
yeah.
We
want
to
have
every
server
know
everything
about
the
world.
B
So
the
way,
briefly,
that
the
super
cluster
gateway
technology
works
is,
is
that
we
start
in
an
optimistic
way,
which
is
oh
yeah
I'll,
send
you
everything
and
then
you'll
prune
the
interest
rate
and
what's
nice,
is
that
when
Colin
was
talking
about
accounts,
think
of
accounts
as
like
the
containers
for
your
messaging
system,
they
put
a
little
wrapper
around
it
right
and
so
you're
kind
of
isolated
in
there.
So
if
I'm
sending
something
over-
and
he
has
nobody
even
at
home
on
that
account-
he
will
actually
not
just
prune
the
subject.
B
He'll
prune
the
whole
account
and
I'll.
Remember
that
I'm,
like
oh
okay,
fine
I,
won't
bother
you
anymore,
and
then
we
have
a
way
that,
under
degenerative
cases
where
what
we're
trying
to
do
is
minimize
the
amount
of
traffic
on
the
wire
going
back
and
forth,
but
there's
degenerative
cases
where
the
pruning
method
might
actually
start
generating
more
traffic
than
perfect
knowledge
mode.
And
so
we
Auto
switched
a
perfect
knowledge
mode.
So
he
can
go.
Hey,
stop
sending
all
this
crap
I
will
promise.
You
I'll
tell
you
what
I
want
you
to
send
me.
B
Otherwise,
don't
send
it,
and
so
the
system,
dynamically,
is
switching
all
the
time.
Based
on
that.
So
that's
a
little
bit
longer
answer,
but
it's
cool
tech
I
think
it's
pretty
neat.
Yes,
oh
absolutely,
that's
I
mean
so
the
the
yeah.
So
when
Colin
was
talking
about
the
notion
of
accounts
and
then
when
you
want
to
share
something,
he
said
two
words:
services
and
streams.
Stream
is
an
immense
stream.
It's
a
published
thing:
things
are
going
out,
I,
don't
know,
I,
don't
know
who's
out
there.
B
Who
wants
to
see
him,
but
if
you
want
to
great
services,
are
you're
gonna?
Send
me
a
request
I'm
going
to
send
you
response
an
RPC
request
reply
and
those
are
the
two
major
patterns
because
even
low
balance,
Q's
or
the
distributive
queuing
technology
is
still
a
request
replies.
Just
we
automatically
can
load
balance
without
additional
side
cards
or
load
balancers
or
any
other
goofy
tech.
So
any
others.
Yes,.
B
B
The
information
is
there
and
in
the
tech
that
we're
coming
up
with
the
ability
to
not
have
to
ask
for
information
out
of
the
system,
but
it'll
actually
push
it
to
you
is
being
introduced,
and
this
was
an
idea
that
Colin
and
others
on
the
team
had
had
and
now
that
we
have
accounts.
We
feel
that
we're
in
a
perfect
space,
because
we
can
put
that
in
a
system
account
and
then
the
system
account
has
to
say
I
will
export
this
to
you.
B
Otherwise,
you
can
never
see
that
is
saying:
hey
somebody's
listening
on
foo
or
I'm,
using
this
much
memory,
but
now
sudden
that's
all
going
around
so
I
would
imagine,
and
while
you'll
hit
me
with
his
book,
if
I'm
wrong,
we'll
start
taking
advantage
of
that
in
the
operator
sometime
in
19
such
that,
if
you
wanted
to-
and
you
told
it
hey,
listen
to
this
stuff
and
here's
the
thresholds
or
whatever
model
you
want,
and
you
can
auto
scale
based
on
that.
That's
a
lot
more
possible
now
I
think
is
that
fair?
B
B
If
you
came
along
and
said,
show
me
everything
you
can
see
everything
except
the
response.
Nats,
it's
not
like
that.
It
is
pure
pub/sub,
meaning
if
you
want
to
and
you're
allowed
to
you're
authorized,
which
by
default
you
are,
you
can
say,
show
me
everything.
I
want
to
see
all
the
requests
going.
Oh
I
want
to
see
the
responses.
I
can
measure
latency,
which
is
kind
of
what
Colin
was
showing
in
that
graph.
B
You
can
easily
say
I
see
the
latency
and
I,
don't
like
it
and
I'm
gonna
press
a
button
to
say
start
more
of
these.
That's
really
really
straightforward
with
that
and
then
I
think.
Your
other
question
was
about
monitoring.
The
original
design
of
Nats
I
took
a
lesson
from
Google
and
it
has
the
ability
to
have
var,
Z's
and
stuff
which
are
HD,
JSON
endpoints.
B
The
system,
that's
on
master,
now
that
we're
cutting
release
can
optionally
be
configured
with
a
system
account
and
as
soon
as
you
do,
that
the
system
wakes
up
and
it
starts
sending
messages
pure
Nats
messages
out
on
all
the
stuff
it's
doing
internally
and
then,
if
you
want
to,
you,
can
subscribe
to
those
either
can
service
import
them
or
stream,
import
them
or
I,
wouldn't
recommend
it.
But
you
can
give
yourself
a
user
on
the
system,
account
and
directly
look
at
them,
but
I
like
the
separation.
To
be
honest
with
you
any
others.
Yes,.
B
So
the
question
is:
do
you
have
a
time
stamp
on
the
message
and
that
synchronize,
the
the
answer
is
no
and
the
the
payloads
are
opaque
to
us.
But
that
being
said
in
the
the
last
thing
that
we've
been
working
on,
we
want
it
to
be
able
to
coordinate.
You
know
as
well,
and
so
what
we've
done
is
is
that
we,
instead
of
doing
time,
we
do
sequence
based
on
event
streams,
and
so,
if
I'll
sudden
I
get
something
out
of
order,
I
know
I
can
ignore
the
one
that
was
delivered
out
of
order.
B
So
it's
not,
as
you
know,
it's
not
like
a
vector
clock
type
of
thing,
but
it's
a
simple
mechanism
that
we
can
say.
Oh
okay,
you
know
the
message:
I
just
got
from
him
and
then
you
sent
me
one.
You
know
yours
was
old
or
I'll.
Just
you
know
if
it's
an
idempotent
feed,
which
we
always
do
so
all
of
our
our
eventing
out
of
there
is
always
item
potent
meaning.
You
have
everything
you
need
to
know
what
the
message
in
hand
and
then
we
just
added
the
sequence
number.
B
So
that's
their
spanner
window
right
for
if
there's
conflicts,
if
it's
in
that
seven
millisecond
window,
they
got
to
kind
of
figure
stuff
out,
otherwise
they're
good
to
go,
but
most
people
don't
have
that,
so
any
others.
These
are
good
questions
by
the
way.
Thank
you,
okay.
Thank
you
guys
very
much.
I
appreciate
it.