►
From YouTube: Bringing Cloud-Native Applications to the Edge of the Network - Megan O'Keefe & Steve Louie
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Are You Ready to Be Edgy? — Bringing Cloud-Native Applications to the Edge of the Network - Megan O'Keefe & Steve Louie, Cisco (Advanced Skill Level)
More devices means more data, more applications, and more pressure on the cloud to transport, process, and store massive amounts of data. Edge computing aims to mitigate this network bottleneck by offloading intensive compute and storage to many "microdatacenters" at the edge of the network. In this talk, Megan and Steve explore the state of edge computing and its benefits to users in the areas of lower latency, data privacy, and safety. They outline exciting use cases for edge, including machine learning, virtual/mixed reality, video, transportation, and natural disaster detection. Then, they discuss what makes an application "edge-ready," from storage and network requirements to multitenancy and security. Finally, they demonstrate, using a prototype edge management platform built on top of Kubernetes, the process of deploying an edge application to multiple microdatacenters at once.
Note: This demo and our team’s prototypes in Edge Computing are not part of any official Cisco products.
About Megan
Megan is a software engineer at Cisco, where she works on a team dedicated to innovation in cloud, video, and data center technologies. Megan has spent the last year immersed in edge computing, where she has worked with service providers to help prototype a new platform for cloud-native edge applications. In her spare time, Megan likes to experiment with Kubernetes and Golang, and loves to talk about all things edge and IoT.
About Steve
Steve Louie is a Software Engineer at Cisco responsible for developing distributed systems, focusing on bringing cloud-native methodologies to Cisco. Steve is a Kubernetes contributor, and wants to build a more elegant cloud. Steve holds a Masters degree in Computer Science from Lehigh University and specialized in entrepreneurship as an undergrad. When he's not writing Go code, he can be found Swing Dancing in Boston's Lindy Hop community.
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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Is
are
you
ready
to
be
edgy,
bringing
your
applications
to
the
edge
of
the
network?
This
talk
is
going
to
be
all
about
edge
computing
and
approaching
edge
as
a
Multi
cluster
kubernetes
problem,
which
is
exciting
stuff.
Just
to
give
a
little
bit
of
background.
Both
of
us
are
engineers
at
Cisco.
We
work
near
Boston
on
a
rapid,
prototyping
team.
We
work
on
all
sorts
of
different
projects,
ranging
from
you
know,
data
centers,
stuff
cloud
stuff,
video
stuff
the
last
year
for
us
has
been
mostly
focused
on
edge
computing.
A
So
that's
what
we're
here
to
talk
all
about
so
in
this
talk,
we're
gonna
try
to
give
a
whirlwind
tour
of
edge
first
I'm,
going
to
cover
sort
of
what
is
edge
computing.
Why
does
it
exist,
talk
about
some
cool
use
cases
and
then
talk
about
what
makes
an
app
ready
to
be
deployed
at
the
edge
some
architecture
considerations
and
then
Steve
is
gonna
dive
into
some
platform
architecture
for
edge
and
give
give
a
demo
of
multi
cluster
edge
kubernetes.
A
You
know
some
some
of
these
emerging
use
cases
think
about
things
like
connected
cars,
virtual
reality
and
smart
home
devices
just
a
whole
bunch
of
use
cases
that
are
requiring
ultra-low
latency
and
we're
not
talking
just
like
regular
low
latency
we're
talking
like
single
millisecond
kind
of
latency
right,
where
in
some
cases
talking
from
device
to
is
actually
not
sufficient
anymore.
It's
just
it's.
It's
not
possible
to
get
that
kind
of
latency,
and
so
what
we've
basically
spent
the
last
year
thinking
about
is
how
could
we
address
this
from
a
compute
perspective?
A
You
know
we
think
of
the
cloud.
Is
this
sort
of
ubiquitous
thing,
but
in
some
cases
we
have
to
start
thinking
about
actually
moving
physically
moving
the
cloud.
You
know
you
have
the
device
and
you
have
the
cloud
and
you
have
to
move
one
of
them
right,
and
so
how
could
we
move
the
cloud
closer
to
the
device
so
at
a
high
level?
That's
that's
why
educating
exists.
This
is
a
really
hard
problem.
You
know
there's
a
whole
bunch
of
people
trying
to
think
about
it
and
address
it,
and
so
you
know
one
way.
A
One
way
to
address
this
is
with
edge
computing,
and
so
this
is
a
very
generic
definition
for
what
edge
is
sort
of
by
design
edge.
Computing
is
a
very
vast
space
and
you
hear
a
lot
of
kind
of
competing
terms
and
definitions.
We're
happy
to
kind
of
field
any
questions
about
about
that,
because
we
know
it's
right
now
kind
of
like
a
confusing
and
very
new
space,
but
really
what
edge
computing
is.
Is
it's
it's
exactly
this?
A
It's
the
process
of
moving
applications
from
the
centralized
cloud
out
towards
the
edge
of
the
network,
and
so
just
to
kind
of
clear.
The
air
right
edge
is
not
a
replacement
for
the
cloud,
and
so
you
hear
sometimes
the
wing
of
the
phrase
cloudlet.
You
know
these
all
these
little
clouds,
these,
like
tiny
little
data
centers
all
over
the
place
right
serving
requests
edge,
is
not
necessarily
a
replacement
for
the
cloud
we
see
edge
as
the
evolution
of
cloud
thinking.
A
You
know
five
years
from
now,
ten
years
from
now,
we
think
of
kind
of
this
utopian
vision,
right
where
the
cloud
is
the
edge
right.
The
cloud
just
has
a
much
deeper
footprint
down
into
the
edge
of
the
network,
and
so
you
know,
given
that
any
edge
has
a
lot
of
different
shapes.
We
kind
of
have
a
couple
diagrams
here
on
the
left.
You
know
some
of
your
phones
may
already
be
serving
edge
workloads.
A
Some
phones
now
have
dedicated
chips
that
do
specific
things
like
different
machine
learning
tasks,
that's
edge
right,
that's
moving
a
workload
out
of
the
cloud,
but
for
us
mostly,
what
we
deal
with
is
thinking
about
edge
compute,
not
as
cloud
not
as
end
device
but
somewhere
in
the
middle
thinking
about
something
like
an
becquer
data
center
that
can
that
can
serve
applications
and
talk
to
the
cloud
and
also
talk
to
the
device.
So
on
the
right
here,
we
show
an
example
of
a
car
picture,
a
vehicle
moving
down
the
highway.
A
It
needs
to
access
some
sort
of
back-end
application
and,
ideally
that
car
is
always
accessing
the
closest
instance
of
that
application,
which
could
dynamically
change
right,
really
really
really
fast.
As
that
car
moves
down
the
highway
and
so
to
kind
of
dive
into
a
couple
of
use
cases
before
we
get
into
the
juicy
kubernetes
stuff
generally,
when
we
think
about
edge
use
cases
and
applications
that
are
actually
fit
for
the
edge
that
really
belong
at
the
edge.
A
We
we
think
about
these
three
categories,
usually
applications
with
very
low
latency,
so
VRA
are
lots
of
IOT
use
cases.
Some.
You
know
again
to
go
back
to
kind
of
like
an
autonomous
car
situation.
Think
about
all
the
decisions
that
car
has
to
make.
You
know
do
I,
stop
do
I
turn.
That
is,
you
need
ultra-low
latency
for
that
high
bandwidth.
So
you
know,
video
processing
is
one
example
devices
that
generate
a
lot
of
data
and
also
kind
of
an
interesting
sort
of
thing
to
think
about
with
edge.
A
Is
this
whole
idea
of
ephemeral
or
temporary
data?
When
you
start
thinking
about
you
know,
applications
that
span
both
cloud
and
edge
enterprises
could
run
an
application
on
both
in
both
cloud
and
at
the
edge
and
start
being
able
to
promise
their
users.
You
know
we're
not
going
to
ship
your
data
up
into
the
cloud
we're
going
to
process
it
ephemerally
in
one
of
these
edge
maker
data
centers,
and
it
will
never
end
up
in
the
cloud.
A
So
that's
been
on
our
minds,
you
know
lately,
you
know
thinking
about
now
secure
data,
those
sorts
of
things.
So
this
is
a
this
is
a
very
big
slide
with
a
lot
of
different
use
cases
and
we're
not
gonna
touch
on
all
of
them.
We
would
love
to
and
to
field
any
questions
that
you
have,
but
the
whole
idea
here
is
that
across
IOT
across
enterprise
use
cases
across
service
provider
use
cases
edge
is
relevant.
A
There
is
just
a
vast
array
of
use
cases
and
we,
we
think
of
new
ones
and
find
new
ones
floating
around
every
single
day.
Honestly,
and
so
it's
a
really
exciting
time
in
this
space,
and
so
I'm
just
gonna
touch
on
two
of
these
use
cases
just
to
kind
of
get
a
lay
of
the
land
before
we
dive
into
examples
of
like
actually
deploying
these
kinds
of
applications.
A
The
first
is
machine
learning,
so
this
is
like
the
machine
learning
room.
There
have
been
like
some
amazing
talks
this
week
about
all
sorts
of
different
ways
of
using
you
know,
kubernetes
for
a
machine
learning.
Coop
flow
is
one
example
right
coop
flow
is
comprised
of
you
know
different
different
containers.
You
know
you
have
the
the
model
train
model
serve
so
edge
could
be
really
cool
because
say,
you're
an
enterprise,
and
you
have
a
machine
learning
application
right
now.
A
All
of
it
runs
in
the
cloud
which
means
that
serving
requests
like
serving
serving
your
model,
that
happens
in
the
cloud,
but
ideally
right.
You
want
really
low
latency
for
that
serving.
But
the
problem
is
that,
when
you're
training
your
model,
you
need
lots
of
compute
resources.
You
might
need
GPUs,
you
might
need
even
like
TP
use
generally
edge
breaker
data.
Centers
are
not
that
high-powered
right.
You
have
that
sort
of
advantage
of
proximity
to
the
end
user,
but
you
might
not
have
the
advantage
of
like
a
ton
of
resources.
A
We
include
another
use
case
here
with
healthcare
as
one
example:
I,
guess,
of
sort
of
an
IOT
example
where
I
think
that
sometimes
you
know
we
work
with
service
providers
and
less
with
enterprises,
but
I
think
it's
really
important
to
state
that
with
edge
it's
not
just
okay,
let's
put
compute
at
a
cellular
base
station.
It's
not
just,
let's
put
compute
in
a
in
a
central
office
for
an
SP,
whether
it's
like
a
higher
ed
institution,
a
hospital
edge
could
be
relevant
for
them.
You
know
you
could
you
could
put
compute
in
a
hospital.
A
So
in
this
example
we,
you
know
you
put
something
like
a
kubernetes
cluster
on
a
hospital's
private
network
and
you
can
serve
workloads
from
their
micro
data
center
talks
to
the
cloud
and
just
thinking
about
things
you
know
like
managing
highly
sensitive
data.
You
know,
medical
data
is
very
highly
regulated
and
so
just
think
thinking
about
how
they
could
store
that
in
a
house.
A
Those
sorts
of
things
again
just
just
one
example,
and
so
I
guess
I'm
trying
to
reinforce
here-
is
that
there
are
so
many
different
ad
use
cases,
but
I
guess
before
it's
Steve
dives
into
some
of
the
kubernetes
stuff,
just
think
think
about
what
are
maybe
some
unifying
themes
across
different
edge
use
cases.
You
know,
as
this
field
develops,
what
does
an
edge
application
look
like
you
know.
We
have
some
experience,
no
deploying
different
sorts
of
workloads
on
different
edge
platforms.
What
are
some
best
practices?
I?
A
Suppose
so
the
first
would
be
architecture,
I
guess
before
I
get
into
these.
You
know
a
lot
of
these
principles.
Are
it's
really
just
you
know
a
cloud
native
application
to
the
extreme,
so,
for
instance,
if
we
go
back
to
this
machine
learning
example
right,
you
are
deconstructing
your
kubernetes
deployment
to
run
literally
in
different
different
clusters.
Going
back
to
you
know
this
whole
idea
of
hybrid
cloud,
edges,
edges,
hybrid
cloud
right.
A
A
You
need
scalability
right,
your
your
compute
and
your
storage
has
to
all
scale
together
edge
maker,
datacenters
sort
of
posed
an
interesting
issue.
Where
sometimes
you
know
there
may
not
you,
you
might
not
be
able
to
always
guarantee
a
cloud
uplink
so
think
about.
You
know:
failure,
resiliency
and
those
sorts
of
things
storage.
So
the
whole
point
of
edge
right
is
that
you're,
reducing
backhaul
you're,
reducing
the
amount
of
stuff
you're
transporting
up
into
the
cloud
so
being
able
to
cache
state
I'm.
A
Only
syncing
with
the
cloud
when
you
have
to
Steve
is
going
to
dive
into
sort
of
an
example
of
how
we're
doing
DNS
at
the
edge.
You
know
it
so
that
you're
really
getting
the
traffic
to
route
to
the
closest
cluster
and
so
I
think
yeah
think
about
you,
know:
community
service
names
and
you
know
enabling
sort
of
ingress
those
sorts
of
things
across
clusters,
security,
so
with
edge
just
to
kind
of
speak
broadly
right
when
you,
if
you
have
thousands
and
thousands
of
edge
sites-
and
they
all
you
know,
get
a
vulnerable
application.
A
That's
like
thousands
of
points
of
entry
into
your
application
and
just
thinking
about
sort
of
the
geographic
disciplic
disparity
of
different
clusters.
It's
a
security
issue
and
any
time
you
read
an
article
about
edge
security
will
come
up.
You
know
we
are
not
security
people,
but
you
know
we.
We
absolutely
acknowledge
that
this
is
absolutely
a
concern
and
so
yeah.
So
with
that
that
was
I.
B
Megan,
hey
everyone,
so
Raymond
really
brought
up
kubernetes
and
in
great
detail
yet-
and
you
know,
there's
there's
a
table
here,
there's
probably
more
reasons.
This
is
just
at
least
what
I
feel
is
the
most
relevant
ones,
as
Megan's
already
described,
there's
a
wide
variety
of
use.
Cases
edge
comes
in
many
different
shapes
and
sizes.
B
We
think
kubernetes
is
a
really
good
fit,
and
so
here's
a
really
high-level
view
of
how
we're
thinking
about
an
edge
platform
with
kubernetes
we're
open
to
discussion.
Please
you
know
we
know
everyone
has
great
ideas.
I'll
say
this
is
an
OK
enough
idea,
at
least
for
now
we're
still
working
through
it
right.
But
so
let
me
explain
what's
going
on
here,
so
we
have
the
top
level
we
have
that
edge
manager.
So
that's
in
your
public
cloud.
That's
something
that's
highly
available.
B
You
know,
temperature-controlled,
that's
the
brains
of
the
operation
right,
so
that's
running,
you
know
keeping
track
of
all
the
other
edge
clusters,
so
I'll
just
go
down
to
the
next
tier
those
edge
clusters
in
blue,
and
so
that
could
be
it
could
be
a
restaurant.
It
could
be
something
running
on
like
a
light
pole
or
cell
station,
and
what
we
want
to
do
is
make
those
independent
kubernetes
clusters
and
the
reason
we
feel
that's
really
important
is
for
something
they
can
actually
brought
up
already
is
if
you
have
a
network
partition.
B
So
if
I
can't
get
back
to
my
edge
manager,
though
you
know
the
brain
of
the
operation
at
least
myself
I'm
reasonably
independent
I
could
scale
up
and
I
could
scale
down.
You
know
I
could
I
could
make
some
decisions
on
my
own
without
going
back
home,
and
so
we
feel
that
something
that's
real
important
with
the
amount
of
edge
sites
we're
gonna
have,
which
is
on
the
magnitude
of
thousands,
hundreds
of
thousands
lots
of
them
that
independence
and
that
autonomy
is
really
important
at
the
edge
and
then,
lastly,
going
to
the
bottom
layer.
B
Here
we
have
different
devices
and
the
really
important
part
here
is
just
getting
to
the
closest
edge.
We're
gonna
do
all
this
work
and
we
have
to
guarantee
that
you
as
your
device
as
you're
in
your
car
and
a
train
just
walking
along,
will
have
the
best
experience
because
we're
always
getting
you
to
the
closest
site
and
so
we're
gonna
dive
into
the
edge
manager.
So
what
what's
up
there?
And
how
do
we
see
it?
We
have
three
components,
and
this
is
really
motivated
by
our
vision
of
how
we
want
this
to
go.
B
So
we
want
it
to
be
this
simple.
You
know
we're
not
we're
not
there
today,
but
we
want
to
take
an
edge
box.
You
go
to
your
restaurant
or
wherever.
Maybe
you
plug
it
in
and
then
from
there
on
out,
like
it's
just
automated,
which
means
we
put
an
operating
system
on
it
that
we
could
lifecycle,
we
could
update.
We
could
manage
that.
The
next
part
is
getting
kubernetes
on
there
and
also
those
core
services
right.
So
this
is
the
second
tier.
The
platform
management
piece
is:
how
do
we
install
kubernetes?
B
How
do
we
lifecycle
it
and
then
even
those
things
that
you
just
want
as
part
of
your
platform,
it
could
be
Prometheus.
You
know
monitoring,
logging
and
those
basic
services,
you're
gonna
want
in
your
cluster,
and
then
we
have
the
highest
level
part,
which
is
actually
what
we're
gonna
demo.
Today
this
is
the
app
manager,
and
so
how
do
you
get
your
apps?
B
The
high-level
view
of
what
they're
doing
is
edge
sites,
basically
just
report
what
they
see.
What
do
I
see
in
my
cluster?
What
services
are
running,
I
push
those
up
to
the
central
DNS
and
I.
Also
ask
hey
what
else
do
you
see
and
it
pushes
down
the
information
about
my
neighbors
right?
So
there's
two
use
cases
that
I'm
outlining
here.
So
we
have
that
device
on
the
left.
So
this
is
the
most
simple
use
case.
It's
just
like
a
standard
one
cluster.
B
B
I
know
that's
running
in
my
cluster
here,
like
here's,
where
it's
running
and
I
just
get
redirected
to
the
edge
app
instance,
that's
running
in
the
cluster
that
idea
nest
with,
and
then
we
have
a
device
on
the
right-
and
this
is
the
more
interesting
use
case
that
takes
a
little
more
work,
and
this
is
where
I
DNS,
with
my
closest
edge
site
and
I,
say
I
want
to
talk
to
edge
app.
That
cluster
is
not
running
my
app
right
now,
but
my
neighbor
is-
and
maybe
it's
you
know
down
the
road
or
wherever.
B
Maybe
so,
it
has
to
redirect
me
to
a
neighbor
which
is
its
own
standalone,
kubernetes
cluster
and
we'll
have
to
pick
the
one.
That's
like
the
next
closest,
and
so
that's
that's
actually
we're
gonna
demo.
These
two
exact
use
cases
in
just
a
few
moments,
and
so
you
could
see
the
two
steps
on
the
Left
here.
I
actually
didn't
bring
those
up,
so
we're
gonna
do
in
anycast
DNS,
which
would
get
us
to
the
closest
cluster.
B
You
know
relatively
closest
cluster,
or
at
least
by
network
hop
distance,
and
then
the
DNS
will
be
able
to
resolve
which
edge
app
instance
or
whatever
you're
asking
for,
is
closest
right.
Now
we're
going
to
be
doing
like
a
geographic
distance.
We
understand
that's
a
little
broken,
but
it
was
just
the
fastest
that
we
could
code
up
in
in
the
time
we
had
so
we're
gonna
dive
into
opticon.
B
This
is
what
that
edge
management
piece
is,
and
this
is
I
guess
the
novel
thing
that
we
built
for
this
presentation
and
so
you'll
see
there's
not
a
ton
of
boxes
here,
and
we
really
want
to
leverage
what's
out
in
the
community,
so
we've,
basically
wrapped
the
cig,
multi
cluster
cluster
registry
I
know,
there's
been
a
ton
of
talks
for
the
cig,
multi
cluster
and
a
lot
of
other
people
have
leveraged
cluster
registry.
So
basically,
if
you
haven't
seen
it
yet
it
helps
you
keep
track
of
individual
kubernetes
clusters.
B
You
could
aggghhhhh
them
put
metadata
on
them
and
health
and
some
other
things
right.
So
it's
how
we're
keeping
track
of
our
clusters
and
then
we're
also.
We
wrote
basically
like
a
helm
client
that
can
talk
to
a
variety
of
helm.
Tillers
I
also
mentioned
the
cord
DNS
plugin,
so
I've
already
explained
that
box,
and
so
we
have
a
UI
and
we
kind
of
wrapped
the
cluster
registry
in
helm,
with
our
own
API,
just
for
some
standardization
and
then
down
at
the
edge
cluster.
B
We
want
to
keep
this
really
lightweight
just
because
those
boxes
aren't
that
hefty.
So
it's
basically
the
kubernetes
core
services
home
tiller
in
that
core
dns
instance,
that's
running
with
our
plugin,
and
so
this
is
going
to
be
what
we're
gonna
have
for
the
demo.
Actually,
it's
all
running
in
VMs
on
my
laptop
right
now,
because
we
didn't
trust
the
internet
here,
so
we've,
basically
offlined
everything
and
we'll
have
one
VM
acting
as
our
central.
You
know
public
cloud
highly
available
cluster,
it's
running
cluster
registry,
it's
running
optic
on
we're
gonna
have
three
edge
sites.
B
It's
gonna
DNS
with
Copenhagen
one
and
we're
gonna
actually
get
a
response
from
that
instance
of
the
web
app
and
then
I'm
gonna
have
another
client,
that's
gonna
DNS
with
Copenhagen
three.
It
is
not
running
that
web
service
nginx
and
it's
gonna
actually
redirect
me
to
copenhagen
two,
which
would
be
the
next
nearest
site.
B
All
right,
I
believe
this
is
big
enough.
Well,
we'll
come
back
to
this
in
a
second
all
right
see
some
thumbs
up.
So
that's
a
good
sign.
So
this
is
the
UI
kind
of
weave
we've
put
together
here.
So
we
could
see
that
we
have
three
clusters:
we've
given
them.
Just
you
know,
string
string
pair
labels,
as
you
would
for
nodes
just
gives
us
a
way
to
group
them,
and
we
just
put
them
in
this
little
map
here.
So
we
have
Copenhagen
to
Copenhagen
three
and
Copenhagen
one.
B
It's
either
healthy
they're,
each
running,
eight
pods
and
so
we're
using
helm.
So,
basically
just
tore
up
or
packaged
up
a
home
chart
and
we'll
attach
it
here.
I'm
gonna
call
this
prom,
you
could
pick
a
namespace
will
put
default
and
then
this
part,
so
our
label,
selectors
I'm,
actually
gonna
do
region
Europe
just
so
that
gets
to
everybody.
I
could
also
leave
this
blank.
It
would
do
the
same
effect
since
region.
B
Europe
applies
to
all
three
clusters
in
this
example,
and
then
you
just
hit
install
so
we'll
see
those
pods
are
coming
up
and
just
to
show
that
this
isn't
some
JavaScript
tricks
here
are
the
clusters,
so,
on
the
Left
we
have
Copenhagen
one.
This
is
Copenhagen,
and
this
is
Copenhagen
three
and
so
you'll
see
that
you
know.
Prometheus
is
running
on
all
the
clusters
here
and
so
that's
that's
a
create
operation.
So
let's
do
an
update.
Actually,
so
we
want
to
do
a
canary
test
or
you
know
a
new
version
of
Prometheus
comes
out.
B
This
is
just
basically
a
label
change
in
the
chart,
but
I
don't
want
to
a
deploy
to
everyone.
So
I'm
gonna
say:
let's
put
this
to
ID
one.
Two,
three
and
I'm
gonna
hit
update
and
we'll
see
that
this
became
version
two
and
so
not
there's
not
really
good
evidence
here,
just
because
of
the
clusters
here.
Let
me
clear
this
I'll
do
a
helm
list
so
we'll
see
now
we're
at
actually
revision,
two
we're
at
6.2
dot
one.
So
that
would
be
like
a
confirmation
that
we
actually
did
our
update.
B
B
B
And
then,
lastly,
I'll
be
deploying
that
nginx
web
server
I'll
call
it
nginx
defaults,
fine
and
we'll
do
kook
on
true.
You
could
see
I've
been
practicing
this
demo,
so
safaris
already
and
doing
it
for
me
so
hit
install
again
just
confirm
right.
So
we
have
those
two
nginx
instances
running
engine
X
coupe
con
on
only
two
of
the
clusters,
so
cluster
three
actually
isn't
running
it.
B
So
here's
my
laptop
and
actually
what
my
laptop
is
we're
going.
We're
gonna
see
this
example
right
now,
so
I'm,
actually
gonna
DNS
with
Copenhagen
one
and
I,
should
get
a
response
from
Copenhagen
one
okay
wow.
This
is
very
good
web
development,
I'm,
pretty
sure
Megan
and
I
are
very,
or
at
least
I
am
because
I
did
this.
So
you
know
that
h1
tag
was
very
hard
and
so
I'll
go
to
my
other
client.
So
this
is
something
that's
more
interesting.
So
this
is.
Let
me
see.
B
This
is
gonna,
be
client
number
two
I'm
gonna,
actually
DNS
with
Copenhagen
3
and
I'm
gonna
get
directed
I
should
get
directed
to
Copenhagen
and
the
reason
is
on
the
map.
Copenhagen
2
is
closer
to
Copenhagen.
3,
so
you
know
in
this
situation
my
client,
you
know
I'm
walking
down
the
street
down
here
and
I-
want
to
talk
to
my
great
great
web
app
here
for
coop
con
and
it's
gonna
actually
redirect
me
to
Copenhagen.
B
A
Cool
good
stuff,
so
you
know
this:
this
prototype
edge,
app
manager
that
Steve
just
showcased.
This
was
really
just
the
last
couple
weeks
of
work
for
us,
so
there's
a
whole
bunch
of
stuff
that
we
want
to
do.
First
of
all,
you
can
access
our
demo
code,
github.com
/
Opticon,
the
repos.
Are
there
you
can,
you
know,
set
up
the
UI.
You
know
deploy
our
virtual
environment
that
Steve
just
showed
play
around
with
it.
A
You
know
we
would
love
input,
yeah,
there's
a
whole
bunch
of
stuff
that
we
we
want
to
do
thinking
about
all
those
scaling.
So
imagine
that
you
know
Copenhagen
one
and
two
are
both
serving
the
same
web
application,
but
for
some
reason
all
the
traffic
is
going
to
one
cluster.
How
could
the
other
cluster
know
about
the
traffic
of
the
other
cluster
and
they
could
they
can
intelligently
load-balanced?
So
we
would
love
to
get
our
hands
dirty
with
that
thinking
about
jobs
that
span
multiple
clusters.
A
So
with
this
to8
there's
some
like
really
cool
multi
cluster
stuff
coming
out.
So
how
could
be
maybe
integrate
with
that?
And
you
know,
work
with,
say,
multi
cluster,
to
help
sort
of
define
this
space
right.
Educating
is
just
one
of
many
multi
cluster
use
cases,
so
we
just
want
to
make
sure
that
what
we're
not
building
is
like
just
for
edge.
A
Ideally,
you
know
you
could
use
this
optic
on
thing
right
for
just
a
couple
of
clusters
and
you
know
I
think
in
a
talk
yesterday,
the
average
number
of
clusters
that
people
have
if
they're
doing
multi
cluster
is
like
five
to
ten
right.
It's
not
thousand,
so
we
understand
that
our
our
use
case
could
be
like
a
little
bit
extreme.
So
we
want
to
make
sure
that
we're
we're
building
tools
that
could
maybe
help
other
people
too.
A
So
with
that
a
lot
in
a
short
period
of
time
and
just
to
kind
of
wrap
things
up,
you
know
we
talked
about
you
know.
What's
what's
driving
edge
touch
on
a
couple
of
use
cases
we
think
machine
learning
is
one.
You
know
awesome
use
case.
We
are
not
machine
learning
people,
but
we
are
really
excited.
To
kind
of
you
know
explore
that
space
and
yeah,
just
to
kind
of
reinforce,
like
the
reason
we
were
able
to
build
this
so
fast
is
because
you
know
of
the
hard
work
that
you
know.
A
Multi
cluster
has
done
on
cluster
registry
because
of
no
the
hard
work
helm
has
done
to
make
home
work
really
great
and
obviously
kubernetes
so
going
back
to
Alexis's
keynote
on
wednesday.
Just
thinking
about
componentization
right
all
of
these
tools
that
sort
of
legos
that
you
can
combine
together
to
make
stuff
like
I'm
just
kind
of
reinforced
that
you
know
it
is
possible
and
we're
like
we're,
excited
to
see
where
we
can
go
with
this
next.
So
if
this
is
was
interesting
for
you
and
edge
know
is
you
know
you're
intrigued?
A
We
do
have
a
bot
that
our
call
our
colleague,
matt
Caulfield,
is
running
at
2:45
today,
and
we
will
be
there
too,
and
we
can
say
after
to
answer
any
questions
that
you
may
have
so
with
that
yeah
we've
got
a
little
bit
of
time
for
it
for
questions,
but
I
think
we
only
have
one
mic.
So
I'll
repeat
any
questions.
I
guess
through
this
mic,
anybody.
A
Yeah
I
mean
so.
The
question
is,
you
know,
with
the
disaggregation
of
the
platform
and
lots
of
different
edge
clusters,
how
do
we
figure
out?
Who
pays
and
maybe
think
about
some
ethical
considerations?
I
mean
that's
on
our
mind.
A
lot
I
mean
we.
You
know
we
work
on
sort
of
prototypes
in
service
provider,
where
we
think
about
a
pattern
where
maybe
cloud
providers
and
service
providers
might
work
together
so
right
so
that
you
know
different
cloud
providers
could
extend
their
footprint.
Then
it's
kind
of
this
weird
situation
where
you've
got
that.
A
You
know
it
does
sort
of
get
you
into
this
space.
Thinking
about
things
like
net
neutrality,
those
sorts
of
things
where
you
know
if,
if
cloud
and
service
providers
are
partnered
together
and
in
enterprise,
what
pays
extra
money
for
their
for
their
service
to
make
it
down
to
the
edge
it's
on
our
minds?
We
know
we
haven't
gone
super
far
down
that
road,
but
it's
it's
definitely
something
that
that
we're
thinking
about
and.
B
B
B
B
Guess
I'm,
not
certain,
like
I,
think
we're
still
working
through
it,
and
the
hope
is
that
we
would
put
a
kubernetes
cluster
at
at
least
some
strategically
placed
cell
stations
to
start
I.
Don't
know
if
all
is
reasonable
or
unreasonable,
but
I
think
you
know
you
got
to
start
somewhere
and
it's
at
least
that's
where
we're
thinking
and
and
some
things
that
were
thinking
about
and
I
guess.
The
use
case,
at
least
the
starting
you
know
base
case
would
just
be
for
a
serving
video
and
it
could
be.
B
We
have
a
really
Orban
example
of
you
have
a
very
densely
populated
city
and
we
could
cash.
You
know
video
there
again.
It
may
not
be
the
best
edge
use
case,
but
it's
a
starting
point.
At
least,
and
then
you
also
have
a
more
rural
example
of
a
you
know
somewhere
where
the
backhaul
is
just
really
expensive,
you
could
think
about
it
like
an
airplane,
so
what
we
could
end
up
doing
is
maybe
these
boxes
that
go
into
those
rural
areas
just
have
a
lot
more
storage
and
you
would
be
able
to
deliver.
B
You
know:
HD
high
quality
content,
as
opposed
to
you
know
what
you
could
just
do
best
with
the
limited
backhaul
you
had,
and
so
I
don't
know.
If
that
answers
your
question
I
think
there's
a
lot
of
you
know
still
a
lot
to
think
about,
but
at
least
that's
where
we're
thinking
about
and
where
we're
trying
to
push
to.
A
Yeah,
and
so
you
know,
there's
a
lot
of
different
options
right.
We
purposefully
kept
a
lot
of
these
slides
a
little
bit
vague
because
we
thought
about
lots
of
different
options
right,
so
this
compute
could
could
live.
You
know
anywhere.
Ultimately,
it's
like
we
thought
about
edge
compute
on
the
plane,
edgy
compute,
on
a
train,
actually
view
mounted
on
a
like
a
like
a
light
pole,
smart
cities
right.
A
So
thinking
about
you
know:
smart
parking,
smart
lighting,
smart
plumbing,
some
of
these,
like
you
know,
less
flashy,
smart
use
cases
compute
needs
to
be
somewhere,
it
could
be
anywhere.
Obviously
there
are
considerations
around
you
know
you
need
to
ruggedized
it.
It
has
to
be
a
lot
of
times.
This
compute
will
be
exposed
to
the
elements.
So
you
know
that
does
kind
of
constrain
where
you
can
put
it.
Obviously,
you
know
if
you
want
kind
of
a
you
know,
a
bulkier
compute.
You
know
there
are
size
consideration,
so
we
can't
just
live
anywhere.
D
B
B
If
we
had
some
some
open
source
thing
that
you
could
just
volunteer
your
computer,
you
we
basically
will
install
kubernetes
on
it
and
then
you're
just
you
know,
machine
hash
number
and
that's
your
identity,
and
we
could
like
put
workloads
to
you
so
I
think
that
has
a
whole
another
set
of
questions,
concerns
and
problems,
but
I
think
it
could
be
possible
like
I,
don't
I,
don't
doubt
that
I'm
not
gonna
like
exclude.
That
is
something
that's
unrealistic.
I
could
see
that
as
being
very
viable
I'm
gonna
go
over
here.
B
So
the
question
was
about
synchronizing
state
between
different
edge
sites,
and
so
something
that
was
in
one
of
these,
but
anyway,
it's
further
back.
So
the
way
that
we're
thinking
about
state
is
that
you
will
not
put
state
at
the
edge.
The
edge
will
only
be
used
as
a
cache
at
best,
so
it's
always
ephemeral.
So
if
you're
doing
something
that
is
stateful
you're
always
going
to
maybe
do
some
computation
and
push
your
result
up
to
the
cloud.
B
So
then
everyone
as
long
as
you're,
not
like
in
an
edge
site
that
has
a
network
partition
back
up
to
the
central
cloud.
You
should
still
be
able
to
pick
up
where
you
left
off,
or
at
least
not
lose.
You
know
the
cycles
that
you
spend
to
get
that
result.
So
that's
how
we
would
see
it
working.
It's
kind
of
I
guess
like
MapReduce
II,
where
you're
always
storing
stuff
centrally
you're,
never
going
to
be
storing
anything
at
the
edge.
Does
that
make
sense.
D
A
So
I
guess
the
question
was
you
know,
thinking
about
these
disaggregated
applications
that
run
in
both
the
cloud
and
at
the
edge?
How
would
the
scheduling
work
right
if
you
have
different
networking
between
cloud
and
edge
great
question,
so
yeah
we're
at
the
beginning
of
a
long
road
with
this
right?
We
the
way
that
we're
thinking
about
it
now
is
that
you
basically
think
of
your
cloud
to
edge
application
as
a
bunch
of
different
applications.
A
B
But
then
also
when
it
comes
down
to
you
know,
this
is
very
basic
scheduling,
but
you
would
have
no
delay
or
like
cluster
labels
on
things
that
you
would
be
running
in
the
cloud
so
I.
We
do
think
that
you
would
probably
end
up
writing.
You
know
your
cloud
version
of
this
app
and
then
you
would
probably
have
some
edge
version
that
has
some
caching
functionality
and
some
other
things
that
you
would
want,
and
it's
probably
lighter
weight,
and
you
know
all
the
things
that
we'd
mentioned.
Oh.
B
We
made
it
through
the
demo
and
now
walking
up
here
so
anyway,
it
was
just
the
cluster
label.
So
I
think
you
would.
You
would
use
your
cluster
white
cluster
labels
to
put
things
up
at
the
cloud
and
then
you
could
specify
some
of
the
other
ones
at
the
edge
and
I've
been
thinking
about
this
and
I
went
to
some
of
the
write,
your
own
kubernetes
pod
scheduler,
which
is
really
cool,
but
also
very
scary,
because
it
seems
like
you
could
really
mess
things
up
very
quickly.
B
So
so
maybe
there's
there's
optimization
there,
but
it's
definitely
not
like
a
one-man.
It's
definitely
a
big
effort
and
then
I
know
it's
lunchtime
so
I
think
we
could
let
people
go
to
lunch.
We'll
definitely
be
here
for
more
questions.
You
know
we
will
be
at
the
ball
flater
or
you
know
just
find
us
now.
Thank
you.