►
From YouTube: An Introduction and Deep-dive into Dotmesh
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
I'm
super
excited
like
we
got
a
mini
talk
about
your
news
thing
there
dot
mesh,
but
before
we
get
to
that,
can
you
give
you
know
the
audience
a
little
bit
of
a
background
like
I've
been
doing
before
that?
So
this
is
your
new
venture
there
you
know
many.
There
are
many
other
things.
I
can
remember
that
might
be
of
interest
like
what
have
you
done
before
yeah.
B
So
I
I
was
involved
in
developing
flocker,
which
was
the
IDE
open-source
project
at
cluster
HQ
with
Flocka.
We
did
a
lot
of
work.
I
mean
the
industry
was
super
early
at
that
point
like
that
was
the
year
that
docker
just
sort
of
started
exploding
in
2013,
14,
14
I
think
was
when
we
really
got
involved,
we
pivoted
something
we
were
doing
previously.
We
actually
had
a
ZFS
based
distributed
web
hosting
platform
on
FreeBSD
I
heard
that
we've
noticed
to
sort
of
start
serving
the
docker
market.
B
But
the
interesting
thing
about
vlaka
was
that
it
was
so
early
that
we
had
to
do
a
lot
of
hard
work
to
just
connect
containers
to
storage
at
all.
And
so
so
we
we
integrated
with
EBS
on
Amazon
and
Google
persistent
disks,
the
integrated
lucinda
on
OpenStack.
We
integrated
with
about
a
dozen
different
storage
vendors
for
the
sandé
products
and
and
we
managed
to
get
flocker
into
a
1.0
and
into
production
with
a
big
customer
Swisscom.
B
Unfortunately,
at
that
point
we
had
already
scaled
to
large
really
to
be
able
to
move
quickly
enough,
and
that's
that
premature
scaling
sort
of
believing
our
own
hype
and
believing
that
we
we
had
achieved
product
market
fit
before.
We
really
had
I.
Think
that
that's
the
reason
why
why
cluster
age
key
wasn't
successful,
ultimately,
but
I
then
took
a
year
out
to
work.
B
But
I
guess
I
just
still
had
the
itch
to
come
back
to
the
container
storage
world
and
so
I
then
launched
this
project
dot
mesh,
which
we
just
launched
on
Wednesday
this
week.
And
it's
not.
It's
not
actually
really
contain
a
storage
anymore.
It's
more
about
data
management
or
cloud
native
applications.
So.
A
B
B
But
absolutely
so
so
yeah!
It
is
definitely
easier
now
that
things
have
settled
and
I
mean
we're
even
getting
our
stuff
working
on
kubernetes
on
docker
for
Mac,
and
it's
really
nice
to
see
the
docker
have
embraced
like
running
a
local
kubernetes
cluster
for
development
on
docker
fluently
nice
way.
So
that's
so
that's
pretty
interesting!
So
yeah
I'll
talk
a
little
bit
about
about
dot.
B
A
B
So
it
would
be
a
really
bad
day
at
work
if
all
three
of
these
things
happen,
but
the
first
one
is
that
you
have
a
change
to
an
application
that
you're
developing
it
passes
all
the
tests
in
CI
and
you
deploy
it
in
production
and
it
blows
up
this
happens.
Surprisingly
often,
it's
happened
to
me.
It's
happened.
B
Companies
I've
worked
with,
and
it's
really
painful
because
it
means
that
you're,
exposing
your
users
and
your
customers
to
two
failures:
two
errors
and
and
so
on,
and
so
you
have
to
ask
the
question:
why
does
this
happen
and
the
reason
that
things
pass
the
tests
and
then
they
blow
up
in
production-
is
that
production
is
just
fundamentally
different
to
all
the
other
environments
that
you
have.
It
has
different
data.
It
has
different
scale.
B
So
that's
the
first
problem
and
that's
a
big
problem
to
solve
and
we're
not
going
to
solve
all
of
that
problem
in
one
go.
But
it's
it's
interesting
to
just
set
the
scene.
The
second
one
and
I'm
sure
you
know
xkcd
I've
actually
modified
this
xkcd
slightly.
It
used
to
say
that
the
number
one
programmer
excused
for
legitimately
slacking
off
is
that
your
code
was
compiling,
but
actually
in
2018.
B
How
can
we
make
our
CI
systems
faster?
How
can
we
make
our
tests
faster
and
more
reliable?
Another
interesting
fact
about
this
is
that
the
more
realistic
your
testing
gets
the
slower
and
flakier
it
tends
to
get
so
end-to-end
tests
that
test,
maybe
50
different
micro-services
together,
using
using
real
databases,
often
and
pretty
much
guaranteed,
to
be
slower
and
flakier
than
unit
tests.
That
can
run
quickly
using
sort
of
prepackaged
data
that
shipped
as
part
of
the
test
and
of.
A
Course
we
stopped
you
and
like
what
do
you
think
about
that?
I
heard
that
a
couple
of
times
and
when
I
said
it
myself,
I
got
you
know
quite
a
lot
of
heat
there.
I
said
like
hey
in
the
context
of
you
know
container
is
the
micro
service
and
whatnot
we're
dealing
with
in
our
space.
It
actually
did
really
do
like
you.
Don't
have
a
key
anymore.
You
don't
have
you
know
you
don't
really
do
test,
you
directly
go
into
product,
and
you
know
you
just
exposed
this
new
version
to
a
very
small.
A
B
There,
though,
where,
if
the
change
that
you're
deploying
depends
on
on
data,
if
the
change
that
you're
deploying,
for
example,
updates
a
schema
in
a
database,
then
you
can't
like
fork
your
database
into
the
old
version
and
the
new
version.
The
that
the
canary
approach
to
testing
new
code
changes
only
really
works
for
stateless
applications.
B
And
I'd
like
to
talk
to
people
at
Facebook
and
Twitter
and
Google
as
well
about
what
they
do
and
and
so
on.
So
anyway,
I'll
proceed
with
with
with
the
third
categories
that
we
have
here.
So
this
one
is
that
one
does
not
simply
capture
the
state
of
for
micro
services
at
once,
and
what
I
mean
here
is
that,
as
we
see
a
progression
towards
micro
services,
there's
this
thing
called
polyglot
persistence,
which
is
where
the
right
way
to
do.
Stateful
micro
services
is
that
each
micro
service
only
talks
to
one
sorry.
B
Each
database
is
only
talked
to
by
one
micro
service
and,
and
basically
the
upshot
of
this
is
that,
instead
of
having
one
large
database
at
the
center
of
your
application,
you'll
end
up
with
many
you'll
end
up
where
the
database
for
your
orders
service
a
database
for
your
users
service,
a
database
for
whatever
other
domain-specific
data
there
is
for,
for
whatever
your
application
does,
and
what
this
means
is
that,
when
you're
testing
an
application
when
you're
doing
development
on
an
application,
you
might
be
spinning
up.
Maybe
four
or
five
different
databases
on
your
laptop.
B
A
Not
sorry,
just
just
one
quick
note,
everyone
might
might
be
from
it.
I
mean
people
probably
know
polyglot
programming,
but
might
not
really
be
that
familiar
with
polygon
persistence.
Just
to
be
clear.
It's
like
it's,
not
a
top-down
thing.
It
right!
It's
not
that
you
know.
Oh,
we
have
to
use
five
different
kinds
of
data
stores,
so
here
we
use
some
some
sequel
and
here's
some.
You
know
elastic
surgeon,
cetera,
it's
really
like,
depending
on
your
workflow,
you
know
shopping
basket.
A
You
know
you
might
need
some
readies
or
whatever
for
some
transactions
that
you
might
see
and
that's
like
bottom
up.
That's
why
you
end
up
with
different
data
kind
of
data
stores,
really
that
treat
data
differently,
and
then
then
you
arrived
it
essentially
that
just
want
to
make
sure
that
everyone
is
on
the
same
page
that
you
know
this
is
really
bottom
up
same
as
probably
programming.
It's
not
that
you
know.
Oh,
you
have
to
use
five
different
programming
languages.
It's
no
no
essentially
grows
what
about.
B
Yeah
absolutely
I,
think
polyglot
persistence
is
sort
of
an
an
effect
that
you
see
a
sort
of
an
emergent
behavior
that
you
see
when
you
do
micro
services,
rather
than
like
the
CIO
saying
we
must
have
five
different
databases.
It's
it's.
It's
sort
of
a
consequence
of
doing
micro
services
properly
and
absolutely
it's
not
like.
B
Oh,
we
have
to
use
five
different
micro
services
or
five
different
databases
like
because
it's
it's
because
each
team
is
given
autonomy
over
developing
the
the
micro
service
that
they're
working
on
in
the
language
that's
most
appropriate
for
it,
and
also
the
data
store,
that's
most
appropriate
for
it.
So
if
you're
working
on
the
search
service,
it
probably
makes
sense
to
use
elastic
search
as
your
data
store.
B
If
you're
working
on
data
that
tends
to
be
sort
of
ephemeral,
then
Redis
might
be
a
good
choice,
whereas
if
it's
something
like
a
user's
service
which
the
is
is
more,
is
the
the
sort
of
transactional
aspect
of
it
is
more
important
than
a
traditional
sequel
like
Postgres
on.
My
sequel
would
probably
make
more
sense.
B
Cool,
so
so,
anyway,
you
end
up
with
this
problem,
where
it's
so
hard
to
capture
the
state
of
multiple
micro
services
at
once
in
in
development
that
people
just
don't
do
it,
and
so
what
you
see
instead
is
like.
Oh,
can
us
station
to
my
machines
to
see
this
to
look
at
this
problem
or
or
even
if
you're,
in
the
same
building.
Can
you
come
over
here
and
look
at
this
problem
over
my
shoulder
and
help
me
fix
it
and,
of
course
that
doesn't
really
work
very
well
if
you're
in
a
team.
B
For
one
thing,
it
means
that
you
have
to
interrupt
people,
and
you
have
to
synchronize
human
focus
between
between
these
environments,
where
the
data
is,
but
it
also
it
goes
badly
when,
when
you're
in
different
time
zones
or
when
there's
lots
of
different
teams,
so
I
think
there's
a
better
way
of
dealing
with
this
problem.
Basically,
and
so,
if
you
take
a
step
back,
then
you
can
see
that
there
are
problems.
The
problems
I've
described,
touch
all
the
different
stages
of
the
software
development
lifecycle
in
production.
B
An
unexpected
production
outage
can
often
happen
because
tests
aren't
realistic
enough
with
respect
to
data
in
CI.
You
often
get
these
end-to-end
tests
that
manipulate
real
databases
that
are
slow
and
they're
flaky
and
in
development,
microservices
and
polyglot
persistence
make
capturing
and
sharing
development
states
hard
enough
that
no
one
does
it.
B
What
are
you
in
control
of
and
what
does
control
mean
in
modern
software
development
and
modern
software?
Is
all
about
control.
We've
been
able
to
control
our
code
well,
so,
firstly,
what
what
is
modern
software
made
out
of
I?
Think
the
modern
software
being
made
out
of
code
infrastructure
and
data
is
a
reasonable
way
of
dividing
up
the
world
and
we've
been
in
control
of
code
for
the
longest
time.
Probably
for
two
decades,
we've
had
version
control
and
more
recently,
we've
seen
the
emergence
of
continuous
integration,
meaning
that
code
is.
B
B
That
they've,
written
or
manual
processes
a
surprising
number
of
companies,
or
maybe
it's
not
surprising-
that
a
huge
number
of
companies
still
have
DBAs
and
you
sent
the
DBA
an
email
or
you
make
a
phone
call
if
you
want
to
snapshot
of
your
production
data
and
so
on,
and
so
I
feel
like
there's
broadly
space
for
data
to
be
brought
back
into
all
sort
of
sorry
brought
into
the
circle
of
control
and
that's
our
mission
with
with
dot
mesh
and
that's
what
we're
trying
to
do.
So.
B
B
You
have
we're
proposing
that
you
include
this
service
called
hub
in
the
center
of
your
mesh
and
then
around
the
edges
of
the
mesh.
We've
got
these
different
environments.
We've
got
a
development
environment
of
one
developer,
we've
got
another
development
environment,
another
developer,
this
first
development
environment
might
be
a
laptop
and
the
second
development
environment
might
be
a
VM.
Then
we've
got
the
CI
system,
of
course,
which
is
running
tests
against
code
as
it
as
it
flows
from
dev
in
to
ultimately
staging
in
prod.
B
Then
you
have
staging
and,
like
you
say,
staging
maybe
is
going
away
or
maybe
there's
more
advanced
versions
of
staging
that
are
happening
like
a
kubernetes
namespace
per
branch,
for
example,
but
in
all
of
those
cases
that
there
are
often
still
environments
in
between
the
CI
system
and
and
production,
and
then
of
course,
we
have
production
itself
where,
where
your
workload
is
running
a
serving
production
traffic
and
once
you
have
a
mesh,
you
can
do
some
interesting
things.
And
so
the
first
use
case
that
we're
proposing
with
mesh
is
developer
collaboration.
B
And
it's
this
idea
that
if
developer
one
has
a
problem,
State
or
some
interesting
state,
maybe
they
found
a
security
vulnerability
in
an
app
and
they've,
and
you
can
only
reproduce
it
by
getting
the
databases
into
a
certain
special
interesting
state
that
they
can
capture
that
dot.
We
call
them
data
dots.
We
can
capture
that
state
in
a
dot
and
then
the
developer
can
commit
that
dot.
B
Just
like
a
git
repo
and
push
that
state
that
interesting
state
up
stub,
another
developer
can
then
come
and
pull
down
that
state
and
debug
the
problem
and
develop
some
some
code
changes
that
address
it.
There's
also
an
interesting
use
case
for
capturing
failed,
CI
runs
so
we've
talked
to
customers
where
they
have
a
CI
system.
That
involves
a
lot
of
a
lot
of
micro
services
being
pulled
together
in
one
pipeline
and
tested
end-to-end,
and
whenever
that
pipeline
goes
red.
B
The
really
interesting
thing
is
that
they
have
to
stop
the
entire
office
committing
changes
because
they
have
to
SSH
into
the
test
runners
and
go
and
poke
around
with
the
databases
to
find
out
what
went
wrong,
and
so
wouldn't
it
be
so
much
better.
If,
instead
of
having
to
SSH
into
the
test
runners,
you
could
just
capture
the
state
of
a
failed
CI
run
in
a
way
that
is
sort
of
reproducible,
both
in
terms
of
code
and
data,
and
pull
that
and
state
down
to
to
a
developer
developer.
A
That's
super
exciting
and
myself.
I
have
a
background
in
data
engineering.
My
parents
I
really
appreciate
and
understand
all
these
issues,
but
they
quickly
try
to
reformulate
that,
in
my
own
words,
to
see
I
really
got
it
because
you
know
I
did
honestly,
don't
get
it
so
far.
I've
played
around
with
it
a
little
long
and
fun,
but
I
did
not
really
get
it.
A
Is
it
fair
to
say
that
that
mesh
is
kind
of
like
the
East
you
for
data,
so
essentially,
rather
than
having
ad
hoc
solutions
that
you
know
say
this
in
NCI
and
capture
that
with
a
shell
script
or
whatever
put
it
there
on
a
three
or
whatever
and
having
it
things
or
even
make
it
part
of
application?
You
kind
of
outsource
that,
with
the
mattress
actually
taking
care
of
you
know
here,
is
that
shot
you're
moving
from
that
environment.
A
To
that
in
the
same
way
that
is,
do
you
know
essentially
says
don't
do
that
in
the
application
we're
doing
it
in
the
data
plane
of
resume.
I
should
say
these
two
services
can
communicate
or
you
inject
some
failure
or
troubleshoot
it
whatever
the
same
way
that
that
mesh
does
that
for
your
data,
that,
yes.
B
I
think
that's
a
very
good
way
of
describing
it
I
might
use
that
hanky
I.
Think
that
the
the
the
that
the
the
the
really
important
aspect
of
what
you
just
said
is
that
it's
a
generic
solution.
The
word
generic
might
not
be
the
right
word,
but
it's
a
generalized
illusion
for
dealing
with
data
snapshots
across
all
different
stages
of
software
development,
lifecycle,
independence
of
which
kind
of
databases
you're
using
independent
of
which
infrastructure
you're
running
on
whether
it's
cloud
or
on
prayer,
more
laptops
or
whatever.
B
B
So
that
would
be
one
way
to
do
it.
It's
not
the
way
that
we've
started
out
doing
it,
though
so
the
the
way
that
we
have
started
doing
it
is
instead
to
provide
a
layer
that
sits
underneath
that
each
database,
because
every
database
that
you
just
mentioned,
writes
files
to
a
file
system,
and
so
we
provide
engine
that
sits
underneath
that
just
allows
you
to
take
consistent
atomic
snapshots
of
the
file
system
state
of
those
data
stores.
B
Now
that
does
rely
on
the
data
stores
being
crash
consistent,
and
it
does
mean
that,
for
example,
we
rely
on
the
fact
that
Postgres
has
a
writer
head
log,
and
we
rely
on
the
fact
that
my
my
sequel
nodb
can
recover
from
a
power
outage,
but
all
of
these
data
stores
can
recover
from
having
the
power
ripped
out
running
on,
and
so
so
we
can
sort
of
recover.
These
atomic
snapshots
different
environments
and
we
can
take
the
snapshots
without
without
stopping
the
database.
A
That
is,
awesome
and
I
think
needed.
Otherwise
these
pieces
might
not
be
possible.
The
only
thing
I'm
having
trouble
understanding
is,
if
you're
working
on
a
file
system,
layer
and
many
you
know
bigger
or
there,
there
are
some
databases
that
actually
you
know
kind
of
bypass
the
file
system
they
better.
If
you
want
to
have
you
know,
Rob
blocks
that
they
are
dealing
with.
How
does
that
work
in
this
case?
So.
B
B
B
It
just
has
the
restriction
that
each
each
data
dot
is
only
on
one
machine
at
a
time,
but
you
can
have
many
of
them
spread
across
many
machines
if
that
makes
sense,
and
but
there
are
just
there
are
definitely
definitely
some
interesting
questions
around
how
to
deal
with
being
able
to
capture
the
state
of
a
sharded
or
distributed
database
and
I'll
just
say.
That's
sort
of
a
research
topic
that
we're
investigating
at
the
moment,
and
we
hope
to
have
a
solution
for
it
in
due
course.
A
That's
that's
I
mean
I
personally
prefer
these
kind
of
like
up
front
like
saying
look.
This
is
what
you
can
do,
and
here
the
limitations
and
whatever
over,
like
you
know,
we're
gonna
solve
all
the
problems
of
the
world
then
boiling
down
to
well
actually,
by
the
way,
in
your
case,
it
doesn't
work
and
I
will
have
to
research
follow
up.
A
Regarding
the
iPhone
at
least
my
experience
many
years
ago,
that
Oracle
be
one
of
those
who,
actually
you
know,
directly
really
relational
databases,
and
then
probably
you
know
you're
spot-on
with
most
of
the
elasticsearch
and
whatnot
they
they
actually
the
end
of
the
day.
Just
have
some
local
file
system
x4,
whatever
that,
let
us
all
the
heavy
lifting
in
the
edges
working
on
top
of
the
file
system
yeah.
The
Charlotte
thing
like
that
is.
That
is
something
where
maybe
you
know
don't
lose
yourself.
B
I
mean
there's
a
few
thing:
project
call
canister
from
a
company
called
Caston
and
I
was
speaking
to
them
yesterday
and
there's
interesting
opportunity
to
potentially
collaborate
around
that
because
Caston
are
taking
the
approach
to
that.
You
first
described,
which
is
that
you
integrate
with
each
data
store
using
the
data
store
native
backup
tools,
basically,
which
is
work
with
that
it
can
work
with
sharded
databases,
because
the
sharded
database
knows
how
to
back
itself
up
right.
So
it's
definitely.
B
It's
really
cool
that,
like
that
the
Caston
and
dot
mesh
like
exploring
these
two
sort
of
possible
solutions
to
the
space
in
parallel
and
also
the
other
things
really
cool,
is
that
canister
is
open
source,
which
is
the
the
project
that
the
Caston
have
for
actually
integrating
with
these
individual
data
stores.
So
it
may
well
make
sense
that
in
the
future
we
can
leverage
some
of
that
and
and
use
use
that
project
and.
A
Like
shifting
gears
a
little
bit
there
is
that
not
necessarily
new
itself
enough
initiative
within
communities
or
actually
work
wider
container
system
called
CSI
storage
interface?
Can
you
kind
of
like
for
audience
put
what
you
offering
you
with
not
mesh
put
that
in
relation
or
or
you
know
what
it's
the
same,
this
overlap
could
be
one
influenced
the
other
or
yeah.
B
So
so
my
understanding
of
CSI,
the
container
storage
interface
is
that
it's
exactly
that
it's
an
interface.
So
it's
a
set
of
eight,
it's
an
API
that
you
implement
if
you're
a
storage
provider
and
that's
really
nice,
because
kubernetes
is
not
saying
we're
going
to
create
storage.
They're,
saying
like
we're
going
to
let
everyone
plug
their
storage
into
kubernetes
and
so
for
us
with
dot
mesh
we
already
plug
into
kubernetes.
B
So
we
have
a
flex
volume
driver
which
is
sort
of
the
precursor
to
CSI,
and
we
have
also
a
dynamic
provisioner,
which
is
the
new
way
that
that
kubernetes
allows
you
to
do
lifecycle
operations
on
volumes
like
create
and
destroy,
and
then
the
flex
volume
driver
is
the
thing
that
does
attach
and
detach
and
I
believe
I
need
to
look
more
into
CSI,
but
I
believe
that
CSI
covers
the
Flex.
Volume
side
is
like
a
new
version
of
the
Flex
volume
driver
and
it's
just
a
nicer
interface
than
the
Flex
API
I.
B
A
Make
sense,
my
hope,
actually
is
going
a
bit
further,
really
that
be
the
this
bag
emerging
expect
world
whenever
extenders,
whatever
in.
Let's
paste,
he's
actually
informed
by
and
influence
shaped
by
what
you
guys
have
to
put
forward
there,
because
the
tree
that
makes
a
lot
of
sense
right,
I
mean
there
are
not
that
many
generic
or
actually
I,
only
know
your
work
there
you're
offering
there.
It
actually
does.
A
B
A
B
Would
I
yes,
sir,
actually
I'll
I'll
just
point
out
a
couple
of
things
so
before
I
before
I
go
through
the
demo,
you
can
see
my
screen
now
right,
cool
I'll,
just
point
out
a
couple
of
things.
The
the
website
at
mesh
calm
is
now
live
and
there's
install
instructions
on
the
home
page
because
we
put
loads
of
effort
into
making
it
just
really
easy
to
install
and
that
just
sets
up
a
local
doctor
environment
with
with
mesh
and
then
also
I
just
wanted
to
point
out
the
the
doc
site.
B
So
I'll
just
open
this
in
a
new
tab.
So
the
doc
site
is
linked
to
from
the
home
page
and
has
lots
of
interesting
information
about
what
mesh
is
and
how
to
install.
It
includes
more
detailed
installation
instructions
on
kubernetes,
for
example,
so
there's
a
set
of
tutorials
here
we
launched
with
with
nine
tutorials,
and
it
covers
sort
of
the
hello
world
and
using
dot
measures.
B
B
The
basically
we
in
this
tutorial
we've
got
a
sample
app
that
is
split
up
into
micro
services,
and
it
just
so
happens
that
there's
four
bugs
in
the
app
and
actually
there's
three
bugs
in
there
and
there's
there's
one
case
in
which
case
in
which
you'd
want
to
capture
some
data
to
use
later.
But
the
most
interesting
bug
is
this
security
vulnerability.
So
it's
we've
discovered
or
a
developer
has
discovered
how
an
unprivileged
user
can
set
the
default
image
for
all
new
users.
B
So
what
don't
mesh
allows?
You
to
do
is
to
capture
that
security
bug
and
then
over
in
the
collaboration
tutorial.
We
pretend
that
we
don't
know
how
we
caused
the
bug,
which
is
entirely
plausible.
It
might
be
possible
that
a
developer
comes
across
the
security
vulnerability
and
doesn't
actually
know
exactly
what
happened,
and-
and
this
comes
down
to
the
question
of
as
software
developers,
what
do
we
spend
most
of
our
time
doing
very
much
very
often,
we
spend
our
time
looking
for
clues.
B
So
with
what
we're
doing
is
we're
inspecting
State
to
try
and
find
clues
and
form
a
hypothesis,
and
so
what
you
can
do
is
with
dot
mesh
we're
giving
you
another
dimension
on
which
to
find
clues.
It's
no
longer
just
over
this
version
of
the
code
cause
this
problem.
It's
this
version
of
the
code
together
with
this
particular
interesting
state
that
might
be
spread
across
three
different
micro-services
databases.
B
So
anyway,
that's
that's
basically
just
sort
of
what
I
got
excited
about
when
I
was
writing
these
tutorials
is
this
idea
of
you
can
actually
use
dot
mesh
to
to
find
clues
for
my
hypothesis
and
then
do
what
we
call
reducing
the
mean
time
to
clue
and
if
you
can
reduce
the
the
average
amount
of
time
it
takes
for
a
developer
to
find
the
first
and
then
the
second
clue,
then
you
can
speed
up
software
development
and
I.
Think
that's
that's
where
things
get
really
interesting.
A
Like
I
did
the
decoder
one
that
you
have
online
there
which
is
sort
of
smooth
you
just
go
there,
clickety
click,
you
don't
need
to
set
up
anything
locally.
Awesome
that
reminds
me
a
bit
of
you
know
in
again,
coming
back
to
analogy
with
the
service
mesh
in
East
yo.
There's
this
thing
that
it
can
inject
failures
right.
You
can
say:
oh
you
know
every
third
one
is
a
4
or
4
or
whatever.
Oh,
you
can
try
it
out.
B
B
A
B
So,
just
for
everyone,
who's
watching
I,
also
encourage
everyone
to
try
themselves.
So
you
can
go
to
doc.
Mesh
calm,
slash,
try
match
it's
also
linked
to
from
the
homepage,
and
you
get
this
little
tutorial
here.
So
so
what
we've
got
here?
We've
got
this
host
environment.
We've
got
a
real
computer
running
here.
We
can
see
I
think
I
need
to
reload
the
page.
B
So
we've
got
a
real
computer
here,
you
can
see
it's
actually
running
Linux
and
then
we
can
run
through
the
tutorial
really
quickly.
So
we
can
install
the.net
client
binary
and
then
we
use
the
dot
mesh
client
binary
to
create
a
single
node
dot.
Mesh
cluster-
that's
running
on
this
machine,
and
the
only
dependency
here
is
that
you
have
a
computer
running
Linux
with
with
doctor
installed.
B
It
sets
up
a
local
dot
mesh
cluster
that
can
then
push
and
pull
data
to
and
from
the
doc
up.
So
we
can
check
that.
Well,
yes,
it's
up
and
running
it's
running
the
zero
dot,
one
release,
that's
wonderful,
and
then
we
can
go
and
clone
this
this
demo
repo.
Now
this
is
the
sort
of
simple
version
of
the
of
the
application
I
was
talking
about,
is
the
one
before
you
have
multiple
micro
services.
So
this
is
why
I
call
it
the
sort
of
a
hello
world,
because
it's
just
really
super
simple.
B
B
B
B
Beyond
the
screen
and
I
can
just
the
DM
check
out
branch,
a
and
I
switch
that
state
from
Britt
from
B
to
a
and
then
I
can
go
back
to
just
brunch
and
I'm
back
to
B.
So
it's
this
basic
idea
that
you
can
start
to
treat
your
containerized
databases
like
git
repo
and
that
that
works,
even
if
you
have
more
than
one
micro
service
and
you
can
capture
a
single
atomic
commit
that
captures
the
state
of
more
than
one
database
at
once.
So
I'll
leave
the
demo
there
because
I
know
we're
short
on
time.
B
I
encourage
everyone
to
try
the
demo,
because
the
next
step
in
the
demo
is
pushing
that
branch
to
the
dot
hub
and
then
pulling
it
down
onto
your
local
machine
to
prove
the
data
around.
But
yeah
I'll
leave
the
demo
there
to
give
people
something
to
try
at
home
as
well.
Perfect.
A
Questions
are
the
Daath
hub,
which
is
essentially.
This
is
central
like
like
a
pub
for
for
code.
Current
is
essentially
your
says
operand,
so
you
that's
right
essentially
using
that
part
but
I.
Suppose,
if
I
want
to
have
that,
you
know
in
the
enterprise
behind
the
firewall,
then
I'm
gonna
reach
out
to
your
big
sales
team.
That
will
tell
me
how
much
money
I
really
after
yes,
so.
B
That's
that's
very
well
said:
I'll,
just
I'll
just
bring
up
half
a
pricing
page
quickly,
because
if
you
go
to
dot
mesh,
then
there
was
a
section
on
pricing
it
before
I
talk
about
pricing.
It's
very
important
to
point
out
at
the
dot
mesh
itself
is
open
source.
It's
available
on
github,
don't
match
and
I'm
a
strong
believer
in
the
necessity
that
the
open
source
is
his
feature
complete
and
powerful,
and
that's
why
dot
mesh
the
open
source
is
it
supports
clustering?
B
That
said,
however,
we
are
a
business
and
we
do
need
to
make
money
and
so
we're
offering
a
hosted
version
of
dot
mesh
as
hub
comm
and
you
command
and
see
that
it's
it's
a
service
that,
for
example,
I'm
I'm
logged
in
here
as
luke,
Mazda
and
I
can
see.
Different
branches
looks
and
feels
a
tiny
bit
like
github,
and
this
interface
is
is,
is
this
is
the
start
of
the
thing
that
we're
going
to
turn
into
an
Enterprise
version?
B
So
on
the
pricing
page,
you
can
see,
that's
there's
a
free
tier,
so
you
can
come
and
try
it
for
as
long
as
you
like,
with,
if
with
a
gig
of
storage
for
free
as
soon
as
you
bump
over
that
one
gig
limit,
then
it's
a
very,
very
simple,
ten
dollars
per
per
user
per
month
for
our
developer
accounts,
but
which
is
it's
the
price
of
the
the
second
cheapest
digitalocean
droplet.
So
we
priced
it
sort
of
with
respect
to
what
developers
are
used
to
paying
for
things.
B
But
then,
as
you
start,
adding
team
and
and
business
features
and
functionality.
The
price
goes
up
accordingly
and
then
there's
the
Enterprise
version,
which,
as
we
developed
more
features
in
the
dot
hubs
that
are
specific
to
the
SAS.
Then
those
are
going
to
be
the
things
that
eventually
turn
into.
We
hope
sort
of
the
the
more
scalable
business
model
where
you
can
a
version
of
the
dot
hub
on
premise,
and
we
can
help
them
support.
A
A
Missed
that
it's
really
awesome,
I
love
it
I,
love,
I,
hope,
people
out
there
can
appreciate
it
much
as
I
do
because
awesome
you
don't
need
a
little
bit
of
a
background
in
data
to
really
get
it,
but
it's
this
is
really
kick-ass.
This
is
really
that's
the
future
and
thanks
a
lot
for
your
time.
Look
I
will
see
you
soon
in
person
continuing
discussion
over
a
pint
or
whatever,
but
communications
again.
This
is
really
awesome
and
you
know,
whoever
has
a
question,
would
just
be
able
to
reach
out
via
your
support
channels,.