►
Description
The Journey to Cloud Native - A Case Study with Mantl.io
Developers are driving the market for cloud consumption and leading each industry into the new era of software defined disruption. There are no longer questions about elastic and flexible agile development as the way to innovate and reduce time to market for businesses. However, Physical and cloud Infrastructure does not enable application development platforms natively nor provide the ability to create applications that are cloud native with elastic services. In addition, businesses are moving to application development architectures leveraging cloud native technologies which are becoming more strategic to their business strategy. This presentation will look at the journey that developers take to transform to an application centric development model leveraging cloud native technologies.
This presentation will clearly define what a enterprises and services providers are deploying into production and how it enables elastic, flexible, and portable application workload deployment. The presentation will take a look at two production deployments and discuss the lessons learned and how to apply them to your cloud native journey.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
What
are
some
of
the
lessons
you've
learned
along
this
path,
and
it
really
is
a
journey
right,
there's
not
an
easy
way
to
just
kind
of
go
from
where
you're
at
to
to
the
next
generation
of
technology
ever
right.
And
so
how
do
we
sort
of
look
at
this
as
an
evolutionary
path?
Not
a
you
know,
greenfield,
stop
everything
you're
doing
and
stuff
from
a
different
model
path,
and
so,
as
a
few
key
concepts,
I
want
to
kind
of
talk
about
at
the
beginning
of
the
talk.
A
I'll
go
through
most
of
these
quickly
because
you
are
here
because
you
understand
them
and
you've
been
hearing
about
them
all
day
and
so
I
don't
want
to
spend
a
whole
lot
of
time
on
these
key
concepts,
but
it
just
want
to
make
sure
that
you
understand
them
in
terms
of
the
case
study
now
talk
about
this
open
source
container
project
in
Cisco's
been
working
on
cod
mantle.
We
built
a
nice
community
around
this.
A
I
do
like
to
kind
of
point
on
the
slide,
though,
that
while
you
don't
maybe
don't
care
as
much
about
your
your
your
cows.
Do
you
do
your
pets?
You
still
take
care
of
them
and
feed
them
and
put
them
in
rock
in
fences
right.
We
don't
let
them
just
kind
of
run
around
and
just
do
what
they
want
to
do
right,
and
so
the
fact
that
it's
a
cow
doesn't
mean
you
don't
care
about.
It
just
means
that
it's
there's
lots
of
cows.
There's
ways
to
replace
cows.
A
You
don't
have
to
like
depend
on
Macy
motel.
At
the
same
time
that
you
know
this
kind
of
concept
is
moving
forward.
You
have
this
whole,
this
term,
that
I
hate
from
Gardner
caught
by
more
OIT
right.
We
have
like
mode
1
and
mode
2
type
of
transformations
happening,
and
it's
really
more
about
moving
from
very
fixed,
very
static
sort
of
agile.
You
know:
I
mean
waterfall
type
of
business
processes
to
more
application,
driven
dynamic,
distributed.
Moving
more
to
you
know,
agile
type
of
developments
is
really
what
the
key
of
this
whole
mode.
A
A
Does
it
doesn't
matter
if
you
have
authorization
or
not,
I
containers,
a
completely
different
set
of
capabilities
that
allow
you
to
sort
of
segregate
your
different
Linux
kernel,
space
into
components
and
make
use
of
that
space
through
an
API,
and
so
that's
really
kind
of
a
key
concept
is
to
not
confuse.
Is
it
containers
or
hypervisors?
It's
it's
not
an
either/or
type
of
scenario:
right,
you
can,
you
don't
have
to
have
hypervisors
you've
never
had
to
have
hypervisors
right.
You
don't
have
to
have.
A
A
The
other
thing
is
that
we
were
making
this
big
shift
in
the
industry
today
from
a
very
well
defined,
well-known
set
of
architecture
patterns
where
you
have
like
a
DMZ
with
a
very
clear
set
of
demarcation
rules
and
access
lists
and
security
controls
around
it.
We
put
your
plan
presentation
logic.
Then
you
go
through
another
firewall
instead
of
intrusion,
detection
systems
and
get
into
the
next
level
of
tears
of
logical
components
which
then
have
another
set
of
common
firewall
controls.
A
A
The
rest
api,
so
do
you
know
direct
sort
of
service
calls,
and
so,
when
you
move
to
this
new
model,
the
complexity
of
all
that
all
that
infrastructure
gets
moved
into
the
network,
and
so
the
the
network
is
now
really
important
and
the
mass
in
as
a
cisco
company
right,
but
just
in
general.
Looking
at
this
in
the
industry
right,
the
network
becomes
very
important
because
it's
the
bottleneck
and
the
control
point
and
all
the
different
services
that
need
to
connect
and
communicate
with
each
other
all
going
through
the
network.
A
Now
in
versus
having
twos
and
layers
of
complexity
off
to
the
side
that
you
could
have
someone
else
manage
now
as
an
app
developer,
you
have
to
worry
about
how
your
network
gets
performing.
You
have
to
understand.
If
you
need
a
better
network,
you
have
to
understand
what
issues
are
happening
in
the
network,
whereas
before
you
had
a
whole
group
of
individuals
off
to
the
side,
you
could
call
up
and
say:
hey,
I
have
latency
or
having
I'm
having
issues
with.
You
know
my
performance
of
my
app
you
check
into
it.
A
A
You
heard
this
in
the
previous
panel
right
is
this
definition
of
cloud
native,
and
so
thanks
to
that,
some
of
the
work
that's
being
done
in
the
sea
and
CF
we've
defined
it
as
containers
or
containerisation,
distributed
orchestration
and
management,
and
then
microservices
architecture
and
what
do
I
mean
by
microsoft,
says
I
Texas
me,
that's
sort
of
the
if
I
were
to
say
what's
the
key
objective
of
understanding
cloud
native.
It's
really
around
this
term.
A
Microservices
architecture
and
I
kind
of
broke
it
down
into
these
four
areas
and
there's
not
meant
to
be
like
any
sort
of
like
relationship
direction
like
it's
not
like.
You
have
to
follow
the
graph
around
from
the
right
to
the
left,
it'll
left
to
the
right,
but
also
is
it
meant
to
represent
that
you
can
go
like
any
direction.
A
You
want
me
there's
just
sort
of
a
set
of
capabilities
that
make
up
an
architecture,
and
so
you
have
application
composition,
which
is
apply
at
the
highest
layer
in
terms
of
like
a
layered
idea
right-
and
this
is
where
you
come
up
with
the.
How
do
I
has
my
application
decomposed
into
a
set
of
microservices
right?
A
It
has
to
do
with
how
do
I
like
understand
the
different
aspects
of
my
application,
so
that
I'm
not
making
too
many
micro
services
and
making
it
too
complex
one
of
the
sort
of
requirements
I
have
in
the
and
the
API
layer
to
allow
these
micro
services
to
be
connected.
What
dependencies
or
loosely
coupled
dependencies
do
I
have
existing,
so
that's
sort
of
what
that
layer
takes
care
of
that
to
the
right
of
that.
You
have
this.
A
You
know
policy
and
event
framework,
and
this
is
where
some
of
the
I
think
requirements
of
of
an
enterprise
and
more
stability
around
deployment.
Architectures
and
software
come
into
play.
As
you
develop
your
application,
you
always
have
thought
in
the
past
about
policies
and
events,
and
how
do
you
get
data?
What
do
you
do
with
this
data
that
you're
collecting?
How
do
you
manage
this
data?
A
How
do
you
use
this
data
to
help
you
give
insights
into
what
you
should
be
doing
in
the
business
to
make
your
application
better
right
and
so
I
think
in
general?
That's
sort
of
to
me
part
of
the
cloud
native
definition,
because
that
doesn't
exist
in
a
lot
of
the
technologies
that
are
cloud
native
technology.
So
a
lot
of
this
is
being
developed
today
by
developers
because
it
doesn't
exist,
so
you
have
to
kind
of
create
all
this.
You
know
how
do
I
was
my
identity
management
capabilities
right.
A
How
do
I
plug
into
my
ldap
I?
Do
I
users
plug
into
and
authenticate
into
my
services,
and
so
thinking
out?
Some
of
those
policies
are
really
important
that
also
kind
of
bleeds
into
the
thing
across
from
it,
which
is
as
common
control
and
operations
capability
right.
So
how
do
I
manage
this?
In
my
existing
operations
consoles?
How
do
I
understand
failure
means
and
what?
A
What
failed
and
how
do
I
fix
that
failure,
and
also
how
do
I
sort
of
create
compliance
and
like
network
security
controls
and
things
like
that
that
are
needed
to
isolate
data
that
is
proprietary
or
has
information.
That's
critical
and
I
think
the
last
piece
is
it's
kind
of
an
important
part
of
why
I
did
separate
the
delivery
from
the
composition
is
that
the
application
composition
and
some
of
those
services
need
is
around
application?
A
Like
you
saw
in
an
earlier
talks,
you
know
supporting
these
different
components
of
the
infrastructure
that
are
out
there,
not
creating
yet
another
infrastructure.
You
don't
accidentally
have
to
do
that.
You
can
run
on
bare
metal,
so
that
gives
you
that
capability,
but
kind
of
separating
the
deployment
from
the
rest
of
the
composition
allows
you
to
have
that
freedom
to
write
your
code
and
optimize
your
code.
Here
we
godless
of
how
you
deploy
knit
and
if
the
business
decides
tomorrow
to
change
who
they
partner
with
and
who
they
buy.
A
Services
from
you
don't
have
to
refactor
your
code
because
you
wrote
it
to
only
work
on
this
one
cloud
provider
for
this
one
set
of
services,
so
those
are
like
the
key
concepts,
I'll
kind
of
go
through
this
quickly.
You
know
kind
of
tell
you
a
little
about
what
meant
always
on
why
we
did
mantle,
so
you
think
about
sort
of
the
the
last
decade
or
so
of
you
know,
kind
of
the
way:
data
center
networks
and
and
services
and
compute
and
storage
of
all
evolved.
A
You
kind
of
have
this
picture
on
the
left
this,
how
we
kind
of
look
at
the
wall.
Today's
you
have
your
your
basic
infrastructure
components.
You
have
your!
You
know,
hypervisor.
If
you
have
one
the
virtual
V,
apps
and
V
network
and
V
operating
system
on
top
of
that
needs
to
have
this
orchestration
management
piece
is
kind
of
a
static,
orchestration
management
piece.
You
have
your
configuration
management
component
that
are
kind
of
tied
back
to
you,
your
cmdb
type
of
model,
and
you
have
something
called
work
loads
which
are
kind
of
like
pattern.
A
So
now
you
have
cluster
managers
and,
and
the
workflow
component
is
not
more
managing
of
different
workflows
and
different
interfaces
that
you
have
to
manage,
what
flows
with
and
then
you
have
this
new
layer.
This
I
think
really
important
that
we
just
talked
about
with
microservices
that's
API,
and
this
application,
composition
and
delivery
components
are
sort
of
off
at
the
top
of
the
stack
and
how
you
define
that
application
irregardless
of
what
those
underlying
components
are.
A
You
don't
have
to
really
worry
about
what
sort
of
components
underneath
that
stack
as
long
as
you
know,
you
have
these
components
available
to
your
service.
You
can
then
call
out
to
a
service
and
that
service
will
be
available
for
you
to
call
out
to,
and
so
when
I
think
about
mantle
right,
I
kind
of
took,
took
that
picture
and
showed
it
exactly
what
we've
implemented
with
mantle
from
an
open-source
standpoint,
we
kind
of
started
with
the
sort
of
the
top
layer
with
the
proxy
and
low
balancing
so
making
sure
that
you
have.
A
A
At
that
point,
and
some
of
the
underlying
physical
components
and
provisioning
to
those
components
is
also
important.
At
this
later,
one
thing's,
we've
kind
of
discovered
with
mantle
was
that
if
your
application
orchestration
works
well
at
you
know
I
can
with
the
coup
benetti's,
you
should
probably
leverage
cooper
Nettie's
as
well
at
that
underlying
provisioning
later,
because
it's
going
to
work,
the
schedule
will
as
well
down
there
as
it
does
at
the
higher
levels
right,
and
so
that's
one
of
the
things
we've
learned
with
mantle.
Now.
A
If
you
want
to
learn
more
about
mantle,
feel
free
to
go
out
to
mantle
I,
oh
it's
an
open
source
project
and
pretty
good-sized
community
today
and
we'd
love
to
have
your
input
on
it
because
of
some
of
the
work
at
C&C.
F,
we've
added
things
like
coo,
benetti's
and
prometheus
to
the
project,
and
so
as
as
we
keep,
adding
more
and
more
projects
to
see
and
CF
will
keep
adding
those
projects
to
match
or
is
an
extensible
platform.
So
it's
not
meant
to
be
like
a
one.
Size
fits
all
type
of
solution.
A
If
you're
curious
about
what
it
really
is.
I
thought
I
put
a
slide
in
just
for
those
of
you
that
they
want
to
know
the
details,
and
so
these
are
the
tools
that
we
have
in
place
today
and
the
projects
that
were
supporting
these
are
all
open
source
projects,
and
so
it
kind
of
gives
you
a
good
idea
of
what
we
have.
And
yes,
we
support
both
KU
benetti's
and
Makos
because
of
different
use
cases
for
cumings
and
meso
sand,
and
when
I
get
to
my
my
customer
story,
you'll
see
why?
A
Because
they're
doing
data
analytics
and
they
needed
mezzos
for
the
data
pieces
that
were
working
on
in
terms
of
a
high
level
architecture
overview.
This
is
sort
of
how
it
connects
together
and
how
we
support
multiple
services
from
both
mezzo
sanku
benetti's.
So
we're
not
we're
not
trying
to
embed
one
in
the
other,
trying
to
hide
one
or
the
other.
We
basically
expose
both
of
them
and
you
can
leverage
either
or
both.
We
don't
leak
air
and
we
abstract
the
underlying
infrastructure
using
terraform.
A
A
Then
what
we,
on
top
of
that,
what
we
looked
at
was
you
know
it's
great
to
have
sort
of
the
technology
pieces
and
help
the
IT
admins
and
the
network
admins
understand
what's
happening
under
the
covers,
but
that
really
wasn't
enough.
In
my
view,
I
kind
of
felt,
like
the
developers
are
the
ones
that
have
a
lot
of
complexity
in
this
new
model
and
kind
of
starting
back
with
cloud
we've
made,
the
developers
lives
a
lot
located,
and
so
what
I
want
to
kind
of
do
is
look
at.
How
do
you
separate
that
developer?
A
It
also
works
with
open
shift
and
with
Cloud
Foundry.
So
it
doesn't
leave
Matt
doesn't
have
to
be
mantle
and
that's
kind
of
I
think
that
the
key
messages
it
kind
of
separates
unless
your
developers
develop
how
they
want
to
develop,
and
then
you
can
manage
and
support
how
they
deployed
under
the
covers
that's
sort
of
the
low
at
today
with
mantle.
It's
sort
of
this
big
picture.
They
don't
want
to
kind
of
show
with
the
vision
that
we
have
today.
A
I
just
will
change
over
time,
obviously,
but
it's
kind
of
a
busy
picture,
but
the
easiest
way
to
think
about
it
is,
on
the
left
hand,
side.
You
have
the
different
user
personas
that
we're
trying
to
address
again
kind
of
thinking
about
this
more
holistically
is
an
open
source
project.
There's
a
lot
of
different
users
and
different
use
cases
that
we
want
to
try
to
address
the
the
metal
part
that
talks
about
like
management
and
compliance
and
network
and
security.
A
Right
I
haven't
had
the
benefit
of
working
with
a
company
that
can
just
do
a
whole
green
filled
deployment.
They
always
have
existing
infrastructure
that
they
have
to
work
with
and
deploy
into,
and
so
it's
so
always
trying
to
like
help
them
figure
out
how
to
bridge
between
the
the
old
and
the
new,
that's
important
and
so,
and
that
center
layer,
where
you
see
those
policies,
that's
what
a
lot
of
the
networking
innovations
that
we're
doing
coming
out
right,
and
so
we
from
a
policy
standpoint.
A
We
have
something
called
Conte,
which
is
an
open
source
project
with
net
plug-in
and
storage
plug-in.
We
have
all
plug-in
and
allows
you
to
sort
of
take
the
existing
policies,
you've
defined
in
your
network,
a
physical
network
without
containers
and
map
those
policies
to
you
can
contain
a
network,
and
so
it
you
can
define
your
policy
once
and
then
that
policy
will
follow.
A
You
your
services,
whether
they're,
containerized
or
not
container
eyes
across
your
different
appointment
locations
and
then
what's
the
only
interesting
is
performance
is
important
to
a
lot
of
our
customers,
and
so
they
asked
us
how
you're
going
to
make
container
networking
higher
performing,
and
so
you
know
we
kind
of
looked
at
the
container
networking
space.
We
looked
at
the
Linux
caught
on
that.
A
What
was
being
done
in
the
linux
kernel,
networking
and
in
other
projects-
and
we
said,
look
to
do
a
lot
of
control,
plane,
stuff,
a
lot
of
underlying
overlay
and
bgp
routing
stuff,
but
they're
not
only
doing
anything
to
make
it
fast
and
to
use
a
plane
right,
and
so
we
worked.
We
took
our
vp
p
project
and
open
source.
That
is
something
called
Fido
FDI.
Oh,
we
have
a
demo
of
that
out
in
a
booth.
A
If
you
want
to
see
that
at
the
next
break,
love
to
kind
of
show
you
and
talk
about
where
we're
going
with
higher
performing
networking
in
the
container
space
and
again
vyto
along
with
you
know,
everything
we
try
to
do
is
cisco
to
be
more
part
of
a
community
works
with
Calico.
We
have
that
demo
and
in
the
booth
it
works
with
conte.
A
If
it
looks
with
it
will
work
with
with
we've
I
think
it's
something
we
have
on
a
road
map
to
do
so,
what
we're
not
trying
to
create
the
only
network
capabilities
right,
we're
trying
to
make
the
network
a
lot
better
and
and
for
me
network
admin
standpoint.
We
want
to
work
with
you
and
help
direct.
You,
like
you,
know,
actions
into
the
networking
space.
If
you're
an
admin
or
I
mean
a
few
developer.
A
We
know
you
don't
care
about
the
network,
and
so
we're
not
going
to
ask
you
to
do
anything
to
find
anything
on
the
network.
You
can
trust
Cisco
to
know
what
you
want
to
do
in
the
network
will
make
it
happen
right.
So
you
just
write
your
code,
publish
it.
What
make
the
network
perform
better
and
fast,
more
secure
for
you,
because
I
haven't
met
a
developer,
yet
that
says,
can
I
don't
want
you
to
make
my
network
faster?
I.
Don't
want
you
to
make
my
network
more
secure.
Let
my
application
get
hacked.
Please
right.
A
A
I'll
go
through
these
quickly
selling
it
to
the
use
case,
and
so
hybrid
cloud
deployments
is
one
of
the
key
things
that
we
want
to
solve
with
this
open
source
project,
because
there's
a
bunch
of
choices
out
there
and
a
lot
of
companies
already
using
Amazon
a
lot
of
because
I'm
using
google
a
lot
of
companies
are
deploying
their
own.
You
know
whether
they're
using
vmware
they're
using
OpenStack.
A
They
have
their
own
private
clouds
and
so
kind
of
supporting
this
hybrid
mode
and
allowing
traffic
to
not
have
to
like
flow
through
like
control
points,
and
so
this
isn't
like
a
you
notice.
These
lines
don't
go
from
from
amazon
back
to
the
your
data
center
it
into
google
right,
they
can
go
directly
from
amazon
to
google,
binding
or
directly
from
google
to
amazon.
We
don't
we're
not
trying
to
route
a
reflect
routing
to
make
it
happen.
A
We
also
have
something
we're
calling
network
auto
pilot
pilot,
which
is
sort
of
this
ability
to
create
these
micro
service
policies
that
tie
back
to
your
physical
network,
and
we
can
kind
of
monitor
those
policies,
and
we
report
back
to
you
in
terms
of
what
is
happening
within
the
underlying
network,
that
your
applications
are
running
on
and
we'll.
Let
you
create
actions
and
with
those
actors,
you
could
do
things
like
scale
up.
A
You
can
do
things
like
you
know,
isolate
this
VM,
because
it's
been,
you
know
hacked
you
can
do
you
know
different
actions
and
different
policies
based
on
what
you're
trying
to
accomplish,
with
with
your
network
intent
and
then
the
last
thing
is
this
idea
of
cross
orchestration,
balancing
right
and
so
we've
been
able
to
kind
of
look
at.
You
know
abstracting
the
orchestration
completely
from
the
application
developer,
so
you
can
just
write
your
application.
Saying:
hey
I
need
a
resource.
A
If
you
only
care
what
the
resources
we
can
give
you
options
of
either
one
and
then
move
you
know
different
slaves
around
as
needed.
So
that's
sort
of
the
three
main
use
cases.
We've
been
working
with
a
lot
of
our
customers,
including
WebEx,
and
so
what
webex
is
trying
to
do
is
just
like
a
lot
of
enterprise
applications.
They
wrote
their
application
to
be
very
monolithic
when
they
first
wrote.
A
Once
they
get
once
the
services
get
spun
up,
they
can
actually
remote
login
and
configure
them
and
manage
them
for
our
customers,
and
so
there
are
a
couple
of
drivers
for
what
they
wanted
to
do.
Something
more
cloud
native
the
first
one
and
I
hear
this
a
lot
for
millage
enterprises
that
they
that
managing
legacy
infrastructure
is
getting
very
complex
for
them,
and
even
things
like
virtualization
that
have,
you
know,
done
a
lot
of
good
things
in
the
last
several
years.
It's
still
too
complex
to
manage
virtualized
environments.
A
They
want
to
make
sure
that
as
they
deploy
these
services
to,
if
you've
ever
used
WebEx
and
it
didn't
work,
you
were
very
frustrated
right,
and
so
we
don't
want
to
have
that
experience
right.
If,
if
it's
not,
maybe
it
might
be
caused
by
something
other
than
Cisco,
which
is
a
different
issue.
But
if
it's,
if
it's
a
service
disruption,
because
we
we
had
a
service
process
fell,
we
had
something
go
down.
A
If
you
will
at
the
edge
they
required
our
bag
capabilities
and
more
security
capabilities
within
that
appointments
right.
So
this
just
see
groups
and
just
deploying
your
services
was
not
enough
and
they
want
to
have
some
kind
of
role
based
controls
and
then,
in
addition
to
that,
the
interview
to
provide
attendance
so
customers
with
monitoring
information,
metrics
about
how
things
are
performing
on
the
WebEx
servers
and
components
plus
they
had
to
get
locks
who
event.
So
they
would
know
if
something
was
felling
or
something
was
delayed
of
issues
were
happening.
A
So
they
have
this
whole
inventing
structure
that
they
wanted
to
container
eyes
and
make
sure
they're
loosely
coupled
components,
but
they
always
had
to
be
a
certain
number
of
them
available
to
collect
the
certain
amount
of
data
that
they
know
they're
going
to
get
per
second,
and
so
it's
a
lot
of
requirements
around.
How
do
we
contain
arises?
Components
was
still
ensure
that
we
have
a
number
of
them
available
to
support
this
level
of
connections.
A
They
also
had
some
requirements
on,
like
you
know
I
p-put
container
and
doing
things
around
like
service
global
in
a
global
manner.
How
do
you
manage
service
deployments
and
synchronize
the
data
between
these
different
deployments,
and
so
a
lot
of
our
customers
are
global,
and
so
they
might
have
a
in
New
York
in
an
office
and
seeing
a
point
of
trying
to
have
a
webex
and
the
connection
state
of
the
the
voice
in
the
video
and
some
of
the
chatting
that's
happening
on
that.
A
So
the
architecture
that
we
we've
deployed
with
them
and
testing
phase
right
now
with
with
our
webex
team,
is
we've
sort
of
created
as
global
console
interface,
allows
service
discovery
across
multiple
geo
locations
and
a
way
to
kind
of
define
what
the
Geo
requirements
are
for
those
locations
and
we
put
like
a
sink
agent
inside
each
deployment
of
what
we
call
mantle
or
this
underlying
consider.
Services
they're
only
interested
in
mezzo.
So
we
didn't
deploy
KU
benetti's
in
this,
but
we
let
them
know
that
as
we
as
they
evolve.
A
A
So
it's
pretty
simple
and
this
kind
of
gave
them
in
the
early
testing
we're
doing
they're
getting
great
performance
to
seeing
the
benefits
of
having
kind
of
this
isolated,
microservices
architecture
and
they're,
seeing
some
of
the
dependencies
and
failures
that
happen
just
in
general,
when
you
have
a
global
deployment
of
a
network
to
see
and
some
of
those
issues,
cannon
resolved
automatically
which
is
really
exciting
to
them,
and
so
with
that
I
know,
I
come
up,
but
near
the
top
of
the
hour.
I
want
to
at
least
leave
a
few
minutes
for
questions.
A
Mr.
Owens,
what
what
what
would
Joel
you
know,
what
drove
the
specific
requirement
around
IP
per
container
for
webex.
So
that's
actually
a
good
question.
I'm
glad
you
brought
that
up
because
it
started
out
as
an
IP
put
container
and
what
what
they
wanted
to
do
with
that
was.
They
felt
like
they
needed
in
this
world
of
at
the
way
the
software
is
written
in
the
way
they
like
to
connect
and
communicate
between
these
different
services.
A
Not
they
don't
depend
on
each
other,
but
there's
enough
of
a
dependency
there,
that
you
can
kind
of
put
them
goop
them
together
and
save,
and
a
lot
of
the
the
routing
overhead
needed
to
support
it
by
giving
them
a
common
VIP
that
they
all
sit
behind
and
the
services
communicate
directly
to
each
other
anyway.
So
it's
not
like
you
have
to
go
across
some
routing
in
a
face
to
get
to
the
next
hop
right,
so
there's
putting
them
together,
just
made
a
lot
of
sense,
and
then
we
needa
ployed
them.
A
It
also
gave
them
a
smaller
failure
domain
which
they
would
they
were
thinking
about
in
general,
but
they'd
only
understand
fugger
domains
like
we
do
in
networking
right.
So
it
kind
of
had
no
idea
that
these
things
could
cause
all
kinds
of
weird
behaviors.
If
you
had
a
failure
of
this
component,
those
located
in
a
different
data
center
than
the
main
two
component
that
was
relying
on
it
because
the
timeouts
don't
come
back
very
quickly
right.
A
The
network
is
good
enough
that
it's
always
trying
and
retrying
and
retrying,
and
it
takes
like
three
or
four
tries
before
it.
Basically
says
I
give
up,
and
that
was
just
taking
way
too
much
time
and
causing
lots
of
weird
behavior
at
the
application
too,
because
it
was
expecting.
This
is
just
work
and
it
wasn't
expecting
that
failure
to
come
back
and
it
know
how
to
detect
that
failure,
and
so
we
we've
done
a
lot
around
this
IP
per
container
and
just
in
general.
A
How
do
you
kind
of
manage
IP
rowdy
within
this
cloud
native
space
with
WebEx,
and
it's
it's
a
learning
process
but
I
think
they're,
starting
to
kind
of
get
this
idea
of
I
don't
have
to
actually
have
an
IP
and
a
name
on
every
single
container
that
I
spent
up
good
question
thanks.
I
would
thank
you
all
very
much
for
your
time.