►
From YouTube: Webinar: NATS 2.0
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
NATS 2.0 is the largest feature release since the original code base for the server was released. NATS 2.0 was created to allow a new way of thinking about NATS as a shared utility, solving problems at scale through distributed security, multi-tenancy, larger networks, and secure sharing of data. In this presentation, Derek will discuss the motives behind the newest features of NATS and how to leverage them to reduce total cost of ownership, decrease time to value, support extremely large scale deployments, and decentralize security to create secure and easy to manage modern distributed systems.
B
Think
it's
time
for
us
to
kind
of
think
differently.
We
are
in
a
whirlwind
of
technology,
these
days
as
most
people
on
the
call
know
where
technologies
come
and
go
at
a
furious
pace,
but
I
believe
we're
really
in
to
the
beginning
of
the
connected
economy.
We've
moved
on
from
the
compute
economy
and
most
people
believe
we're
in
the
data
economy,
but
how
that
data
and
how
services
are
accessed
and
securely
accessed
I
believe
is
kind
of
the
becoming
age
and
that's
what
I
call
the
connected
economy,
and
this
is
where
the
largest
opportunity
lives.
B
B
What
I've
always
been
fascinated
by
is
a
pendulum
motion
of
technology,
where
we
swing
back
and
forth
and
so
I'm
confident
that
we
will
swing
back
to
simpler
times
that
were
kind
of
trudging
new
ground
and
new
technologies
and
new
features
to
deliver
better
on
the
technology
that
we
have,
but
we're
in
that
that
phase
right
now,
where
things
feel
like
they're
just
becoming
more
and
more
complex,
more
expensive
slower.
You
know
slow.
B
So
in
terms
of
connectivity,
I
believe
this
is
the
key
I
really
do
it's
not
necessarily
about
those
data's
or
the
services
or
the
compute
right,
which
was
the
major
factor
when
we're
going
through
the
cloud
revolution.
But
connectivity
now
today
is
the
key
and
we've
seen
this
in
other
industries.
This
isn't
something
that's
totally
new.
We
saw
this
with
the
internet.
We
saw
it
with
the
global
or
cellular
networks,
as
well
mostly
for
humans
right,
but
what
we
don't
have
and
what
we
lack,
in
my
opinion,
is
a
as
a
technology.
B
That's
a
true
utility
type
technology
can
connect
all
the
world
to
your
system,
services
and
devices.
I
believe
the
connectivity
needs
to
be
ubiquitous,
it
needs
to
be
a
true
utility
and
not
a
silo,
and
that's
something
that
I
think
most
people
skip,
which
is
that
most
technologies
are
silos
and
we've
seen
this
in
other
technologies
as
well.
Like
databases
where
databases
were
a
silo
for
a
certain
group
or
business
organization,
and
companies
would
have.
B
B
Have
tempies,
even
in
companies,
have
said
over
adopting
this
type
of
technology,
you'll
notice
that
there's
multiple
silos
of
these
running
and
there's
usually
an
ongoing
effort,
a
brave
effort
to
say
hey.
We
should
actually
just
create
a
utility
that
everyone
can
share,
but
the
technologies
usually
aren't
built
to
do
that,
and
to
be
honest
with
you,
when
Nats
began
its
life
almost
ten
years
ago,
it
wasn't
as
either
wasn't
either,
but
these
siloed
technologies
just
simply
cannot
fit
into
a
true.
B
B
Where
we
went
probable
to
open
up
the
world
of
e-commerce
and
banking,
and
things
like
that,
I
believe
things,
although
isolated
by
default,
meaning
Coke
and
Pepsi
and
UPS
and
FedEx
can
participate
with
the
same
infrastructure.
There
needs
to
be
a
way
to
securely
share
data
streams
and
services.
It
should
scare
scale
effortlessly
should
have
multiple
patterns,
both
services
and
streams,
data
and
event,
and
in
my
opinion,
this
technology
should
self
heal
itself.
B
It
should
be
agile,
multi-cloud,
on-prem,
edge
and
IOT
applicable
location,
transparency,
access
to
service
event,
streams
from
anywhere
in
the
world,
any
type
of
deployment
platform,
any
cloud
provider
edge
gateway
whatever
that
is,
should
not
be
defined
or
or
confined
I
mean
to
deployment
platforms
and
clouds.
It
should
be
observable
from
anywhere
meaning
it
shouldn't
have
to
run
in
a
certain
area
or
within
a
certain
framework.
B
To
then
say,
oh
I
can
observe
my
service
I,
understand,
latency
I
understand
where
a
requester
company,
where
the
latency
from
the
request
versus
the
responder
is-
and
this
should
just
simply
be
available
securely-
should
be
built
on
an
open
source
technology.
Again,
we're
part
of
the
CNC
app
and
we
believe
deeply
in
their
charter,
and
we
believe
also
in
open
ecosystems
and
decentralized
and
federated
software
as
a
service
offerings
right.
It
cannot
be
controlled
by
one
entity
or
one
company
I
think
it
needs
to
be
federated
by
design
at
the
beginning.
B
B
There
should
be
the
notion
of
location
transparency
not
being
tied
to
IPS
or
host
names,
things
like
that
decouple
producers
and
consumers.
They
should
not
have
an
awareness
of
who
they
are
outside
of
a
security
context,
meaning
I
should
know
that
by
get
a
request,
it's
secured
and
authorized
and
I
know
that
by
default,
but
I
don't
have
to
know
where
they
are
where
they're
coming
from
or
what
client
language
or,
if
they're
deployed
in
the
same
cloud.
B
Think
of
that
as
a
services
right,
I
want
to
deploy
something
I
want
to
get
an
update
on
how
much
CPU
this
this
application
is
using.
It
has
scalable
services
and
streams.
What
I
mean
by
scalable
services
is
is
that
you
can
run
endpoints
and
to
scale
them
up.
You
just
run
more
of
them.
There's
no
load
balancers,
there's
no
sidecars,
there's
no
proxies.
B
As
a
matter
of
fact,
one
of
the
things
that
the
team
is
very
proud
of
is
is
that
applications
that
were
written
almost
ten
years
ago
and
that's
as
a
mature
technology
can
still
run
on
a
modern,
Nats
2o
system.
Today,
it's
actually
been
that
backward
compatible
and
again
for
a
service
to
scale.
You
just
run
more
of
them
and
if
you
want
to
scale
it
down,
you
run
less
of
them.
All
of
this
is
just
built
into
the
system
and
you
get
it
for
free
she'd,
be
extremely
easy
used
for
developers
and
operators.
B
I
should
be
able
to
develop
an
application
on
my
workstation
or
my
laptop
and
transition
that
to
production
with
the
least
amount
of
change
and
and
friction
so
to
speak.
Even
from
the
very
very
beginning
days
when
Matz
was
built
for
Cloud
Foundry,
the
notion
of
being
highly
resilient,
meaning
it
protects
itself
at
all
costs.
It
doesn't
protect
you,
the
user,
at
all
costs
and
what
I
mean
by
that?
Is
that
there's
a
lot
of
enterprise
technology
silo
based
technologies,
that
they
call
it
the
query
of
death.
B
At
least
they
used
to
call
that
for
databases
where
a
client
application
will
ask
the
system
to
do
something
and
it
will
bend
over
backwards
to
do
that,
to
the
detriment
of
all
the
other
users.
And
when
you
start
looking
at
as
technology
as
a
utility
technology,
not
a
silo
technology,
you
know
you
need
to
start
thinking
differently
about
how
that
technology
reacts
to
inputs
from
different
users
and
for
an
as
its
core
philosophy
as
its
highly
resilient
and
protects
itself
at
all
costs.
It's
highly
secure,
extremely
lightweight.
B
You
can
run
a
full-blown
server
on
a
Raspberry
Pi
again,
Nats
has
been
around
for
almost
a
decade.
Now
it
has
clients
for
over
32
and
Counting
different
programming
languages,
and
it's
a
ciencia
product
with
a
project
with
kubernetes
and
prometheus
integrations
and
more
to
come.
Alright,
we're
adding
those
as
the
cnc
FS
grown
at
such
an
amazing
rate,
there's
new
projects
that
are
fascinating
and
interesting
and
we're
looking
at
ways
to
work
with
those
the
best
way
we
can
and
again
originally
built
to
power.
B
Cob
foundry,
but
NASA
is
applicable
not
only
in
the
cloud
multi
cloud,
on-premise
edge
or
IOT.
It's
subject
based
routing,
not
IP,
that's
a
huge,
in
my
opinion.
It's
best
based,
not
packet
or
byte
streams.
It
has
again
scalable
services
and
streamed
with
the
same
technology.
It
natively
does
end-to-end
communications
with
cue
delivery,
not
just
one
to
one.
Secure
and
isolated
is
centralized
by
design.
We'll
talk
a
little
bit
more
about
what
that
means.
B
When
you
actually
get
to
very
large
scales,
secure
sharing,
it
understands
the
notion
of
exports
of
streams
and
services
and
imports
imports.
Is
your
dependencies
exports
your
UI?
Essentially
your
interface,
it's
self-healing
and
highly
observable,
and
it's
capable
of
being
federated
as
a
global
utility
right,
a
global
dial
tone
under
a
single
URL.
It's
just
available
anywhere
in
the
world
again
secured
by
default.
B
So
the
CNC
F
landscape.
Again
this
is
an
amazing
organization
and
effort.
That
is,
it
is
growing
so
fast
that
you
know.
A
lot
of
these
landscapes
are
looking
a
little
bit
like
an
eye
chart,
and
but
we
are
in
there
or
on
the
streams
and
messaging
piece,
as
you
can
see,
the
way
seeing
set
positions.
Us
is
part
of
the
streaming
and
messaging
and
and
puts
G
RPC
in
there,
but
obviously
for
those
outside
the
CNC
F,
who
are
aware
of
Apache
and
Kafka.
B
A
B
B
Oh,
was
I
as
a
an
effort
by
a
lot
of
the
founding
members
of
the
technology
to
bring
together
something
that
could
connect
all
the
world's
digital
system,
services
and
devices,
and
that
sounds
extremely
ambitious
and
it
is,
but
we
also
look
back
at
the
notion
of
what
happened
with
things
like
the
internet
and
the
global
cellular
network,
where
the
opportunities
that
presented
themselves.
Just
by
having
this
you
know,
massive
connectivity
were
simply
unforeseen
I.
B
Don't
think
any
of
us
in
1994
would
have
understood
what
the
internet
would
look
like
and
provide
for
everyone
on
a
global
basis.
Today,
and
while
there
are
7.2
billion
people,
I
think
we've
got
almost
5
billion
people
connected
we're
going
to
be
around
75
billion
digital
system
serves
and
devices
by
2020,
and
so
the
problem
is,
is
a
lot
different,
a
lot.
You
know
much
more
massive
opportunity
and
also
more
of
a
massive
challenge
for
us.
The
2o
release
was
the
largest
feature
release
we've
done
since
the
original
code
base.
B
We
had
one
customer
who
actually
user
actually
talks
about
the
notion
of
parts
of
nets.
Oh
and
the
way
we
did
multi-tenancy
allows
them
to
easily
say
each
micro
service
has
its
own
account,
which
we'll
talk
about
in
a
second
or
essentially
a
messaging
sandbox,
which
they're
the
free
to
do
whatever
they
want.
Inside
of
that,
and
then,
when
they're
ready,
they
can
export
to
share
with
the
world
and
they
can
import
other
people's
services
or
streams
right
again
as
dependencies.
B
One
of
the
big
things
that
we
we
talked
a
little
bit
about
was
this
notion
of:
how
do
you
move
from
a
silo
technology
or
single
tenant
to
a
multi-tenant
technology?
And
it's
it's
non-trivial,
it's
not
something
you
can
both
on
at
the
end,
and
so
the
team,
quite
a
hard
look
at
how
we
would
actually
do
this
what's
nice
was,
is
that
inside
of
the
system?
B
There
was
this
notion
of
the
the
router
right
that
given
a
message
with
a
subject,
it
figured
out
where
that
thing
was
supposed
to
go,
and
so
we
concentrate
specifically
on
that
to
say
that
is
the
the
level
of
multi-tenancy
that
we
want,
such
that
as
a
user
come
in
and
authorizes
themselves
they're
actually
attached
to
one
of
these
domains.
These
sand
boxes
these
containers
for
messaging,
so
to
speak,
and
that
was
how
accounts
were
born.
B
They're,
isolated,
meaning,
Coke
and
Pepsi
can
exist
on
the
exact
same
infrastructure
and
no
messages
will
ever
be
seen
by
by
the
other.
It
allows
to
bifurcate
technology
from
business
driven
use
cases,
the
data
silos
that
are
created
by
design,
but
not
software
limitations.
So
to
speak,
but
again
the
design
was
isolated
by
default,
but
very
huge
emphasis
on
allowing
to
securely
share
data
between
accounts,
both
streams
and
services,
and
it's
a
mutual
agreement
kind
of
like
Facebook
friends.
B
The
topic
topology
the
subject,
apology
of
how
many
tokens
and
who's
gonna
be
where
and
please
don't
step
on
each
other's
feet,
which
was
very
brittle.
It
was
complex
and
it
always
failed.
Eventually,
maybe
a
year
later,
two
years
later,
someone
accidentally
forgot
that
oh
Colin
was
using
this
subject
and
then
we
would
use
it.
B
Accounts
had,
and
this
multi-tenancy
had
a
natural
way
of
solving
that
problem.
It's
your
own
space
and
you
control
everything
about
it,
including
when
you
import
something
in
where
it
shows
up,
and
so
what
happens
is
as
similar
to
people
who
came
from
the
jabo
world
and
had
very
long
method,
names
and
variable
names,
and
then
we
went
to
go,
which
is
a
a
language,
that's
very
common
for
a
lot
of
the
cloud-based
stuff
and
everything
became
very
short.
Small
variable
names,
very
short
method
names
next
to
o
allows
you
to
do
that
with
subjects.
B
A
lot
of
the
deployments
were
looking
at
now
and
we
have
two
tokens
like
kV,
yet
right
or
NGS,
thought
usage,
or
things
like
that,
and
that's
again
because
of
that
one
little
piece
of
a
when
you
import,
you
still
control
your
account
space,
so
you
can
put
it
wherever
you
want.
You
don't
have
to
put
it
where
the
person
would
export
it
had
it.
So
that
makes
sense-
hopefully
it's
easy,
secured,
cost-effective,
extremely
cost-effective
compared
to
the
complexities
that
we're
seeing
right
now
in
the
industry.
B
One:
that's
employment
for
operators
to
manage
its
decentralized
organization.
Organizations
can
self
manage,
meaning
they
don't
have
to
keep
submitting
helpdesk
requests
stick
of
say:
can
you
please
add
a
user?
Can
you
change
the
users
permission?
Can
you
revoke
this
user?
All
of
that
is
managed
by
the
account
owners,
which
will
talk
about
services
and
streams.
So
these
are
the
basic
of
the
patterns
that
we
talked
about.
B
One
of
the
other
things
that's
interesting
about
this
is
that
almost
the
majority
of
changes
to
a
modern
net
system
are
zero
client
configuration
or
API
changes
whatsoever.
You're,
not
changing
anything
about
the
client
application.
You
don't
even
have
to
recompile
the
code
or
rerun
it
or
do
anything
and
again
making
sure
that
we
eat
our
own
dog
food
or
drink
our
own
champagne.
We
have
applications
that
are
8
plus
years
old,
that
I'm
going
to
make
sure
it
could
run
against
a
modern
that
system
and
they
do.
B
This
is
extremely
interesting
for
those
who
actually
understand
messaging
systems
a
little
bit
with
accounts,
what
it
actually
allowed
us
to
do
and
I
again
I
wish
we
could
have
said.
Oh,
we
pre
thought
about
this,
but
we
didn't,
but
with
accounts
we
said:
oh
wait.
A
minute.
An
individual
server
inside
of
a
net
system
can
have
its
own
account
that
it
can
use
to
communicate
now.
So,
instead
of
everything
being
a
protocol
change
for
servers
to
communicate
and
coordinate
amongst
themselves,
we
just
do
the
same
thing
that
application
developers
do.
B
We
just
send
messages
now,
and
so
even
a
global
super
cluster.
Right,
though
all
the
servers
are
talking
to
themselves
with
just
using
messages
through
this
notion
of
a
system
account,
but
that
account
is
no
different
than
any
other
accounts
they're
all
just
the
same,
so
they
have
authorization,
authentication
permissioning,
all
that,
and
so
we
think
that
that's
a
very,
very
powerful,
primitive
because
we
are
doing
the
exact
same
things.
Application
developers
will
do
with
the
system
itself.
B
So
one
of
the
things
that
we
care
deeply
about
with
global
deployments,
if
you're
actually
trying
to
say
hey,
we
have
all
these
silos.
Now,
let's
see
we
can
make
a
utility
that
the
company
shares
that
maybe
has
a
Geo
in
the
East
Coast
and
one
in
your
one
on
the
west
coast
and
one
in
Asia
there's
a
lot
of
things
that
the
team
was
specifically
trying
to
solve
for
in
terms
of
how
do
we
actually
build
one
of
these
such
that?
It's
not.
B
You
know
difficult
to
scale
difficult
to
change,
difficult
to
manage
and
monitor,
I've
been
involved
in
a
lot
of
systems
where
you'll
get
the
system
set
up,
and
it's
so
brittle
or
so
fragile.
No
one
wants
to
change
it
after
it's
actually
up
and
running
and
there's
massive
dashboards.
Everyone
has
to
stare
at
and
pager
rotations
and
all
kinds
of
crazy
stuff
and
I.
Just
don't
like
that.
I
don't
want.
B
If
the
system
can
self
heal
itself,
I
don't
want
to
be
woken
up
in
the
middle
of
the
night
right
I
wanted
to
be
on
earth.
You
know
be
able
to
provide
a
an
SLA
and
fix
itself
most
of
the
time,
and
that's
Oh
does
that
you
know
we
don't
have
to
do
configuration
changes
for
most
most
changes
that
we're
doing
both
clients
and
the
server
self
heal
and
and
talk
to
each
other.
So
a
client
knows
about
the
topology,
even
if
it
wasn't
in
a
DNS
name
or
configured
in
the
application.
B
None
of
that
is
needed
and-
and
you
know,
nets
is
something
that
is
worked
extremely
well
inside
of
kubernetes
deployments
and
we're
getting
a
lot
of
usage
and
a
lot
of
interest
through
quite
a
bit
of
P
or
C's
these
days
around
how
to
do
kubernetes
and
multiple
Cooper
naze
deployment
and
cluster
those
together,
but
Nats
by
itself
is
truly
deployment
cloud
into
you,
agnostic.
It
does
not
care
and
it
will
put
itself
together
and
self
heal
itself,
regardless
of
how
it's
been
deployed,
which
we
think
is
important.
B
Long-Term
superclusters
is
our
way
of
saying
how
do
we
actually
get
to
a
global
footprint?
Most?
Not
all,
but
most
austerity
systems
technologies
do
very
well
if
they're
clustered
together
in
a
very
good
network,
bandwidth
an
RTT
type
of
a
scenario
and
as
you,
what
call
stretch
the
the
technology
to
long
RT,
TS
or
sketchy
networks.
You
know
problems
persist
and
we've
seen.
You
know.
Amazing
companies,
like
you,
know,
Google's
of
the
world
and
the
Facebook's
of
the
world
and
others
trying
to
solve
these
problems
at
Google
scale,
and
so
from
a
communication
standpoint.
B
We
needed
to
try
to
solve
this
problem
as
well,
and
so
we
created
a
whole
new
technology
that
allows
clusters
of
clusters
to
be
networked
together
through
a
novel
spline
based
technology.
It's
got
a
very
interest
or
optimistic
Sens
with
interest
craft
for
me,
because
the
team
collectively
we
have
over
a
hundred
years
of
experience
in
these
systems
and
at
large
scale
a
lot
of
times.
Just
the
chatter
that's
going
back
and
forth
on.
B
One
of
these
systems
actually
brings
the
system
down,
even
though
there's
actually
not
a
lot
of
data
moving
on
the
system,
and
so
we
were
aware
of
that
problem
and
worked
really
hard
to
put
something
together.
The
other
thing
is:
is
that
we've
always
had
this
notion
of
subscribers?
Can
dynamically
form
a
group
so
Colin
and
I
can
dynamically?
B
So
super
clusters
are
again
are
clusters
of
clusters,
so
you
have
US
West,
EU
s,
Us,
East
type,
stuff,
leaf
nodes
leaf
nodes
are
our
way
of
saying
we
think
most
people
really
want
to
have
a
natural
transition
between
I
have
a
silo
technology
and
I
have
a
true
shared
utility
technology,
a
lot
of
times.
Organizations
internally
feel
like
they
can
have
one
or
the
other
and
they're
almost
forced
into
that
shared
utility
model,
and,
to
be
honest
with
you
at
least
the
the
users
and
customers
that
we've
dealt
with,
that
usually
doesn't
go
well.
B
A
lot
groups
resist
that
they
don't
want
to
be
forced
into
using
this
shared
utility
they
for
lack
of
a
better
word,
the
old
server
huggers
right.
They
want
their
own
servers
to
actually
manage
and
so
leaf.
Nodes
is
our
answer
to
that.
It
allows
you
to
have
your
cake
and
eat
it
too.
What
it
means
is
is
that
you
can
use
leaf
nodes
to
extend
super
clusters
with
hub-and-spoke
topologies.
B
You
are
allowed
to
bridge
separate
security
domains.
So,
if
you're
doing
an
IOT
deployment
that
can
have
its
own
secure
you
to
me.
However,
you
want
to
do
that
and
that
can
bridge
transparently
and
securely
into
a
super
cluster.
Let's
maybe
is
the
back-end
services
and
micro
services
that
you're
actually
trying
to
deploy
it's
very
ideal
for
edge
computing,
IOT
hubs,
data
centers,
we've
seen
lots
of
pure
sieves
love
the
fact
that
there
is
a
shared
utility
and
their
services
that
are
being
built
into
that
super
cluster.
B
But
the
system
again
because
of
the
way
it's
built
transparently
securely
and
dynamically
will
understand
if
the
message
needs
to
be
routed
to
the
super
cluster
or
if
messages
that
are
originating
the
super
cluster
need
to
be
routed
out
to
our
own
client
applications,
and
so
this
this
leaf
node
technology
is,
is
very
powerful
and
it
essentially
allows
you
to
have
your
cake
and
eat
it
too.
Right.
B
You
can
have
your
own
technology,
your
own
silo
for
your
own
or
your
own
micro
service,
but
your
company
or
organization
can
be
going
down
the
path
of
a
true
shared
utility
within
the
company,
and
so
this
is
what
kind
of
that
would
learn.
It
can
be
a
single
server,
a
small
cluster
of
servers
and
again
all
of
this
works
totally
transparently.
I
use
it
actually
quite
a
lot
to
have
a
server
running
on
my
computer.
B
So
we
talked
a
little
bit
about
the
fact
that
these
these
services,
these
queue
subscribers-
can
are
now
transparently
geo
aware,
and
so,
if
you
have
a
set
up,
that's
a
super
cluster
like
this,
and
you
have
the
primary
and
the
backup
and
also
there's
an
outage.
Something
goes
down
right
in
terms
of
the
flow.
The
system
will
automatically
reroute
things
for
you
on
the
fly.
B
No
configuration
changes,
no
client
application
changes,
nothing
needs
to
happen
whatsoever
and
what
we've
seen
is
that's
extremely
powerful,
and
it's
not
only
that
if
there's
an
outage
this
works,
but
if
you're
noticing
it
you're
observing
a
system
where
you
realize
a
requests
are
coming
from
Asia
and
your
services
in
the
west
coast
of
the
US,
you
can
actually
move
responders
or
start
adding
responders
in
Asia,
and
the
system
automatically
responds
again
no
configuration
changes.
You
just
deploy
these
these
service
responders
in
Asia.
B
The
system
automatically
will
route
request
from
Asia
directly
to
those
no
load
balancers,
no
configuring
stuff
on
cloud
providers.
None
of
that
is
needed,
so
security
is
really
important.
It
has
to
be
secured
by
default,
but
a
lot
of
times.
People's
shoulders
drop,
they
shrug
they
go.
Oh
man,
this
is
just
gonna,
be
painful,
and
we
realize
that
right.
So
we
really
wanted
to
take
the
notion
of
secure
by
default,
to
be
easy
and
decentralize
meaning
there
is
no
central
point
of
control.
We
have
full
TLS
support
with
certificates
and
bi-directional
both
client-server.
B
We
can
support
the
understand
inside
our
spiff
kit,
for
the
Nats
user,
identity,
support
for
normal
user
name/password
and
again
leaf
nodes
allowed
you
to
bridge
different
security
domains
as
needed,
and,
of
course
you
have
permissions
restrictions
on
what
subject
you
can
send
on
receive
on
how
big
of
message
payloads
all
of
this
is
possible
and
with
Nats,
oh
and
operator
mode.
All
of
this
is
decentralized.
There
is
no
centralized
control
for
how
I
would
introduce
a
client
that
would
be
Colin.
They
can
only
send
up
to
256
bytes.
B
Only
on
this
subject-
and
so
this
notion
of
least
privilege
is-
is
very
easy
within.
That's,
where
normally
it's
very,
very
hard
and
very
scary
to
do
generally
the
way
operator
mode
works.
Is
it's
similar
to
way
the
web
works
right?
There's
three
main
components:
there's
an
operator
and
then
an
operator
will
vouch
for
accounts
and
accounts,
vouch
for
users
and
applications,
use
user
credentials
essentially
to
connect
the
system
does
not
understand
anything
on
boot-up,
so
to
speak,
except
the
trusted
list
of
operators.
It
can
figure
out
everything
else
from
there.
B
The
system-
and
this
is
important-
the
nets
to
Oh
systems
never
have
any
private
keys
or
passwords
whatsoever,
they're,
never
even
transmitted
to
the
system.
So
what
happens
is
is
that
underneath
the
covers
that
that
system
will
challenge
a
client
application
with
a
nonce
that
needs
to
be
signed
by
the
private
key
of
the
owner
of
the
client
credentials,
and
then
that
has
to
be
valid,
not
expired,
has
to
be
signed
by
a
valid
account
and
again,
the
system
can
dynamically
figure.
B
This
all
out
on
the
fly,
therefore,
account
owners
can
be
free
to
do
anything
they
want
with
users
in
terms
of
adding
them
revoking
them.
Changing
their
permissions
without
ever
having
to
talk
to
an
operator
or
any
type
of
central
authority
whatsoever
and
that's
to
O
is
designed
specifically
to
be
a
federated
model,
meaning
again
it
can
have
multiple
operators
right.
It
could
have
servers
that
are
being
operated
by
Google
and
by
Amazon
and
by
a
sure.
Yet
as
a
user,
they
all
look.
B
B
We
only
support
that
which
allows
us
to
make
the
JWT
s
public
and
secure,
and
then
we
actually
do
the
signatures
with
only
IDI
255,
1,
9
keys
and
again,
the
three
actors,
essentially
in
the
system
are
operators
accounts
and
users
and
I
encourage
you
to
go
to
our
new
documentation.
If
you
want
to
learn
more
or
ask
questions
or
ping
me
directly
on
the
slack
Channel
or
info,
and
that's
that
I,
oh,
these
are
kind
of
what
these
things
look
like
and
just
here
on
the
account.
B
These
are
some
of
the
things
that
you
can
control
the
max
number
of
connections
globally,
max
number
of
leaf,
node
connections,
the
max
data
bandwidth.
Essentially,
the
exports
and
imports
things
like
that
are
all
at
your
control,
totally
decentralized
and
instantaneous.
So,
for
example,
if
globally,
someone's
trying
to
connect
in
Asia
and
the
account
already
has
10
active
connections-
and
this
would
be
the
11th-
it's
denied
instantaneously
in
the
system
again,
the
way
the
server's
talk
to
themselves
in
a
secure
manner
keep
all
of
this
state
on
a
global
scale.
B
B
Document
Fornax
Oh
documentation
is
hugely
important
for
modern
systems.
People
can
self
learn
can
and
you
know,
ask
and
answer
their
own
questions.
We
encourage
you
to
look
at
them
to
help
us
improve
them.
We
put
a
lot
of
effort
into
it,
but
it's
an
ongoing
effort
that
we
work
on
every
week,
but
the
ecosystem
is
also
embraced
this
and
started
to
really
put
effort
into
helping
us
maintain
a
world-class
set
of
documentation,
which
again
I
think
is,
is
critical
for
any
type
of
ecosystem.
B
Our
ecosystem
is
is
great
and
growing,
as
you
can
see
we're,
probably
at
about
a
eighty-five
million
combined
downloads
between
Nats
and
net
streaming
on
docker.
This
is
kind
of
like
benchmark.
You
got
to
take
them
for
what
they
are,
but
we
can
see
that
we're
going
up
into
the
right
very
quickly,
and
we
see
also
that
with
the
number
of
slack
users,
the
number
of
interactions
on
slack,
the
ecosystem
is
just
very
healthy
and
it's
growing
very
quickly
and
we're
super
excited
about
all
of
that.
B
B
We
already
have
transparent
bi-directional
bridges
for
Kafka
and
MQ
series,
which
quite
a
bit
of
users
in
the
ecosystem,
and
customers
of
ours
are
starting
to
use
again.
The
documentation
updates
are
critical,
I
think
for
a
healthy
ecosystem
in
2019
we're
now
working
on
the
successor
than
that
streaming.
B
The
request
can
be
coming
from
anywhere
in
the
world
the
responder
can
be,
and
the
system
will
present
you
with
the
metric
that
says:
here's
how
long
the
service
itself
took.
Here's
the
responder
RTT,
the
request
RTT
and
the
internal
Nats
latency
again
on.
Let's
say
something
like
a
super
cluster,
so
we're
super
excited
about
that.
As
we
move
into
the
end
of
the
year,
we
do
plan
that
IOT
is
a
massive
opportunity
for
any
type
of
technology.
It
does
try
to
connect
everything,
and
so
we
believe
Nats
works,
amazingly
well
on
very
low-end
devices.
B
However,
we're
going
to
introduce
native
MQTT
support,
both
31500
and
the
sensor
network
versions
such
that
these
applications
untouched
can
connect
directly
to
a
NAT
system,
we're
also
going
to
introduce
WebSocket
support
and
edge
dead,
zero
trust,
security,
zero
trust
for
us,
it's
a
loaded
word,
but
what
it
means
is
is
that
before
our
system
ever
sees
anything
everything's
already
encrypted,
and
we
don't
have
the
keys,
that's
kind
of
our
version,
what
that
means
and
then,
as
we
go
forward,
we
really
think
there's
a
massive
opportunity
again.
If
everything
is
connected,
these
services
are
available.
B
Things
can
be
imported,
kV
databases,
things
like
that,
also
an
embrace
where
webassembly
is
going
and
use
our
security
model
webassembly
to
say:
here's
a
signed
web
assembly
module
that
I
want
to
work
on
ingress
for
the
subject
foo.
In
my
account,
they
can
do
things
like
identify
personal
information
and
gdpr
type
things
filtering
t
anything
you
can
think
of
and
again
with
webassembly
almost
any
language.
You
want
to
write
it
in
combined
with
our
security
model.
B
So
hopefully,
this
was
was
helpful.
We
really
think
there's
an
opportunity
to
think
different
to
stop
making
things
more
complicated
again,
regardless
of
what
we
do
as
an
ecosystem.
We
know
this
is
going
to
happen.
You
know
technology
always
is
a
pendulum.
It's
always
swinging
back
and
forth.
I
still
feel
we're
still
swinging
toward
making
things
more
complicated
than
they
need
to
be.
I
want
to
start
trying
to
make
things
simpler,
but
not
give
up
on
the
principles
of
what
we
feel
modern
to
serve.
B
Your
system
should
do
right
that
the
micro
service
is
the
easy
to
deploy
the
observability,
the
debug
ability.
Those
things
are
good.
They're
they're,
meaningful
I
just
think
we
can
do
them
in
a
in
a
simpler
way.
So
we
need
what
I
could
consider
our
own
Tesla
moment
right
where
Tesla
said
all
of
that
amazing
technology,
it's
over
century-old
and
billing,
an
internal
combustion
engine.
We
can
just
replace
it
by
something
as
really
simple
and
bulletproof
and.
A
B
Thank
you.
I
really
appreciate
the
time.
Here's
how
to
get
hold
of
us.
That's
IO.
The
website,
github.com
I,
think
we're
up
to
like
65
different
repos.
The
system.
An
eco
system
again
is
very
reverent
and
that's
IO
on
Twitter
not
happy
to
take
any
questions.
We
have
some
time.
I
didn't
have
the
we
have
some
time
perfect.
We.
A
We
do
we
have
a
couple
questions
here
in
the
Q&A
great,
no,
the
first
one,
a
problem
we've
had
with
Nats
and
frankly,
some
other
messaging
systems
is
a
lack
of
message,
ordering
guarantees
or
more
simple
message,
time:
stamping
for
messages
sent
by
different
producers
to
a
given
receiver.
What
are
your
suggestions
for
handling
this
I?
Think.
B
That's
a
great
question
ordering
there
there
are
cases
where
Orion
does
matter
right.
If
you
look
at
NAT
streaming,
one
of
the
first
tenants
of
what
a
Streamy
does
and
Jetstream
that
were
doing
as
a
successor
does,
is
that
once
an
order
is
defined,
it's
the
exact
same
order
for
every
subscriber
in
the
system,
and
so
my
my
answer
is:
is
that
if
it's,
if
it
is
important,
you
know
Usenet
streaming
or
look
into
our
work
on
Jetstream
and
be
part
of
that
process
to
help
us?
B
A
B
The
way
one
last
thing
you
know
that
streaming
at
jet
stream,
you
don't
need
to
use
it
for
everything.
So,
for
example,
remember
how
we
talked
about
system
accounts
and
that
our
servers
actually
talked
to
each
other
now
and
they
actually
coordinate
information
when
they
send
a
message.
They
send
it
with
their
ID,
which
is
a
unique
8255,
one,
nine
key
that
we
talked
about
and
a
sequence
number
per
event,
and
so
any
other
remote
server
can
instantaneously,
no
matter
how
many
servers
are
in
between
them
realize
if
they
miss
something.
B
So
you
know
you
don't
have
to
go
to
a
pre-canned
solution
all
the
time.
If
there's
a
situation
where
you
say,
hey
I,
want
to
make
sure
I
understand
that
it
can
be
as
simple
as
saying
every
time.
I
send
a
message:
I
send
a
unique
identifier
and
a
sequence
number
that's
always
plus
one,
and
then
the
other
side
simply
has
to
store
state
on
that
unique
identifier
and
the
last
sequence
it
received
and
if
you've
received
something,
that's
not
plus
one,
it
throws
its
hands
up
or
does
something
to
to
fix
the
problem.
B
A
B
That's
another
great
question
and
and
I
have
a
two-part
answer,
so
philosophically
Nats
was
designed
to
be
payload
agnostic
and
we
have
maintained
that
throughout
its
lifetime.
Now
from
an
application
standpoint,
you
need
to
know
what
the
message
is
right,
so
understanding
what
it's
meant
for
what
encoding
it's
in
JSON
or
protobuf
is
important
and
we
want,
as
part
of
the
ecosystem,
to
make
that
easier
right.
B
We
have
some
clients
that
do
a
little
bit
of
that
stuff,
but
we
also
have
and
one
of
the
things
on
the
roadmap
was
this
data
pipelining
and
we've
been
doing
some
internal
work
to
make
that
easier,
however,
that
that
payload
agnostic,
sometimes
people
kind
of
push
back
a
little
bit
on
that,
and
that's
totally
fair.
The
metaphor,
though
I'd
like
to
draw
is
it's
kind
of
like
a
phone.
You
know
my
phone
I
can
speak
English,
Portuguese
Japanese,
it
doesn't
matter
right,
its
payload
agnostic.
B
You
would
hate
to
buy
a
phone
that
only
understood
English,
and
so
we
feel,
philosophically,
the
coordinates
system
needs
to
be
payload
agnostic,
but
we
also
recognize
as
an
ecosystem.
We
need
to
make
it
easier
for
our
users
to
be
able
to
say:
I
want
to
use
things
like
GRDC
have
like
with
protocol
buffers
and
service
endpoint
definitions,
and
things
like
that,
and
so
the
team
is
putting
a
lot
of
effort
in
there.
And
if
you
have
suggestions,
we
encourage
you
to
send
that
feedback
to
us
or
submit
a
PR.
B
A
B
Do
know,
but
we're
biased,
but
we
do,
but
where
it
becomes
very
interesting,
is,
is
that
if
you
understand
you
know
what
the
request
is
and
what
the
response
is
right,
you
can
layer
that
over
top
of
Nats
very
quickly,
I
mean
it's
a
lot
of
times.
It
can
be
as
easy
as
a
10
minute
exercise
and
we've
actually
done
it
unless,
with
some
of
the
team
members
at
user
sites
right
to
say,
oh
well,
it
was
just
widget
over
two
Nats,
but
that's
not
the
most
powerful
part.
B
The
most
powerful
part
is,
is
that
now
you
have
a
totally
and
then
secure
system
that
you
can
lock
down
any
way
you
want.
Without
ever
a
line
of
code.
You
can
scale
up
the
service
endpoints
without
adding
load,
balancers
proxy
side
cards.
You
can
scale
it
back
down.
You
can
put
the
requesters
anywhere
in
the
world
and
so
what
you
you
get
in
that
10
minute
exercise.
Is
you
get
a
truly
global,
scalable
system?
That
is
also
observable.
Now
you
can
observe
it
today.
B
It's
a
pure
pub/sub
system,
but
we're
making
that
even
easier
and
that
code
has
already
landed.
So
I
encourage
you
to
reach
out
to
me
well
we'll
talk
one-on-one
about
where
we're
going
with
that
to
say,
oh
and
oh,
by
the
way,
this
exported
service
is
now
instantly
observable
anywhere
in
the
world,
but
only
for
secure
credential
holders.
Right
I
can
see
all
of
the
latency
and
again
not
just
the
service
or
what
I
thought
the
requesters
view
of
the
world
is
right
because,
when
you're
observing
it's
actually,
what
does
the
service
provider
see?
B
What
does
it
requests
are
see
and
what
does
the
actual
NAT
subsystem
see
and
anyone
who's
observing
wants
to
see
all
three
and
we
don't?
You
know
we
haven't
seen
that
yet
and
our
system
does
that
so
absolutely
and
please
reach
out
to
me
directly
or
the
team
we'd
love
to
talk
more
one-on-one,
wait.
Okay,.
B
B
B
A
B
Yes,
that's
a
part
of
the
Jetstream
initiative
and
again
there
is
actually
a
jet
stream
channel
on
the
slack
Channel
that
is
sharing
all
of
the
design
documents,
and
you
can
see
a
lot
of
the
conversation
between
the
people
in
the
Nets
ecosystem.
That
care
about
this,
and
it
is
part
of
that
subsystem-
is
to
include
that
functionality
and
for
those
who
don't
know
what
Jetstream
is
it's
a
successor
than
that
streaming.
B
But
the
the
take-home
points
are
that
it's
not
only
streaming,
it
can
do
work
using
and
do
normal
messaging
type
stuff
it'll
be
built
into
the
net
server
it'll
be
horizontally
scalable
and
it
will
allow
different
types
of
what
we
call
observable
patterns
again
to
exactly
what
you
just
asked
for
in
terms
of
the
SQLite
functionality.
Okay,.
A
B
So
that's
a
great
question:
we
don't
necessarily
plan
on
it
and
we
want
to
make
it
as
easy
as
possible,
so
we're
going
to
put
effort
into
that,
but
after
Jetstream
is
actually
designed.
So
what
I
mean
by
that
is
we're
not
trying
to
design
Jetstream
as
Stan
v2,
because
we
felt
like
getting
closer
to
the
the
native
Nats
API
understanding
wildcards,
you
know
different
types
of
patterns
like
that
were
were
critically
important.
You
know
bundling
it
inside
of
the
server
and
set
up
having
Stan
kind
of
run,
a
server
embed
it.
B
But
at
the
end
of
the
day
you
know
we
try
very
hard
to
protect
the
ecosystem
or
and
protect
our
users
nobody's
perfect
and
we're
not
either.
But,
as
you
can
tell,
if
you
take
a
8
year
old,
Matt's
application,
you
can
still
run
it
today.
We
at
least
try-
and
so
we
are
going
to
do
that
with
Stan
and
for
people
who
want
to
move
from
Stan
to
Jetstream.
Make
that
as
easy
as
possible.