►
From YouTube: Next-Gen Protection Platform for Next-Gen Applications
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
I'd
like
to
thank
everyone
for
joining
us
welcome
to
today's
cncf
webinar.
Next,
in
jada
data
protection
for
next-gen
applications,
I'm
libby,
schultz
and
I'll
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenter
today,
deepak
verma,
director
of
product
strategy
at
zerto,
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen,
separate
from
the
chat
box.
A
A
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
webinar
page
at
www,
dot,
cncf,
dot,
io,
slash
webinars.
B
Oh
thanks,
libby
and
thanks
everyone
for
attending
this.
This
session
so
kind
of
a
little
background
on
what
I'm
going
to
talk
through
today
and
it's
pretty
simple
I'll
introduce
who
we
are
in
a
minute.
But
the
the
genesis
of
this
is
that
a
lot
of
customers
were
asking
us
to
develop
something
for
containers
and
kubernetes
application
protection
and
rather
than
force
fitting
an
existing
product
or
a
legacy
product
into
a
cloud
project
cloud
native
applications.
B
A
B
Share
with
you
today
was
some
of
the
data
points
that
we
gathered
from
the
market
as
well
as
how
we
converted
those
into
design
considerations
for
for
developing
a
new
platform
a
little
bit
about
me.
First,
I
have
a
lot
of
years
of
experience
in
data
protection
by
choice
or
lack
of
choice.
B
I've
been
doing
dr
since
y2k
days,
my
first
job
was
at
a
bank
preparing
for
for
the
y2k
crisis
that
never
happened,
but
a
lot
involved
a
lot
of
dr
testing
of
various
operating
systems
at
the
time
through
the
years.
Obviously,
technology
has
changed
and
evolved
and
learned
new
technologies.
In
the
recent
years,
I've
focused
quite
a
little
bit
on
various
cloud
platforms,
specifically
public
cloud
platforms,
and
I
am
a
huge
supporter
of
designing
applications
in
a
cloud-native
manner.
B
I
think
it's
the
future
of
applications
for
us
as
a
side
note,
I
am
an
avid
biker
road,
biker
and
there's.
B
B
Deserto,
where
I'm
a
director
of
product
strategy,
part
of
the
product
organization,
so
this
means
I
talk
to
a
lot
of
customers
as
well
as
interface
with
our
engineers
and
product
owners,
to
really
design
our
products
to
meet
the
requirements
of
our
customers.
B
Our
customers
next
gen
applications,
so
we
can
bring
it
to
market
a
little
about
zerto
we've.
We
just
crossed
our
11th
year,
actually
11th
anniversary.
Just
last
week
we
have
over
8
000
customers
and
we
we
provide
a
single
platform
for
disaster,
recovery,
backup
and
recovery
as
well,
and
it's
been
primarily
focused
around
vms
entirely.
So
we
started
out
when,
when
vms
were
a
new
thing,.
A
B
Customers
were
thinking
about.
How
am
I
going
to
protect
my
applications
that
I'm
going
to
put
on
vms
now
we're
at
a
junction
point
as
well,
where
there's
an
evolution
happening,
a
lot
of
environments
and
the
same
questions
are
being
asked
of
us
for
cloud
native
applications,
specifically
around
containers
and
kubernetes
applications.
B
So
this
is
what
I'm
sharing
with
you
guys
to
together
some
of
the
data
that
we
wanted
for
designing
our
our
own
platform.
One
of
the
data
sources
that
we
had
tapped
on
was
enterprise
strategy
group
to
actually
run
a
survey
for
us
across
enterprises
in
the
americas,
and
the
objectives
of
the
survey
were
pretty
simple
and
by
the
way
these
results
are
published
on
msg's
website.
B
You
can
also
get
it
from
zebra.com
if
you
want
to
look
at
the
full
details,
but
I'll
be
going
through
just
a
few
of
the
the
highlights
that
that
are
relevant
for
for
the
design
of
our
solution.
So
what
we
want
to
look
at
was
first
market
adoption.
Obviously,
in
this
community
there's
a
you
know
where
we're
living
and
breathing
containerized
applications,
kubernetes
and
all
the
the
various
platforms
associated
with
it
on
a
daily
basis.
B
But
we
want
to
see
what
the
penetration
was
in,
what
I'll
call
traditional
enterprise
organizations
and
also
with
that
understand
what
some
of
the
challenges
were?
Not
just
specific
data
protection,
but
beyond
data
protection,
and
along
with
that
it
was.
It's
been
a
change
in
looking
at
the
persona
from
a
standpoint
of
who's
making
the
decisions.
How
are
these
applications
being
architected?
How
are
they
being
brought
into
production
and
who's
responsible
overall
for
the
decision
making?
B
That
was
important
for
us
and
and
then
lastly,
also
looking
at
the
features
you
know,
what
features
would
be
will
be
important
for
for
an
application
that
would
or
platform
that
would
provide
a
certain
level
of
challenge
reduction
in
this
environment.
So
these.
A
B
Four
kind
of
areas
that
we
were
looking
at
from
a
high
level
and
a
survey
was
done
back
in
in
june
of
this
year
and
we
had
a
good,
healthy
set
of
customers
responding
about
334.
B
It
was
primarily
focused
around
north
america,
us
and
canada
just
for
me
for
making
it
a
quick
turnaround,
time
frame
and
it
was
limited
or
narrowed
down,
scope,
narrowed
down
to
folks
professionals,
who
were
responsible
for
application
environments,
strategy
specific
to
do
with
containers
kubernetes,
and
we
got
a
good
representation
across
both
the
size.
B
B
So
we
got
a
very
good
representation
both
from
size
as
well
as
from
industry.
Vertical
and
again,
you
can
look
at
the
full
results.
So
first
thing
was:
we
wanted
to
see
what
is
it
that
customers
were
using
containers
for
what
type
of
applications
were
they?
What
are
the
running
containers,
primarily
because
the
the
adage
out
there
is
it's
for
stateless
workloads
and
that's
how
it
how
containers
have
really
grown,
but
what
we
were
pleasantly
surprised
to
find
is
that
quite.
A
B
B
Pipelines
you're
going
to
find
state
in
there
as
well.
I
particularly
like
the
any
application
being
deployed
because
I've
heard
that
from
a
lot
of
customers,
I've
talked
to
where
you
know
any
future
applications
they're
building
in
a
cloud-native
manner
and
some
will
have
state
and
some
will
have
some
will
be
stateless.
B
So
from
our
design
perspective,
what
that
meant
for
us
is
that
that
we've
seen
an
evolution
where
more
state
is
being
put
inside
a
container,
so
more
persistence
is
being
put
inside
companions
applications
and
we
believe
also
speaking
for
personal
experiences,
both
as
a
as
a
user
is
that
this
is
primarily
to
avoid
lock-in.
If
I'm
designing
an
application,
and
I
have
to
rely
on
state
coming
from
vms
now,
those
vms
are
essentially
part
of
my
application.
I
have
to
worry
about
that
aspect.
B
I
can
go
with
the
assumption
that
another
group
takes
care
of
that
and
ensures
that
those
applications
are
always
available,
but
that
really
breaks
the
architecture
of
my
application.
The
same
thing,
kind
of
extends
to
pass
and
sas
services
that
are
available
specifically
from
a
lot
of
the
public
cloud
vendors.
They
always
have
flavors
that
are
associated
with
with
that
specific
cloud
platform,
and
it
makes
it
hard
to
to
be
flexible
in
in
movement.
B
B
I
have
better
services
that
they're
offering
on
that
platform
if
I've
integrated
with
pas
and
sas,
that
makes
it
a
little
difficult,
whereas,
if
I
put
state
within
within
my
cloud
native
application
within
the
containers,
I
can
build
both
my
stateless
and
my
state
full
to
the
different
cloud
platforms.
So
we
think
flexibility
and
that
avoiding
that
lock-in
is
another
driver.
B
So
what
this
meant
for
us
is
really
looking
at,
protecting
and
and
recovering,
as
well
as
providing
all
the
use
cases
for
both
the
state
full
components,
as
well
as
the
stateless
components.
B
If,
if
it
purely
just
focused
on
on
the
on
the
stateful
components,
then
the
challenge
would
have
been
that
the
stateless
entities
that
you
need
would
still
need
to
have
to
be
brought
up,
and
especially
when
it
comes
to
recovery
times
that
can
start
becoming
a
challenge.
So
that
was
a
very
critical
design
component
for
us
and.
A
B
Feel
that
this
is
a
way
in
the,
especially
in
the
upcoming
year,
where
a
lot
of
applications
will
evolve
to
having
both
state
and
state
full
as
part
of
the
application
set,
so
obviously
being
primarily
focused
the
in
the
recovery
area
of
the
industry.
One
important
question
that
comes
to
top
of
mind
is
well:
what
is
what
does
recovery
mean
for
these
customers?
What's
what
are
rpos
and
what
are
rtos
that
they
want
to
achieve.
B
B
That
the
entire
graph
has
shifted
left.
What
I
mean
by
that
is
if
the
survey
was
done
three
years
ago,
just
as
you
know,
as
recent
as
three
years
ago,
a
lot
of
the
application
respondents
would
have
been
okay
with
four
hours,
eight
hours,
even
even
24
hours,
but
we
see
that
now.
We've
we've
essentially
narrowed
the
scope
and
really
limited
the
limited
field
of
loss
to
men.
Just
minutes
where
the
estimated
mean
the
average
running
mean
for
for
the
survey.
Results
was
about
22
minutes.
A
B
Agent,
based
anything
that
streams,
data
from
the
application
to
get
a
copy
for
protection
purposes
completely
is
out
of
the
equation.
It's
just
way
too
short
of
a
time
frame,
and
it
really
puts
snapshot
based
approaches
into
into
question
as
well,
because
if
I
I
was
doing
a
little
bit
of
quick
math
before
before
the
presentation
here
and
if.
B
B
Systems
that
are
providing
snapshot
based
approaches
really
tackle
that
so
the
second
question,
obviously
again
being
very
resilient
focused,
is
looking
at
the
recovery
times.
So
for
those
who
are
not
from
the
dr
industry,
what
that
really
means
is:
how
long
can
you
tolerate
from
a
lost
point,
to
bring
an
application
up
and
again
very
interesting
everything
had
kind
of
shifted
left
in
terms
of
the
scale
and
with
the
estimated
mean
being
around
2.8
hours
so
from
when
you
look
at
2.8
hours?
What
is
it?
What
does
that
really
mean?
B
B
B
B
B
I
think
that
obviously,
dr
and
recovering
the
cloud-based
platforms
is
is
extremely
appealing.
It's
always
available.
You
just
have
to
you
know,
make
sure
your
your
payment
method
is
up
to
date
and
you
can
start
spinning
things
up
and
then
it's
a
matter
of
bringing
your
data.
A
B
What
this
also
means
for
us
from
a
design
perspective
is
that
orchestration
kind
of
starts
becoming
important,
so
what
we
did
from
a
design
standpoint
is
eliminated
from
our
core
design,
any
need
to
have
any
specific
application
agents
that
would
use
a
traditional
streaming
method,
essentially
a
copy
data,
kind
of
method,
or
and
and
also
eliminate
any
snapshots,
because
that
becomes
a
management
nightmare.
A
B
Running
snapshots,
every
22
minutes
starts
becoming
a
challenge,
especially
on
the
side
of
the
graph,
that's
lower,
so
we
approached
it
with
a
continuous
manner.
What
that
means
is
that
for
persistent
data
we
design
technology
that
would
allow
us
to
continually
stream
the
changes
from
the
applications
on
the
persistent
volumes
of
the
applications
on
a
continuous
basis,
which
allows
for
extremely.
A
B
B
Points
to
manage,
and
as
a
user,
you
may
only
be
concerned
with
specific
ones,
so
I
may
be
concerned
with
a
point
at
every
hour
or,
more
importantly,
I'm
about
to
push
a
change
out
into
into
a
production
application.
I
know
I
can
roll
that
back
with
kubernetes
for
that.
For
that
reason,
but
how
about
the
persistent
data
would
be
really
nice
if
I
could
tag
that
checkpoint,
essentially
bookmark
it
to
say
this
isn't.
B
This
is
special
to
me
because
I'm
about
to
put
to
change
out
and
if
anything
goes
wrong,
I
can
roll
that
back
so
giving
the
ability
to
having
both
both
low
checkpoints,
but
also
the
ability
to
bookmark.
Specific
checkpoints
was
important
for
our
design
and
then,
along
with
that
was
the
ordered
recovery
of
applications.
It's
something
that
we've
traditionally
delivered
in
that
in
vm
space,
but
we
had
to
start
thinking
around
what
that
really
means
for
microservices
for
distributed
applications.
There
are
still
some
dependencies.
B
I
know
grenades
has
a
standard
timeout
periods
built
in
which
can
be
which
can
be
changed,
but
would
be
really
nice
if,
for
example,
my
mongodb
came
up,
that's
running
in
a
continuous
environment
came
up
in
a
specific
period
of
time,
and
only
when
it
was
up
and
running
my
higher
layer
applications
essentially
came
up.
So
that's
that
was
an
important
design.
Consideration
is
to
try
to
crack
the
an
ordered
recovery
method
for
for
applications
as
part
of
our
our
design.
B
So
what
when
you
consider
ordered
applications?
What
comes
to
mind
is
also
multi-container
applications,
so
by
essence
running
a
lot
of
microservices
or
application
that
is
relying
on
dozens,
if
not
hundreds
of
little
microservices,
there
is
ordered
recovery,
but
also
there
is
consistency,
consistency
that
needs
to
be
needs
to
be
insured.
B
B
Like
I
said
dozens
of
dozens
to
hundreds
of
microservices,
obviously
we
don't
care
about
this,
the
consistency
in
the
stateless
ones,
but
for
the
stateful
ones.
That
does
become
important
so
as
well
as
you
know,
boot
order
of
that
recovery.
B
So
from
up
from
our
standpoint-
and
this
is
where,
from
a
design
standpoint,
we
really
had
to
think
hard
and
learn
hard,
learn
more
about
the
cloud
native
design
of
applications
and
come
up
with
a
storage
agnostic
way
of
ensuring
volume,
consistency,
and
I
think
there's
there's
benefits
to
that,
and
that's
primarily
that
if
ideally
I'd
want
to
design
an
application
that
can
run
anywhere
on
whatever
storage
is
available
to
me
on
that
specific
platform.
So
I
could
have
parts
of
an
application
running
on
prem.
B
B
Distributed
across
multiple
clouds
and
multiple
locations
and
they'll
use
multiple
services,
storage
services
underneath
them,
and
if
I,
if
we
limited
awareness
or
design
to
a
specific
storage
platform,
then
the
challenge
becomes
that
that
now
is
a
design
consideration.
So
we
had
to
design
a
method
where
we
could
ensure.
B
Excuse
me
would
be
that
different
applications
would
be
able
to
ensure
that
they
come
up
to
the
same
point
in
time.
Then
I
don't
have
to
deal
with
rolling
back
certain
parts
of
the
application
rolling
forward
other
parts
of
the
application
to
get
get
it
consistent.
So.
B
Aspect,
the
second
design
element
was,
was
the
entire
application,
so,
with
consistency,
the
driving
factor
was
the
entire
application.
From
our
standpoint,
what
that
meant
was
looking
at
all
the
elements.
So
obviously
the
stateful
sets
the
stateful
parts
of
the
applications,
but
also
the
stateless
components.
B
So
the
services,
the
config
maps,
the
deployment
templates,
bringing
up
all
the
elements
of
that
application
along
with
the
persistent
parts
so
that
we
can
so
that
that
entire
application
can
be
recovered
as
a
whole
and
that
that's
been
from
our
design
standpoint,
pretty
pretty
heavy
lift
just
because
of
the
variety
of
kubernetes
applications
to
be
that
we
get
the
the
different
asp,
the
different
areas
in
which
the
important
data
can
reside.
Some
can
be
residing
within
within
secrets.
A
B
Can
be
residing
within,
let's
say
within
you
know,
helm
installer.
How
do
we
bring
all
of
that
together,
along
with
persistent
data,
so
that
when
a
business
says
recover
that
application
everything
else
is
is
recovered?
Along
with
that?
So
there's
a
there's
a
lot
of
work,
and
I
think
this
is
an
area
that
we're
going
to
continue
evolving
in
and
growing.
A
B
The
and
the
as
the
landscape
changes
as
well,
and
then
we
introduced
a
concept
from
from
virtual
from
our
10
years
of
experience,
protecting
virtual
environments
of
really
this
concept
called
virtual
protection
groups,
which
would
be
a
super
set
here
to
the
various
artifacts
models
that
are
available
in
kubernetes.
So
putting
multiple
deployments.
Putting
multiple
stateful
sets.
Putting
multiple
demon
sets
into
one
logical
protection
group
so
that
entire
entity
is
is
treated
as
one.
So
we
created
a
superset
if
you
will
from
a
design
standpoint.
B
That
is
a
environmentally
aware
of
what
the
specific
kubernetes
components
are,
but
b
can
give
you
a
set
that
that
incorporates
all
this,
and
so
this
is
learning
from
10
years
of
experience
that
we
have
kind
of
bringing
the
best
of
breed
of
that
and
applying
it
to
cloud
native
technologies
and
from
a
design
perspective
that,
for
us.
A
B
Been
you
know,
another
challenge
that
we
had
to
overcome
because
it's
it
it's
easy
to
tag
or
capture
vm.
It's
a
thing:
it's
a
it's
a
state,
but
within
kubernetes
applications.
There
are
a
lot
of
them.
A
B
They're
used
in
different
manners
so
being
able
to
identify
all
of
those
and
ensure
you
can
capture
everything
has
been
was
been.
Obviously
a
heavy
lift
from
our
stand.
Expect
is,
you
know,
nonetheless
important
so
when
we
focus,
let's
shift
a
little
bit
of
focus
from
design
of
the
back
into
the
application
recognizing
the
environment.
B
The
next
part,
the
next
question
in
the
survey
that
was
interesting
is
orchestration
of
this,
so
you've
got
it
you've
captured
it.
You've
ideally
identified
all
the
elements
of
the
application
that
need
to
be
protected,
but
now
something
bad
happens,
and
you
know
we
will
be
able
to
recover
that
and
perform
operations
of
it
how's
the
orchestration.
How
important
is
the
orchestration
you
know,
and
unsurprisingly
this
was
by
majority
said
yeah.
This
is
definitely
has
importance,
importance
to
them
from
an
orchestration.
B
B
This
is
an
area
that
we
had
to
really
tap
on
our
other
side
of
the
house
that
has
been
dealing
with
orchestration
and
build
some
of
the
orchestration
components
in
there,
and
we
we
took
three
completely
new
approaches
that
we
traditionally
have
not
used
in
in
the
in
our
traditional
vm
spaces
at
all
and
the
first
of
them.
First
of
it
was
data
protection
as
code.
B
This
was,
we
call
the
data
protections
code
and
what
we
mean
by
this
is
rather
than
us,
going
out
and
trying
to
identify
all
the
different
components
of
the
application
that
he
protected,
put
the
onus
on
more
of
a
devops
centric
personality
or
persona.
What
I
mean
by
that
is,
if
I'm
a
devops
engineer,
I
know
better
than
anybody
else.
What
needs
to
be
done
with
this
application?
There's
certain
slas
that
need
to
be
met.
So,
as
I'm
deploying
this
application
to
my
enterprises,
requirements
it'd
be
fairly
easy
for
me
to
say
yeah.
B
I
would
like
this
protected,
so
what
we
essentially
did
was
tap
on
annotations
in
yaml
deployment,
declarative
deployment
templates
and
added
a
new
annotation
called
vpg
that
it
goes
back
to
that
virtual
protection
group
I
talked
about.
I
can
push
this
this
deployment
that
I'm
giving
an
example
of
into
a
specific
group,
so
I
can
say
hey.
This
is
my
test
group,
and
I
want
you
to
ensure
that
this
is
bundled
with
the
rest
of
the
apps
and
objects
and
staples
even
sets
that
I
I'm
going
to
annotate
in
the
same
manner.
B
So
what
annotations
allowed
us
to
do
is
really
push
the
onus
on
the
front
end
rather
than
taking
this
sledgehammer
approach
of
everything
needs
to
be
protected
which
drives
us
drives
up
costs.
It
drives
up
management
and
drives
up
infrastructure
network
requirements
along
along
with
it
as
well.
So
with
data
protection
as
code,
it's
as
simple.
As
you
know,
I've
got
a
deployment.
I
annotate
it.
B
If
I
want
it
to
be
in
a
specific
group-
and
I
can
annotate
it-
I
can
remove
that
annotation
redeploy
and,
while
I'm
out
of
that,
that
allowed
us
to
really
fast-track
integration
into
for
orchestration
purposes.
The
other
part
which
unanimously
has
been
you
know,
accepted
by
a
lot
of
customers.
I've
talked
to
in
this
area
has
been
apis
that
everybody
wants
to
use.
B
A
B
Set
of
ways
to
learn
to
manage
the
protection
of
an
application
in
kubernetes
environment,
we
essentially
extended
the
api
which
any
given
any
other
platform.
It
would
be
very
hard
to
do,
but
the
extensibility
of
of
kubernetes
just
made
this
super
simple
for
us
to
to
employ
them
and
then
and
then
comes
the
the
configuration
itself
of
the
the
components
of
the
application.
Again.
Why
not
take
a
very
a
cloud
native
approach
and
do.
A
A
B
So
that
that
gives
us
kind
of
a
overarching
view,
but
if
we
l,
if
we
peel
the
onion
back
a
little
more
dig
a
few
layers
deeper,
we
started
looking
at
specific
feature
importance,
and
so
what
features
did
the
respondents
want
in
the
capabilities?
An
important
note
on
this?
Is
you
know
multiple
choices
were
allowed,
so,
unsurprisingly,
multi-cloud
support
this.
This
goes
in
line
with
the
promise
with
kubernetes
and
computer-based
applications.
I
should
really
have
that
portability.
A
B
Kubernetes-
and
you
should
be
able
to
you-
should
be
able
to
run
it
on
that
platform.
So
multi-cloud
support
was
was
one
of
the
top
features
access
to
apis
again,
unsurprisingly,
one
of
the
top
top
requirements
in
terms
of
feature
capabilities
and
what
what
they
were
less
concerned
was
was
about.
B
Is
its
policy
engines
or
having
a
specific
gui
for
management,
primarily
because
we
want
to
build
protection
of
applications,
just
as
as
we
would,
the
deployment
of
applications,
it
should
be
part
of
our
our
app
deployment
cicd
and
certain
things
should
just
happen
when
applications
get
pushed
or
new
applications
get
get
brought
into
production.
B
With
that,
it
was
about
going
native
with
the
application,
so
the
one
thing
that
we
wanted
to
avoid
was
the
let's
say
from
an
engineer,
standpoint
and
being
a
huge
supporter
of
cloud
native
is
to
design
an
application
outside
of
the
cloud
native
approach
of
application
of
design
elements
for
applications.
What
I
mean
by
that
is
the
last
thing
is:
I
want
to
have
a
windows
server
sitting
somewhere
with
a
backup
application
that
can
essentially
back
up
my
kubernetes
or
pull
my
kubernetes.
It's
it
it's
it's
moving
forward.
B
A
A
B
So
we
wanted
to
ensure
that
that
was
platform
independent
and
going
with
the
kubernetes
native
application
was,
you
know,
alleviated
some
a
lot
of
those
challenges
and
as
the
intricacies
and
interdependencies
for
us
and
then.
B
Scaling
with
the
environment,
so
you
know
in
the
being
in
this
industry
for
a
long
time
what
I've
always
kind
of
found
frustrating
is
you've
got
production
running
on
one
side
and
they've
got
all
the
side
elements,
so
one
of
them
could
be.
You
know,
protection
and,
as
you
scale,
production
which
you're
planning
for
and
it's
part
of,
the
growth
cycle,
capacity
planning
cycle
and
somebody
the
last
minute
realized.
Oh
yeah.
We
can't
do
that
because
we
got
a
spend
x
on
growing
the
environment.
B
It's
back
up
and
now
we've
got
a
dependency,
so
scaling
with
the
import
environment
was
important,
whether
you're
scaling
up
nodes
are
becoming
more
powerful
or
if
you're
scaling
out
by
by
growing
cluster
sizes.
We
wanted
to
be
able
to
scale
along
with
that
and
not
not
hamper
again.
B
Element
of
a
good
kubernetes
application,
so
what
we
ended
up
when
we
put
all
these
design
elements
together
was
essentially
a
very
simple
application.
We
have
a
a
manager
which
is
essentially
a
a
stateful
pod
that
runs
runs
within
a
cluster.
Only
one
instance
is
is
really
required
and
it's
a
point
for
for
management's,
a
point
for
for
all
the
brains
of
the
on
the
operation,
and
then
we've
essentially
got
these
workers
that
do
the
heavy
lifting
we
call
them.
B
The
replication
engines
that
own
the
copies
of
the
persistent
data
that
own
the
copies
of
the
continuous.
I
o
that
flows
between
applications
and
owns
the
the
journaling
function,
essentially
providing
the
continuous
backup
and
the
continuous
replication,
and
these
are
the
replication
engines
and
that's
a
that's.
A
demon
set
that
that
runs
on
every
node
and
again
beauty
of
kubernetes.
A
B
We
don't
have
to
manage
it,
we
just
tell
kubernetes
here's
here's
the
demon
set
and
here
all
of
its
requirements
and
kubernetes
goes
ahead
and
makes
sure
that's
always
available.
It
could
be
deployed
in
one.
B
Be
deployed
and
another
another
cluster,
and
we
try
to
cut
down
a
lot
of
traditional
components
that
you
would
find
in
say
an
outside
approach
in
order
to
protect
this
makes
it
super
lightweight
and
it
grows
with
the
cluster.
If
your
nodes
grow
up
in
scale
up,
then
the
zre
components-
stateful
demon-
sets
grow
with
it.
If
you
scale
out
your
cluster
with
a
lot
more.
B
B
Or
across
the
cluster,
so
a
really
simple
architecture
model
is
is
what
we
ended
up
with
and
then
I
you
know
generically
referred
to
it
as
cluster
one
and
cluster
two
in
this
diagram,
because
the
idea
is
it
shouldn't
matter
where
that
cluster
is
running,
whether
that
that's
a
kubernetes
is
a
service
master
or
from
one
of
the
cloud
providers
out
there,
whether
it's
your
own
flavor,
that
you've
picked
on
prem,
whether
it's
running
on
physicals
or
it's
running
on
virtuals,
you
know
pick
your
hypervisor.
B
It
shouldn't
really
matter
to
us
as
long
as
we
can
recognize
what
are
the
different
positives,
you're
deploying
that
you
need
protected
and
identified
persistent
data
behind
it.
B
This
is
where
we
kind
of
followed
what
we've
learned
over
the
last
10
years
with
our
vm
side
of
the
house,
customers
really
like
and
that's
giving
a
quick
dashboard
one
screen
to
show.
How
is
all
my
protection,
you
know
where,
where
is
it
going
from?
Where
is
it
going
to
how
many
stateful
sets
on
the
employment
services,
big
maps,
I'm
protecting?
What's
my
history?
Essentially,
what's
my
rpo
history
of
rpos
that
I'm
maintaining
and
then
what's
my
running
rpo
that
I
can
achieve
set
slash
for
them,
trivial
alerts,
etc?
B
Another
interesting
survey
question
that
we
asked
was
around
skill
sets,
so
this
is
obviously
important.
This
is
important
for
a
lot
of
organizations
is
getting
the
right
right
skill
sets
and
for
those
of
you
kubecon
virtual
this
year,
and
then
you
know
there
was
an
entire
job
board.
B
So
it's
pretty
used
to
kind
of
see
that
and
the
number
of
postings
that
are
that
are
out
there
for
for
the
skills
in
this
area
and
that's
obviously
a
challenge
that
that
a
lot
of
organizations
have
it's
folks
that
can
understand
the
needs
of
an
enterprise
but
also
understand
the
cloud-native
way
of
designing
applications
and
what
would
be
needed
in
there.
So
to
that
end
I
mean
we
can't.
We
can't
fix
the
people
problem,
but
we're
trying
to
do
the
best
that
we
can.
B
It
has
a
lot
of
material
on
how
we're
designing
the
application,
what
we're
doing
and
as
part
of
our
kubecon
was
the
first
time
we
attended
kubecon
this
year
virtual,
we
introduced
a
hands-on
lab
we're
giving
a
customer's
ability,
or
anybody
actually
ability
to
sign
on
and
run
and
test.
What's
up
what
our
beta
product
looks
like
in
a
in
a
live,
kubernetes
environment,
it's
running
on
a
cloud
platform
pay
for
it.
B
They
don't
have
to
worry
about.
You
know,
standing
up
for
a
separate
kubernetes
test
environment
having
to
go
through
all
the
infrastructure
and
security
and
network
concerns
and
and
requirements
before
getting
the
environment
up
and
running.
So
we've
got
that
controlled,
and
anybody
can
essentially
sign
on
to
my
zerto
and
do
the
lab.
B
We
also
have
a
tech
preview
that
we're
downloading
so
far
our
standpoint,
the
product
to
beta
right
now
we're
getting
a
lot
of
customers,
a
lot
of
partners,
a
lot
of
tech
partners
as
well,
which
includes
the
cloud
vendors,
kicking
the
tires
and
giving
us
feedback,
but
from
a.
B
A
B
Really
understanding
what
those
requirements
are
for
those
applications
and
then
trying
to
design
a
new
platform
and
then
the
approach
that
we're
pretty
pleased
with
is
designing
a
cloud
native
application
for
cloud
native
applications
versus
having
to
force
fit
a
legacy
application
which
comes
with
a
lot
of
baggage.
If
you
will,
you
know,
in
order
to
provide
resiliency
backup
protection
for
these
applications
and
the.
B
Day,
I
think,
is
pretty
simple,
which
is
if
we
can.
A
B
You
make
it
easier
for
you
to
get
your
application
to
production
sooner
by
checking
off
all
the
governance
marks
requirements
so
yeah.
You
know
his
backup
coverage
his
dr
cover
can.
Can
you
recover
the
application
in
the
event
of
a
loss,
whether
it's
you
know,
local
or
or
regional?
If
we
can
check
those
boxes
and
help
you
get
a
cloud
native
application
out,
that's
kind
of
what
we're
aiming
for.
B
So
it's
been
an
interesting
journey,
incorporating
cognitive
methods
into
into
traditional
application
approaches,
but
you
know
one
where
we've
learned
a
lot
so
hopefully
being
able
to
share
some
of
our
design
elements,
some
of
what
we
considered
in
order
to
design
ours
and,
like
I
said
the
esg
report
is
available.
We
sponsored
it
from
zerta.com
and
if
you
are
interested
in
looking
at
the
rest
of
the
survey,
questions
for
which
there
were
plenty
anyways.
So
thank
you
and
stop.
B
See
if
anybody
has
any
questions.
A
Great,
thank
you
so
much.
Everyone
with
questions
go
ahead
and
pop
them
into
the
q,
a
tab
at
the
bottom
of
the
screen.
Those
will
populate
and
we
can
get
to
your.
B
A
A
B
No,
I
would
just
say
you
know,
go
to
zerta.com
and
we're
gonna,
hopefully
ga
a
product
next
year,
and
it's
been
a
tremendous
support
from
the
cnc
community
to
get
us
this
point.
So
we
look
forward
to
working
with
this
community.
A
Awesome
well
thanks
so
much
for
a
great
presentation
and
we
will
go
ahead
and
wrap
it
up.
Thank
you.
Everyone
for
joining
us
today.
The
webinar,
recording
and
slides,
will
be
up
online
on
the
website
later
today,
and
we
look
forward
to
seeing
you
at
another
cncf
webinar
soon
everybody
have
a
great
day.