►
Description
Join us for Kubernetes Forums 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
To meet regulatory and business continuity requirements, it’s critical that companies deploying a cloud-native strategy have the flexibility to deploy a multi-cloud application strategy. Major cloud vendors regularly experience outages, and organizations lose data as a result. Concerns around these outages and potential data loss, along with requirements for availability and reliability, are driving the need to be able to distribute business critical applications across multiple clouds. These concerns are changing the playing field for how companies will deploy distributed application in the cloud.
View this webinar based on a case study with a challenger bank in Hong Kong. We’ll discuss how this bank is using the NuoDB SQL database and the Rancher Kubernetes Engine to provide distributed transaction processing across multiple clouds. Join us to learn:
-Why multi-cloud environments are growing consideration for running core banking applications in the cloud
-How to achieve optimal data protection and availability for your core banking applications
-How new regulations pertaining to multi-cloud and persistent data applications may push Kubernetes to the next level
A
Good
afternoon,
good
evening,
good
morning,
wherever
you
are
welcome,
I
am
Chris
shorts,
I'm,
a
principal
Technical
Marketing
Manager
at
Red,
Hat
I'm.
Also,
a
cloud
native
ambassador
I'll
be
moderating.
Today's
webinar
fuse
how
a
few
I
see
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
attendees
sorry,
but
that's
just
how
it
works.
There
is
a
Q&A
box,
though
so
at
the
bottom
of
your
screen.
A
You
click
that
Q&A
box
feel
free
to
drop
in
as
many
questions
as
you
feel
necessary
to
get
what
you
need
out
of
this
webinar.
Also
a
friendly
reminder.
This
is
an
official
CN,
CF
webinar
and,
as
such
is
subject
to
the
CN
CF
code
of
conduct.
Please
do
not
add
anything
or
chat
about
anything
or
put
anything
in
your
questions
that
would
be
in
violation
of
the
code
of
conduct
basically
be
respectful
of
all
of
your
fellow
participants
and.
A
So
I'd
like
to
thank
you
for
joining
us
today,
welcome
to
the
today's
CN
CF
webinar
distributed
tracing
or
distributed
transaction
processing
across
multiple
clouds,
with
kubernetes
I
I'd
like
to
introduce
Joe,
Leslie
Senior
Product
Manager
at
nuodb
and
Erin
Corelli
principal
professional
services,
solution
architect
at
nuodb
who
will
be
driving
today's
webinar.
Please
take
it
away.
C
Also,
as
the
ODB
is
a
distributed
sequel
database
I
managed
the
from
a
product
standpoint
the
control
plane,
as
well
as
our
new
ODB
insights,
visual
monitoring
tool,
which
you
will
get
to
see
a
little
during
our
demo
time.
Aaron
once
you
say
a
few
words
as
well
about
your
role
here
at
Newton,
be
sure.
C
Thank
You
Aaron
all
right:
let's
go
ahead
and
get
started
yeah,
let's
so,
let's
first
review
our
our
agenda
switch
great
excellent.
Thank
you.
So
I
thought
it
would
be
good
if
we
just
started
with
you
know
a
little
setting
of
context,
and
we,
you
know,
we
define
terms
like
multi
cloud.
Also
will
do
that
today.
Also,
you
know
why
customers
are
looking
to
multi
cloud
as
a
means
to
deploy
business,
critical,
apps
and
then,
as
Erin
mentioned,
we're
gonna
review
a
case
study.
Actually
a
real
case.
C
Study
of
a
real
enterprising
Bank
that
is
going
to
you
know,
is
deploying
going
to
market
with
a
multi
cloud
infrastructure
and
there's
gonna.
Take
us
through
a
live
demonstration.
All
right,
we're
gonna
actually
show
a
kubernetes,
multi
cloud
environment
and
and
then
we'll
talk
a
little
bit
more
about
no
DB
and
and
our
participation
in
making
all
of
this
happen
for
this
particular
customer
and
then
we'll
have
some
nice
time
for
Q&A
to
make
sure
that
everyone
gets
their
their
questions
answered.
Okay.
C
So
with
that,
let's
yeah,
let's
talk
a
little
bit
about
what
exactly
is
multi
cloud.
You
want
to
make
sure,
as
we
use
terms
here
today
in
the
presentation
that
you
you
know
what
we
mean
when
we
use
these
terms.
So
first
off
multi
cloud
is
not
hybrid
cloud,
so
right
in
our
industry,
there's
lots
of
jargon,
and
certainly
in
this
new
space
of
cloud
computing
we're
not
short
for
jargon.
You
know
we
love
to
insert
words
in
front
of
things
to
make
it
possibly
more
complex
to
understand
or
come
up
with
some
new.
C
Typically
in
a
hybrid
cloud.
What
you
see
is
it's
a
little
more
rigid
and
certain
components
are
running
in
that
you
know
that
segment
only
where,
with
a
multi
cloud
and
as
I
mentioned,
you
know
we're
we're
defining
it
here.
As
you
know,
two
or
more
public
clouds,
the
idea
is
around
allowing
applications
and
their
services
to
now
move
more
freely
between
these
public
cloud
clusters.
C
C
Now,
as
I
mentioned,
that's
the
definition
we're
using
you
know
you
could
go
out
onto
you,
know
the
internet
and
in
Google
multi-cloud
you
will
find
different
definitions.
So
that's
why
I
thought
it's
important
that
you
know
I
stay
in
our
presentation
when
we
use
both
the
cloud
we're
referring
to
two
or
more
public
clouds.
C
So
what
we
wanted
to
talk
about
is
you
know
some
of
the
reasons
that
we're
seeing
that
companies
are
looking
to
the
multi
cloud
environment,
to
deploy
their
apps
and
and,
as
mentioned
just
a
little
earlier,
business
continuity
and
an
extending
the
the
availability
through
a
multi
cloud
is
actually
something.
That's
that's
now
available
and
can
reduce
vendor
lock-in.
C
If
you're
in
a
multi
public
cloud
environment-
and
let's
say
it's
made
up
of
Amazon
and
Rouge
or
you
by
nature,
will
be
more
resilient
to
any
failure,
events
that
would
occur
in
any
one
of
those
cloud
environments
because
you're
not
losing
that
entire
vendors
cloud
infrastructure,
you
would
only
be
losing
the
one
and
the
other
would
be
able
to
continue
to
run
and
support
your
applications.
So
so.
C
We
do
I
thought
it
would
be
a
great
way
to
kind
of
present
the
topic
to
talk
through
a
case
study.
This
is
a
real,
a
real
bent
that
has
implemented
a
banking
application
in
a
multi
cloud,
environment
and-
and
you
know,
when
deploying
a
multi
cloud
strategy,
but
what
we've
kind
of
come
across
is
you
know
some
industries
and
specifically
the
one
I'm
referring
to
here
in
the
banking
industry.
There
are
regulatory
requirements
that
now
mandate
the
use
of
heterogeneous,
you
know
or
disparate
public
cloud
platforms.
So
you
know
why
is
this?
C
Well,
you
know
major
public
cloud
vendors
regularly
experience
outages
now
that
might
sound
like
a
surprise,
but
it's
it
is
a
reality
know
some
of
these
out.
It
just
may
be
short,
and
you
know
the
extent
of
them
can
vary,
but
the
fact
is
they
do
experience
regular
outages-
and
this
is
actually
you
know
verifiable
right.
C
We
can
all
go
out
to
the
internet
and
Google
on
these
terms,
and
you
know
you'll
see
that
you
know
there's
actually
even
annual
reports
on
on
cloud
vendors
products
about
the
you
know:
the
outages
that
they're
reporting
and
annual
kind
of
interruptions
and
so
on,
but
so
what?
Why
is
this
important?
Well,
so,
what
happens
in
you
know
during
these
outages?
Is
organizations
can
lose
availability
or
data
or
possibly
both
right?
C
So
so
that's
why
we
start
to
look
towards
you
know
greater
protections
and
distributing
our
applications
across
different
vendor
products
and
with
multi
cloud
there's.
Actually
some
tech
enablers
that
you
know
make
this
all
possible
and
we're
going
to
talk
about
some
of
those
today.
So
one
is
kubernetes
or
frustration
right,
kubernetes
being
you
know
the
leading
de
facto
standard
you
and
you
know
open-source,
you
know
orchestration
container
management.
Basically,
you
know
a
tool
that
is
is
maturing
very
very
quickly
through
open-source
contributors
and,
as
I
mentioned
again
is
like
de
facto
standards.
C
C
We
can
see
to
the
three
milliseconds
of
delay
and
with
that
kind
of
capability
yeah,
we
can
now
start
to
stand
up
critical
banking,
apps
or
other
critical
apps
within
an
infrastructure
as
we're
describing
and
there's
also
lower
costs
associated,
so
low
cost
compute,
and
you
know,
of
course
you
know
any
kind
of
cloud.
Investment
means
that
there's
no
less
investment
in
your
own
on-prem
resources,
be
it
you
know
capex
or
you
know,
op
X
type,
investments
that
we're
seeing.
You
know,
lower
lower
costs
associated
with
these
environments
and
then
storage.
C
C
C
They
believe
that
multi
cluster
is,
is
the
right
environment
for
them
to
deploy
their
application,
and
we've
included
here
several
of
the
kind
of
reasons
that
they
landed
on
and
some
of
them
we've
covered
lightly
already,
but
in
order
to
achieve
the
highest
level
of
this
business
continuity,
they
believed
strongly
in
in
deploying
across
vendors
products
and
we'll
see
that
we
lab
is
chosen
Amazon
in
the
jour.
But
you
can
absolutely
choose.
C
You
know
other
public
cloud
environments
as
well:
the
reduce
operational
costs,
it's
really
reduced
capital
and
operational
costs
of
deploying
these
environments
and
also
the
ease
of
management
kubernetes
as
a
more
mature
platform.
Now
for
for
deploying
containerized
apps,
there
are
lots
of
options
available
now
for
managing
these
environments,
creating
a
single
pane
of
glass
or
you
know,
interface,
to
managing
and
monitoring
and
controlling
the
environments.
C
So
as
all
these
come
together,
it
makes
multi
cloud
environment
that,
yes,
a
you
know
a
company
or
institution,
even
even
banks,
as
in
this
example,
can
now
choose
the
public
cloud
environments
to
deploy
their
their
applications.
So
when
we
look
at
we
labs
environment,
we'll
just
kind
of
cover
a
few
of
the
things
I've
mentioned
some
of
them
already.
They
they
have
gone
with
a
multi
cloud
that
is
comprised
of
two
public
clouds,
Amazon
and
Azure,
of
course,
they're
using
the
kubernetes
to
deploy
their
stateful
applications
with
persistent
storage.
C
That
also
includes
the
nuodb
component,
the
no
DB
distributed
database
uses
persistent
storage
and
we'll
talk
a
little
more
about
that
as
well.
Some
of
the
the
technology
the
to
glue
the
the
to
multi
clusters
together
we're
using
some
VPN
tunneling
technology,
some
quality
of
serve
via
a
service
provider
mega
port
and
in
this
particular
deployment
we've
chosen
to
use
rancher
kubernetes
management.
In
fact
that
was
we
Labs
decision
to
go
with
Rancher
as
their
kubernetes
management
interface
and
console,
of
course,
the
the
application
itself.
C
C
So
so
so
with
that
I'm,
so
Aaron
I'm
gonna
go
ahead
and
turn
it
over
to
you,
as
as
the
one
who
actually
implemented
was
part
of
the
team
that
implemented
the
system
to
to
take
us
through
some
of
the
challenges
faced
because
I
think
for
our
listeners
today,
they'll
be
really
important
as
they're
considering
deploying
their
own
multi
cloud
applications.
What
sort
of
challenges
were
we
faced
and
and
how
we
resolved
some
of
those
those
challenges.
Sure.
B
Thanks
Jay
and
so
Joe
asked
me
to
think
about
the
challenges
we
face
and
them
you
might
recognize
a
theme
amongst
these.
These
few
examples
I've
given
hearing
a
lot
of
them
boiled
down
to
networking
I
mean
if
you,
if
you
take
each
individual
cloud
on
its
own
and
you
take
an
application
which
is
container
native
and
kubernetes
native
and
easily
deployed.
Then,
of
course,
each
of
those
is
going
to
work
pretty
well
on
its
own.
B
So
let's
have
a
good
views
that
just
face
one
by
one,
so
latency
between
clouds
now
nuodb
is
is
interested
in
latency.
We
want
the
best
possible
latency
to
get
the
best
possible
performance,
and
one
of
the
metrics
we
have
is
that
we
would
like
Layton
sees
to
be
a
lot
less
than
five
milliseconds
wherever
possible,
and
if
you
look
in
here
to
how
they
resolves
so
looks
at
latency.
B
Now,
in
the
case
of
we
lab,
we
were
lucky
in
that
they
are
using
a
mega
port
which
is
going
to
offer
a
certain
level
of
QoS
for
the
VPN,
its
operating
over
VPN
being
the
connection
between
the
two
clouds.
So
we
can
be
sure
of
a
certain
level
of
service
there,
rather
than
going
over
the
public
Internet,
which
might
be
a
lot
more
variable.
B
Now,
while
we
bring
up
this
topic
of
VPN,
it's
worth
pointing
out,
we
were
actually
concerned
here
with
two
different
layers
of
VPN.
If
you
like,
there's
a
layer
of
VPN
which
is
connecting
the
two
clouds
together,
which
lots
of
different
applications
might
run
over
and
then
separately,
we
also
have
a
VPN
which
is
being
deployed
by
nuodb
within
the
containers
themselves.
So
if
I,
if
I
reference
to
VPN
I
might
be
talking
about
one
or
the
other,
I,
might
I'll
try
and
distinguish
between
them.
B
B
Hong
kong's
also
see
not
an
enormous
place,
and
actually
the
distance
between
them
is
islamists
over
ping
times
latency
between
their
two
datacenters
isn't
actually
pretty
good
and
that's
not
to
say
you
couldn't
use
it
on
a
wider
network,
but
you
always
need
to
be
considering
those
latency
times
and
the
last
point
here,
keeping
client
connections
local
to
one
cluster.
So
this
will
depend
a
lot
on
the
topology
and
and
what
the
aim
of
using
multiple
clusters
is
in
this
particular
use
case,
and
we
we
have
a
dr
type
scenario.
B
So
the
is
your
cluster
is
a
dr
cluster
and
the
AWS
azar
is
our
primary
class
surfacing
client
connections.
Now,
that's
not
to
say
that
you
couldn't
use
them
active
active,
but
the
good
thing
here
is
that
we,
what
we
can
do
is
keep
client
connections
local
to
one
cluster
and
that
saves
having
too
many
hops
between
those
clusters
for
both
the
client
connections
and
for
retrieving
data
from
from
the
ODB
itself.
B
So
the
second
challenge
I
really
put
down
here-
is
pod
support
connectivity
between
the
clusters
themselves
so
again
related
to
networking,
and
while
we
were
looking
at
this,
we
looked
at
a
lot
of
different
options.
There's
a
lot
of
party
products
out
there,
which
could
do
this
for
you,
as
some
examples
here,
contain
the
networking
sto
service,
mesh
cilium
using
host
networking
host
ports.
But
there
definitely
are
options
out
there
and
in
most
cases,
getting
to
the
point
of
having
a
networked
multi
cluster
is
is
not
straightforward,
but
definitely
possible.
B
The
problem
is
when
you
start
looking
at
trying
to
get
existing
applications
working
over
those
solutions.
They
might
introduce
problems
which
you
then
each
change
your
product
to
to
work
with.
So
it
really
comes
down
to
a
question
of
perhaps
how
flexible
are
you
to
make
it
work
on
these
solutions
or,
if
you're,
perhaps
building
up
a
solution
from
scratch?
It
might
not
matter
so
much,
but
certainly
in
our
case,
what
we
found
is
a
lot
of
these
solutions
are
likely
to
also
be
predetermined
by
by
the
client
you're
working
with
you
know.
B
Perhaps
the
Kas
cluster
has
already
got
a
CNI
installed
and
that's
the
one
the
company
chosen
to
work
with
so
in
order
to
get
a
bit
of
flexibility
and
certainly
have
a
lot
of
things
at
our
control.
We
decided
in
this
particular
case,
to
run
over
our
own
internal
VPN,
so
this
is
new
in
DB
as
a
product
establishes
its
own
VPN
connections
between
all
the
peers
in
its
database
network
and,
like
it
says
here,
this
is
pretty
simple
effective.
It
allows
the
solution
to
be
flexible.
B
B
Third
point
here:
connectivity
from
outside
to
inside
the
VPNs
have
asset
another
challenge
now,
naturally,
if
nuodb
is
working
within
its
own
VPN
that
produces
a
barrier
to
try
and
applications
connecting
into
it.
The
obvious
answers
of
that
is
to
also
put
that
client
on
the
VPN,
but
you
know
that
might
introduce
other
problems
along
the
way
so
and
unfortunately
nobody's
quite
flexible
in
that.
In
that
respect,
and
what
we
can
do
there
is
allow
to
you,
direct
connections
using
that
in
combinations
with
the
KSR
services
are
available.
B
So
as
a
handy
flexibility
there
that
new
ID
be
allowed
us
to
work
around
that
problem
and
the
third
one
here.
Sorry,
fourth,
one
here,
the
main
databases,
stability
and
differences
of
performance
between
clouds.
So
this
this
is
a
pretty
big
one.
Actually,
when
Noah
DB
is
running
on
a
one
cloud,
perhaps
or
whether
it's
running
on
bare
metal,
you
can
get
pretty
pretty
consistent
and
you
expect
the
performance
to
be
of
a
certain
level
when
you
start
mixing
multiple
clouds.
B
What
we
found
is,
especially
with
kubernetes
as
well
the
differences
in
times
between
servers
being
provisioned,
between
pods
being
replaced
between
persistent
volumes
being
allocated
and
can
vary
quite
considerably,
and
what
we
found
was
that
that
was
causing
havoc,
sometimes
with
how
a
new
ad
be
handled,
domains
coming
up
and
databases
being
available
in
the
the
timeouts
for
default,
timeouts
that
we
were
used
to
just
just
weren't
enough.
So
in
this
particular
case,
the
the
resolution
for
that
was
to
look
at
how
many
different
ways
we
can
possibly
tune
you
a
DB.
B
Fortunately,
we
expose
a
lot
of
different
options
as
to
what
timeouts
you
can
change,
whether
it's
your
admin,
layer
or
SMS
or
two,
and
we
are
able
to
change
a
number
of
different
time
that
timeout
settings
and
address
address
them
specifically
to
the
latency
of
the
network.
So
we
can
look
at
average
latency
maximum
latency
of
the
network
over
a
period
of
time,
and
then
we
can
use
those
figures
to
apply
them
to
the
new
DB
settings
and
make
sure
it's
and
work
as
expected.
B
So
combination
of
different
issues,
they're
mostly
networking
related
and
resolutions
around
making
sure
that
we've
got
QRS
on
the
on
the
VPN,
taking
some
things
into
our
control
with
using
our
and
internal
VPNs
and
the
flexibility
of
a
ODB.
We
have
direct
connections
and
lots
of
different
tunable
options
to
make
this
work
well,.
B
So
move
on
to
the
next
slide,
so
this
is
an
example
of
the
actual
client
architecture.
A
tween
app
now
is
simplified
somewhat.
You
can
see
in
the
sense
here.
Let
me
just
get
my
pointer
up.
So
in
a
sense
here,
we've
got
a
simple
representation
of
the
VPN
connection.
Now
that
represents
both
VPN
connections.
These
site-to-site
VPN
between
clouds
and
also
the
nuodb
VPN.
You
can
see.
We've
actually
got
VPN
pods
here
running
as
well,
which
are
servicing
the
internal
VPN
connection
for
new
ADB.
B
On
the
left-hand
side,
this
is
showing
the
azure,
the
Amazon
Cloud
store
in
orange
and
the
right-hand
side.
Here
we've
got
the
azure
cloud
in
blue
that
visa,
both
Hong
kong-based.
You
might
notice,
on
the
right
hand,
side
and
in
those
year
we
don't
actually
have
availability
zones
and
that's
because,
as
you're
doing
offer
availability
zones
in
hong
kong
region
on
the
left,
you
can
see.
B
We've
got
availability
zones
there,
so
the
intent
here
really
is
to
distribute
and
the
no
DB
architecture,
the
tea
transaction
engines,
the
storage
managers
and
the
and
the
admin
processes
ensure
they're,
distributed
over
enough
different
resources
that
we
are
resilient
to
failure
in
a
number
of
different
ways.
In
this
example,
here
we
could
tolerate
failures
of
multiple
pods,
multiple
machines,
multiple
zones
and
multiple
clouds
and
still
have
an
operational
database.
B
One
thing
to
point
out
here
is
I
mentioned
before
that.
In
this
particular
case,
it
is
a
DR
scenario,
so
we
can
see
at
the
top
applications
initially
we'll
be
connecting
to
Amazon
and,
like
I,
said
before,
connections
from
client
applications
within
this
cloud
will
all
be
directed
to
transaction
engines.
Within
this
cloud
they
would
never
go
across
clouds.
The
connections
are
made
across.
Clouds
are
all
to
do
with
newer,
DB's
internal
synchronization
of
data
and
can
to
ensure
consistency
of
the
data
across
both
clouds.
B
In
a
failure
event,
the
customer
looked
to
be
moving
connections
from
the
apps
over
to
the
other
cloud,
and
that
would
be
that
could
be
automated
or
manual
process.
Of
course,
another
interesting
thing
to
point
out
on
this
diagram
is
at
the
bottom.
Here
we
have
a
tie,
breaker
zone
now
that
could
actually
exist
anywhere
and
the
most
logical
place
is
to
actually
use
a
cloud
potentially,
for
example,
you
could
use
a
google
kubernetes
engine
or
you
could
use
Rancher
deploy
to
Google
to
Google.
B
So
if,
if
we
only
had
two
clouds
Amazon
the
left
and
those
tier
on
the
right,
we
could
end
up
in
a
scenario
where
the
connection
is
lost
between
the
two
and,
if
all
processes
are
equal
on
both
sides,
we
end
up
with
the
network
partition
and
the
database
shuts
down.
So
what
this
tie
breaker
zone
is
effectively
doing
is
allowing
majority
to
be
maintained
should
that
connection
be
dropped,
and
this
is
what's
allowing
us
to
tolerate
loss
of
the
entire
cloud
or
a
connection
to
that
cloud.
B
B
Okay,
so
what
you
see
on
screen
I've
got
four
windows
open.
The
top
right
bottom
right
bottom
left
are
all
the
rancher
management
interface
and
the
top
left
up
here
is
the
new
ADB
insights
tool,
which
Joe
was
mentioning
earlier,
that
he
manages
I'm.
So
one
of
the
first
is
just
give
you
a
quick
overview
of
the
rancher
management
console.
Some
of
you
might
be
familiar,
so
you
might
be
brand
new.
Pretty
pretty
nice
way
of
looking
at
kubernetes
makes
it
very
easy
to
manage.
B
B
We
have
our
te
processes
here
and
we
have
one
of
those
running
in
Azure
and
we
have
an
SM
and
that's
also
running
on
these.
Your
side
there's
a
few
other
pods
here,
the
VPN
service.
That
is
obviously
the
connection
between
the
clouds
for
no
DB
itself.
We
have
a
YC
SB
low
generator.
So
this
is
the
Yahoo.
Your
cloud
servicing
benchmark
I
think
we
haven't
anything
started
a
moment,
but
we'll
play
with
that
shortly
and
we
have
a
few
other
daemon
set,
so
T
HP
we
require
a
transparent.
B
B
B
C
And,
as
you
mentioned
hearing
there's
always
the
live
demo
Murphy's
Law
that
will
and
always
take
effect,
but
I
think
most
our
listeners
appreciate
whenever,
whenever
we
try
to
to
show
live
demos,
it's
they're,
helpful
I'll,
just
also
mention,
while
Aaron's
waiting
for
this
one
screen
to
to
repopulate
on
the
slide.
The
demos
slide
that
it
that
Aaron
launched
from
here
it
has
two
links
to
recorded
videos.
Knowing
that
sometimes
live
demos
can
be
a
challenge.
B
Everything
else
is
very
similar
with
an
additional
monitoring,
insights
and
pod
running
here,
which
is
the
screen
you
see
in
the
top
left,
so
that
that's
an
overview
of
the
domain.
If
I
you
can
see
here,
these
are
two
separate
windows.
They're
two
separate
clusters
running
in
two
separate
clouds,
everything's,
very
distinct
and
very
independent.
The
only
key
do
we
might
have
that
something
is
linked.
Is
the
peon
service
down
here
so
in
this?
Some
bottom
left
window
now
for
draw
your
attention
down
here.
B
B
So
what
this
really
does
here
is
to
show
you
that
the
neuro
DB
is
really
seeing
this
as
one
logical
database
and
one
logical,
no
DB
domain
across
multiple
clouds
and
that
multiple
clouds
might
not
just
be
Azure
an
AWS.
It
could
also
be
Google
it
cool
to
be
on
parami
could
also
be.
It
could
be
anywhere
if
it
to
feel
where
you've
got
that
connectivity
available.
B
So
what
this
is
doing
is
this
is
an
overview
page
system
overview,
we'll
we'll
check
back
here
now
and
again
to
see
what
the
database
is
doing.
You
can
see
not
much
is
happening
right
now.
This
is
showing
us
memory
usage
per
node
as
heaps
utilization
transactions
per
node.
An
interesting
one
here
is
the
aggregate
transaction
rates
in
total
TPS,
that's
running
and
our
client
connection.
So
we'll
keep
coming
back
here
and
checking
what's
going
on
while
we're
doing
the
demo.
B
So
the
first
thing
I
want
to
do
is
I
want
to
scale
up
a
workload,
so
we
have
Y
CSB
Roy
WS
in
the
top
right
I
was
going
to
drop
that
down
and
we
have
Y
CSP
in
the
bottom
right
here,
so
go
and
drop
that
down
as
well.
So,
first
of
all,
I'm
going
to
scale
that
Y
CB
y
si
has
to
be
work,
load,
ops,
2
and
I'll.
B
So
well,
that's
some
stabilizing.
The
first
thing:
I'm
gonna
do
here
as
an
example
is
to
delete
te.
So
this
is,
this
is
a
you
know,
a
soft
way
of
simulating
a
pod
failure.
If
you
like,
let's
save
it
or
one
of
our
transaction
engines
dropped
whether
it
be
the
know
that
it
was
on
died,
it
could
be.
The
pod
itself
died
a
thing
to
do
with
causing
that
transaction,
and
you
can
stop
running
now.
B
In
this
particular
case,
we've
only
got
one
other
available
tea,
but
what
we
should
see
over
here
is
the
connection
was
dropping
off
of
one
tea
that
died
reconnecting
to
the
other
te
while
it
gets
rescheduled
bye-bye
cuban
entities
and
then
what
we
should
see
shortly
after
that
is
the
low
get
redistributed
back
to
the
restarted
te
and
all
the
time.
We
should
see
that
the
transactions
continue
running.
We
have
no
loss
of
availability
in
the
meantime,
so
this
is
stabilizing
over
here
now
on
the
left
top
left.
B
C
B
A
C
B
C
Well,
that's:
okay,
Aaron!
What
why
don't
we
go
ahead
and
continue
is
I.
Think
everyone
gets
the
main
idea
around
the
idea
of
the
ease
of
management
through
a
containerized
management
console
like
Rancher
2,
to
manage
a
multi
cloud
environment
as
well
as
how
nuodb
a
distributed
sequel
database
is
servicing
a
banking
application
or
in
this
case
a
sample
app.
But
but
you
know,
the
idea
is
the
same
with
you
know
with
the
client
that
we
we
have
implemented
me
lab.
C
Also
I,
think
you
know
some
of
the
strong
points
that
Aaron
was
making
around
our
choice
of
the
VPN
tunneling
I
think
we
want
to
also
make
you
know
clear,
as,
as
you
look
to
deploy
your
own
multi
cloud
environments,
we're
always
gonna
suggest
that
you
know
you
consider
and
look
over
the
best
possible
generally
available
options
at
that
time.
It
is
what,
while
immature
space,
it
is
continuing
to
evolve
and
improve.
C
C
C
C
Next,
he
was
going
to
demonstrate
the
resiliency
of
the
system
that
was
built
by
basically
inserting
a
failure
event
and
deleting,
in
this
case,
a
transaction
engine,
but
you
can
delete
it
or
a
transaction
engine,
a
storage
manager,
even
an
admin
process
within
the
control
plane
and
the
new
ODB
database
system
will
continue
to
operate
as
long
as
there
are
multiple
processes
of
each
process
type.
The
new
DVD
database
system
is
going
to
continue
to
run
and
process
sequel
requests.
So
it's
a
very
strong
benefit
of
the
solution
so
Aaron.
C
While
we,
when
we
jump
back
to
the
slide
deck
sure
you
could
and
yeah
again
I
think
on
the
next
slide.
It
actually
shows
those
video
links
that
I
was
referring
to
and
and
our
listeners
can
always
go
and
enjoy
stepping
through
those
at
their
own
pace.
They
all
have
text
labels
describing
you
know,
what's
happening
as
as
you
go
through
those
videos,
but
on
the
next
on
the
next
few
slides,
and
you
know
we'll
move
through
quickly,
there's
just
a
few
things
that
we
wanted
to
talk
about.
C
You
know,
and
one
is
you
know
when
and
when
not
to
deploy
a
multi
cloud
environment.
Now
you
know
really.
The
suggestion
here
is
a
multi
cloud
architecture.
Well,
while
certainly
great
for
for
this
particular
Bank
in
their
critical
app.
Maybe
not
all
applications
require
this
level
of
business
continuance.
You
know
the
bank
is
trying
to
achieve.
You
know
24
by
7
by
365
availability
and
they
were
looking
to
the
absolute
best
technologies
available.
To
do
that,
you
know
so
why
not
to
consider?
C
Well,
you
know
if
your
app
isn't
is
not
requiring
that
type
of
service
level,
then
you
you
can
likely
deploy
in
a
single
cluster
or
you
know.
Maybe
it
doesn't
need
to
be
across
heterogeneous
clouds.
You
know
you
can
go
across
to
particular
clouds
or
a
hybrid
environment
that
we
had
talked
about
earlier.
So
all
things
to
consider
on
the
next
few
slides
and
some
of
this
I'm
gonna
allow
for
your
review
as
well.
C
Once
you
receive
the
deck
for
your
own
keeping
is
just
some
slides
that
review
the
nuodb
solution
itself
as
a
distributed
sequel
database
Aaron.
If
you
could
flip
one
more
slide,
there
was
a
couple
of
areas.
I
wanted
to
point
out
in
the
architecture.
If
you'll
notice
in
the
diagram,
the
transaction
engines
are
highlighted
in
green
color
and
the
storage
managers
sort
of
in
this
yellowish
color,
one
of
the
takeaways
and
benefits
of
the
product
is
how
the
database
is
architected
such
that
the
transaction
and
storage
layers
are
independent
of
each
other.
C
This
allows
nuodb
to
scale
either
component
based
on
a
particular
workload
or
use-case.
So
to
the
left.
We
see.
You
know
this
traditional
environment,
where
the
query
processing
and
the
storage
management
management
layers
are
tightly
coupled
together
and
they
just
kind
of
stay
together
in
a
full
database
instance.
Nuodb
is
providing.
C
You
know,
flexibility
here
that
allows
nuodb
to
service
applications
in
an
in
a
greater
variety
of
ways,
also
nuodb.
If
you're
curious
about
the
type
of
sequel
it
supports
you
standar
sequel,
it
also
delivers
acid
transactional
properties.
So
you
can
trust
that
when
you
run
your
sequel
applications
that
you
are
getting
a
secure
and
consistent
atomic
transaction,
that's
being
committed
durably
to
disk.
Just
as-
and
you
know
some
if
you're
migrating
from
any
legacy
popular
database
systems,
nuodb
delivers
that
same
high
level
of
transaction
security
in
the
next
slide
actually
demonstrates.
C
Some
of
you
know
how
the
the
different
environments
that
can
be
supported-
and
this
you
know
you
can
have
some
applications
that
that
might
require
scale
out
of
the
transaction
layer
Aaron.
If
you
could
just
flip
the
slide.
That
would
be
great
yeah
thanks
here.
We
see,
you
know
the
one
at
the
top
may
be.
A
logging
application
has
many
more
storage
copies
as
where
maybe
an
H
tap
a
hybrid
transactional
and
a
little
analytical
processing
at
might
might
have
lots
of
transaction
engines
servicing
different
types
of
applications,
but
less
copies
of
the
database.
C
C
Yes,
so
so
let's
go
ahead
and
wrap
up
and
then
we'll
work
to
take
some
questions.
So
really
what
have
we
talked
about
today?
We
have
talked
about
some
rapidly
maturing
capabilities
that
that
have
effectively
allowed
multi
cloud
infrastructure
to
become
a
serious
choice
for
those
who
would
even
be
deploying
stateful
critical
business
apps
to
the
cloud
we
talked
about
kubernetes
and
network
resiliency.
C
You
know
a
lot
of.
What's
available
today,
we
could
have
only
have
dreamed
about
just
just
even
a
few
short
years
ago.
You
know
also
this.
You
know
idea
of
running
critical,
apps
and
a
single
logical,
distributed
sequel
database
across
a
kubernetes
managed
environment.
It's
it's
demonstrating
for
us
really
the
new
possibilities.
Earlier
we
talked
about
the
you
know,
true,
zero,
downtime
capabilities,
and-
and
you
know
these
these
options-
you
know
they
they,
they
really
allow
our
customers
today
and
yourselves
as
you
as
you
look
to
deploy
multi-cloud.
C
It
allows
you
to
consider
you
know
for
you
that
the
best
ways
to
deploy
these
applications
kind
of
when
you
want,
where
you
want
and
how
you
want
in
in
multi
cloud
infrastructure.
So
with
that,
why
don't
we
go
ahead
and
open
for
questions?
We've
got
a
few
minutes
left
and
Aaron
and
I
would
be
glad
to
to
answer
any
questions
that
are
are
out
there.
A
C
C
C
You
know
much
of
a
larger
percentage
of
the
database
in
memory,
so
so
they
do
kind
of
work
together
in
order
to
create
that
that
in-memory
distributed
database
performance,
ok
and
then
we
also
have
a
third
question:
is
this
in
the
same
competitor
space
as
data
stacks,
a
distributed?
Cassandra
yeah,
exactly
you're
answering
your
own
question
right?
Guess,
not
since
sequel,
verse,
no
sequel,
yes
Dwain!
That
is
correct,
so
no
DB
is
is
pure
sequel
database.
C
Ok,
it
looks
like
we
have
another
question
coming
in
as
well
from
suji
how
is
concurrency
handled
when
multiple
te
and
SE
and
SMS
attempt
to
update
the
same
underlying
database
records
in
nuodb,
so
nuodb
also
supports
a
distributed
lock
manager,
just
like
all
those
other.
You
know
legacy
mature,
relational
database
products
that
you're
used
to
so
there
is
for
each
data
atom
in
nuodb.
We
call
it
a
chairman.
They
all
have
effectively
an
owner.
C
That
is,
it's
distributed,
lock,
manager,
okay,
so
so,
basically,
two
different
writers
would
not
be
able
to
write
to
the
same
data
at
the
same
time,
whoever
establishes
the
lock
first
will
become
the
owner
and
others
will
have
to
either
wait
or
can
at
the
application
layer
choose
to
not
wait.
Ok,
so
really
it's
handled
in
the
same
way
as
other
major
relational
database
products.
B
B
B
The
new
Adibi
VPN,
which
we
are
deploying
in
order
to
operate
across
multiple
clouds,
can
optionally
also
be
TS
encrypted
and
then,
thirdly,
if
you're
operating
rather
than
over,
the
public
Internet,
if
you're
operating
virus
I
to
site
VPN,
for
example,
between
this
year
and
AWS
or
if
you've
got
a
provider
like
mega
poor,
then
there's
options
around
encryption
there
as
well.
So
that's
you
know.
Potentially
three
layers
of
encryption
you
could
use.
I
was
saying
you
you
should
or
or
would
use
all
of
those,
obviously
Dave
might
add
latency
as
well,
but
yeah.
C
Thank
You
Aaron
appreciate
some
further
insights.
There
I
think
that
wraps
it
up
for
us
Chris,
so
I
guess
so
from
our
side,
myself
and
Aaron.
We
were
delighted
to
present
to
the
group
today
it's
a
fascinating
topic
and
we
were
glad
to
sure
to
share
our
experiences
as
we
have
deployed
multi-cloud
for
one
of
our
banking
applications.
So
whenever
considering
a
sequel
application
in
the
cloud,
we
do
hope
you
may
call
upon
us.
As
this
is
an
area
we
have
a
lot
of
experience
and
we
we
look
forward
to
perhaps
crossing
paths
again
awesome.
A
Thank
you,
Joe
and
Aaron
for
the
presentation
today,
the
webinar
recording
will
be
in
slides
will
be
available
online,
hopefully
later
today
at
CN
CF
that
io
/
webinars
with
an
S.
If
you
have
any
questions
or
concerns
ahead
there
and
wait,
you
know
feel
free
to
look
for
the
video
and
reach
out.
If
you
have
any
other
questions
for
the
gentlemen
call
today
and
without
further
ado,
see
you
at
the
next
CN
CF
webinar
in
the
future
and
have
a
great
day
thanks.