►
From YouTube: Why is Cloud-Native Application Development Still So Hard? - Irene Zhang & Venugopal Reddy
Description
Join us for Kubernetes Forums Seoul, Sydney, 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
Why is Cloud-Native Application Development Still So Hard? - Irene Zhang & Venugopal Reddy
Creating reliable, scalable, distributed cloud-native applications is still way too difficult for us mere mortal application developers. Why must we understand and solve complex distributed systems problems like data consistency, shard balancing, consensus algorithms, network partitions and exponential backoff just to build a straightforward business or social media app? Given that new real-world applications now also run across intermittently connected mobile devices, hybrid cloud servers, edge nodes, IoT devices etc, the problem is rapidly becoming even more difficult, to a point of being practically impossible. Surely we can do much better than this? Quinton and Irene will describe some of the recent advances in distributed systems R&D, and an open source distributed cloud operating system their groups have been collaborating on, that might just provide a way forward.
https://sched.co/Nrlc
A
A
She
is
a
researcher
at
Microsoft
and
holds
a
PhD
in
distributed
systems,
and
I
would
like
to
mention
about
my
colleague
Quinton
hole,
who
has
envisioned
that
this
project
and
thought
that
it
would
be
worth
outsourcing
it.
Unfortunately,
he
couldn't
make
it
to
this
event,
due
to
some
reasons.
Alright,
let's
get
started.
Our
team
and
Irene's
group
had
been
collaborating
for
the
past
few
years
and
a
pretty
exciting
project
to
take
the
research
and
she
did
in
distributed
systems
for
her
PhD
thesis
and
expanded
into
a
full-fledged
open-source
project
in
C&C
F.
A
In
today's
agenda
will
cover
the
brief
history
of
evolution
of
applications,
nature
of
applications,
development
from
monolithic
to
micro
services
and
the
skill
set
required
for
application
developers
system
developers
a
service,
a
DevOps
engineers
note
that
the
application
developer
I
meant
here
is
not
a
standard
industry
term.
I
will
talk
about
it
when
I
get
to
that
slide
and
then
we'll
briefly
touch
on
a
broader
effort
to
create
a
full
distributed
operating
system
amino
s
and
then
zoom
in
to
the
most
interesting
part
of
it.
I
mean
or
an
micro-service
runtime
system.
A
Once
upon
a
time,
applications
that
people
interacted
day-to-day
were
pretty
simple,
they
typically
support
single
user,
ran
on
a
single
operating
system
and
on
a
standalone
machine.
They
were
things
like
text,
editor
document,
viewers,
calendars
and
simple
games.
Life
was
good
for
application.
Programmers
single
machine
operating
systems
work
fairly
well,
Linux,
Windows,
Mac
OS.
All
of
them
provide
a
great
layer
of
abstraction
for
application
programming
with
the
basic
building
blocks
like
local
process,
virtual
memory,
file
system,
synchronization,
primitives
and
locks.
A
All
of
these
are
indispensable
when
writing
an
application
for
sing-sing
single
submission,
mostly
one
or
two
programming
languages,
are
required
to
build
an
application
and
the
application
programmers
understand
that
platform
pretty
well,
but
suddenly
everything
changed
cloud
computing
happened.
Everybody
moved
to
smartphone
mobile
for
strategies,
ubiquitous
network
connectivity,
high-speed
Internet
everywhere,
so
the
type
of
applications
changed.
Suddenly
we
have
social
media
applications
like
Twitter,
Pinterest
Facebook,
and
in
addition
to
that,
some
of
the
previously
existing
applications
with
single
user
also
became
collaborative
multi-user
applications.
A
Firstly,
users
share
these
applications,
so
the
application
has
to
run
on
the
number
of
servers
in
the
cloud
next
users
access
these
applications
through
mobile
devices
like
cell
phones
and
tablets,
so
it
means
that
applications
need
to
have
a
mobile
component
cloud
component,
sometimes
a
desktop
component
and
increasingly
sometimes
edge
components
too
in
case
of
smart
cities
and
autonomous
systems
autonomous
vehicles.
And
lastly,
these
application
need
to
coordinate
across
distributed
components
over
the
links
that
are
sometimes
flow
are
unreliable.
A
In
summary,
all
this
adds
up
to
some
significant
challenges
for
application
programming.
They
have
to
coordinate
data
and
computation
across
distributed
nodes.
They
have
to
meet
application
requirements
with
guaranteed
performance
and
limitations,
performance
limitations
and
failures,
and
they
have
to
do
all
this
across
different
programming,
environment
and
varying
hardware
resources,
which
means
application.
Development
is
really
very
hard
with
multi-user
multi
program,
multi-platform,
multi,
node,
etc.
This
is
one
of
the
reason
why
cloud
native
computing
foundation
exists
along,
came
essentially,
cnc
of
containers,
kubernetes,
micro
services,
etc.
A
Most
of
you
know
well
about
the
things
on
this
slide.
Things
have
certainly
got
better.
Applications
can
be
partitioned
into
deployable
containers,
programmatically,
orchestrated
and
declarative
configurations
with
kubernetes
different
language
can
be
used
in
every
single
container
and
we
can
connect
micro
services
with
service
measures
like
linker,
D,
sto,
etc.
A
service
can
run
these
things
in
developers
and
develop
them.
A
However,
the
problem
is,
somebody
still
got
to
write
the
code
that
runs
in
these
containers
and
it
turns
out
to
be.
It
is
very
difficult
to
do
it
reliably
in
a
way
that
use
the
application
properties
that
you
want.
Companies
like
Google
and
Amazon
have
been
doing
it
for
quite
long,
but
they
do
have
somewhere
around
100,000.
Pretty
good
software
engineers
spent
and
building
this
resilient
and
scalable
systems
problem
is
that
a
company
that
needs
to
build
some
end-user
application
doesn't
necessary.
A
A
How
do
you
handle
the
failures
disconnections,
reconnections
replication
leader
election
sharding
for
horizontal
scaling?
All
of
these
are
complex,
distributed
system
problems
that
we
are
forcing
application
developers
to
understand
them
and
handle
them.
Some
of
these
areas
are
partially
fulfilled
with
things
like
service
wishes,
but
there
isn't
a
single
platform
where
you
can
sit
down
at
and
write
a
distributed
application
and
know
that
you
have
got
all
the
primitives.
You
need
in
order
to
build
a
distributed
application.
A
Not
surprisingly,
these
are
distributed
system
problems.
These
are
the
things
we
study
in
computer
science
operating
system
classes.
We
learn
about
how
virtual
memory
manager
works,
understand
how
TCP
sliding-window
protocol
works,
but
we
don't
expect
application
developer
to
implement
TCP
sliding-window
protocol
in
their
applications
or
decided
which
memory
should
go
on
disk
and
which
memory
should
go
on
to
ram.
This
should
be
abstracted
away,
which
at
the
moment,
is
not
in
case
of
distributed
systems,
unlike
single
machine
operating
system,
unlike
single
machine
operating
system,
which
takes
care
of
them
all
these
things
under
the
hood.
A
The
terminology
I'm
using
here
application
developer
is
not
something
everybody
understands,
certainly
not
in
standard
term
in
the
industry.
Just
want
to
be
clear
on
what
I
am
talking
about
here
and
I.
Think
there
is
a
large
amount
of
very
necessary
specialization
developed
around
this
area.
These
are
application
developers.
These
are
the
kind
of
people
who
know
particular
application
domain,
very
well,
like
social
networking,
travel,
finance,
banking,
etc.
A
They
know
what
their
systems
need
to
do,
what
their
customers
want,
what
functionality
they
need.
They
don't
give
a
hoot
to
distributor
system
problems
in
the
middle.
We
have
sis
system
developers,
they
are
the
people
who
are
interested
in
understanding
and
solving
the
complex
distributed
system
problems.
They
are
extremely
short
in
supply.
Problematically.
They
don't
understand
your
business
needs
and,
on
the
right
hand,
side.
We
have
a
service
DevOps
engineers.
They
are
the
people
who
understand
how
your
actual
application
behaves
in
real
life.
What
happens
when
a
particular
customer
hits
your
application?
A
What
do
your
shouting
systems
look
like
what
breaks
and
why,
once
again,
they
are
not
necessarily
distributed
system
experts
and
not
necessarily
application
domain
expert,
but
they
do
understand
how
to
run
the
systems.
Well.
I
think
it
is
very
useful
to
understand
these
distinctions.
A
Suri's
are
good
at
running
reliable
systems.
Application
developers
are
good
at
application
domain,
so
what
we
think
is
ultimately
we
need
a
distributed
operating
system.
I
mean
always
I
mean.
Oh,
is
this
an
umbrella
project?
We
think
it
should
probably
compress
of
at
least
these
major
subsystems.
A
First,
twenty
Cimino
run
manages
distributed
micro
services.
It's
a
distributed
programming
system
that
provides
customizable
and
extensible
deployment
of
mobile
and
cloud
applications.
This
flexibility
enables
program
was
to
separate
deployment
logic
from
their
applications.
Second,
one
is
aminos
sync
reactive
data
management
service,
which
provides
the
persistent
cloud,
storage
and
reliable
synchronization
between
storage
in
mobile
devices,
and
also
provides
automated
execution
of
application
code
in
response
to
shared
data
updates.
Third,
one
is
Cimino
store,
distributed
transaction
protocol
like
that
droids
linearizable
transactions
using
inconsistent
replication,
unlike
two-phase,
commit
with
strong
replication.
A
A
A
This
picture
is
self-explanatory.
What
we
really
want
you
to
be
thinking
is
distributed.
Cloud
native
applications
doesn't
actually
have
to
worry
about
pieces
which
piece
of
code
runs
on
which
machine
operating
systems
has
to
take
care
of
them,
and
we
know
it
is
a
unified
system
that
provides
microservice,
runtime
memory,
management,
storage
and
security
components.
It
needs
to
run
across
all
the
operating
systems
in
the
network.
A
A
lot
of
research
had
been
going
on
for
several
years
in
the
university
of
washington,
but
only
the
time
Irene
had
published,
published
her
theses.
We
came
across
it
and
thought
that
it's
worth
turning
into
an
open
source
project
in
the
CNC
F,
so
that
people
can
use
it.
Research
wasn't
intended
for
that
purpose.
Originally,
it
was
really
experiment
related
figure
out
what
this
face
looks
like
and
what
we
needed
in
particular,
there
are
academic
papers
floating
around
in
Internet.
A
Some
of
the
terminology
in
the
papers
are
different
from
what
we
have
described
here
over
time.
We
discovered
that
certain
terms
we
use
were
confusing.
For
example,
we
renamed
amino
system
to
amino
run,
aminos
diamond
to
amino
sinc,
etc.
So
if
you
see
the
contradictory
terms
floating
around
the
internet,
hopefully
you'll
understand
the
origin
I'm
going
to
hand
over
to
Irene
from
here.
B
Seemed
like
Jhelum
on
you
ho,
okay
I
seen
the
neck
wandering
Roman,
no,
really
I'm!
Actually
gonna.
Do
this
talk
in
English,
because
my
Chinese
is
not
that
good.
So,
okay,
you've
gotten
a
great
introduction
to
the
overview
of
the
whole
amino
system.
I'm
going
to
focus
today
on
the
very
detailed
parts
of
the
amino
run,
sub
system
sort
of
what
the
magic
is
and
what
the
knobs
are
that
make
it
all
happen.
B
So
when
we
started
taking
a
look
at
this
problem
space
of
developing
a
distributed
operating
system
for
mobile
and
cloud
application
developers,
we
had
a
couple
of
goals
that
we
wanted
to
achieve
when
we
were
looking
at
building
this
runtime
system.
So
the
first
is
that
we
did
not
want
what
we
consider
deployment
logic
to
be
mixed
in
with
the
application
logic.
So
you
can
think
of
this
as
the
code
that
a
distributed
systems
programmer
would
have
to
implement
like
building
RPC,
compared
to
something
that
an
application
programmer
should
be
building
which
is
like.
B
B
So
the
best
way
to
understand
how
Amino
run
works
is
by
taking
a
look
at
its
architecture,
and
the
key
thing
here
to
notice
is
that
there
going
to
be
three
layers
to
this
architecture
at
the
top
will
be
the
distributed
application,
which
is
the
application
code.
That's
going
to
run
across
all
of
your
mobile
devices
and
IOT
devices
and
cloud
servers.
B
Then,
at
the
very
bottom
layer
we
have
a
deployment
kernel
which
implements
best-effort
basic
deployment,
tasks
like
just
making
a
call
to
a
different
part
of
the
application
or
being
able
to
find
other
components
in
the
application.
But
the
most
important
part
of
the
amino
run
architecture
is
the
deployment
manager
this
layer.
B
So,
to
give
you
an
example,
the
application
programmer
takes
their
application
and
splits
it
up
into
a
couple
of
large
micro
services.
What
we
do
underneath,
then,
is
that
we
have
the
deployment
kernel,
which
runs
these
Microsystems
services,
but
then
for
each
micro
service,
there's
going
to
be
a
deployment
manager
that
provides
the
exact
functionality
and
deployment
tasks
that
the
applicant
micro
service
needs.
B
So
then,
if
we
look
down
into
the
deployment
kernel,
the
deployment
kernel
is
a
piece
of
software
that
is
distributed,
but
it
runs
on
every
single
cloud,
server
and
mobile
device.
Its
entire
job
is
to
instantiate
and
manage
these
high-level
micro
services
that
comprise
the
Amino
run.
Applications
it
tracks
where
each
micro
service
is.
B
B
On
our
pcs,
essentially
and
then
routing
or
managing
those
calls,
so
as
an
example,
to
give
you
a
concrete
example,
one
deployment
manager
might
replicate
a
micro
surface
by
creating
multiple
instances
of
that
Microsoft
service
in
different
containers,
for
example,
then,
every
time
the
application
makes
a
call
to
that
micro
service,
the
deployment
the
deployment
manager
will
route
the
call
to
all
of
the
replicas.
So
the
nice
thing
about
deployment
managers
is
that
they
encapsulate
deployment
code
and
tasks
separate
from
the
application
code
itself.
So
programmers
can
decide
that
they
have
implemented
this.
B
B
So
I'll
give
some
examples
in
the
next
section
about
how
exactly
these
deployment
managers
work
but
understand
a
little
bit
better.
If
you
think
of
each
of
these
as
being
a
micro
service,
we
could
decide
that
perhaps
this
game
board
micro
service
needs
to
be
replicated.
So
we
would
attach
a
replication
deployment
manager
to
it,
which
would
ensure
that
the
game
board
micro
service
is
replicated
to
and
instantiated
in
different
containers
and
then
have
each
of
the
RPC
calls
to
the
micro
Service
replicated.
B
B
The
other
thing
that's
interesting
is
that
you
can
combine
them
in
interesting
ways
so
that
you
can
use
more
than
one
deployment
manager
at
a
time.
So
we
have
lots
of
different
categories
in
which
we
group
our
deployment
managers.
We
have
a
bunch
of
deployment
managers
that
just
implement
very
primitive
deployment
tasks
like
exactly
once
RPC.
We
also
have
caching
and
serial
light
serializability
checkpointing
replication
mobility,
scalability
and
more
so
there
are
a
very
large
set
of
these
library
deployment
managers
already
and
more
to
come.
B
B
So
when
I
talked
about
how
the
deployment
managers
interpose
on
our
PC,
the
way
that
we
actually
implement
deployment
managers
is
through
an
interface
provided
by
the
south
by
the
Amino
run
deployment
kernel.
So
what
happens
actually
is
that
each
deployment
manager
is
implemented
as
three
separate
components,
each
of
which
support
a
sequence
of
up
calls
that
the
deployment
kernel
automatically
invokes
when
our
pcs
come
in.
So
let
me
give
you
an
example.
So
we
have
a
server
side
component,
which
is
co-located
where,
with
where
the
micro
service
actually
runs.
B
So
when
an
RPC
comes
in,
an
up
call
will
be
made
to
the
server
side,
deployment
manager.
Similarly,
for
the
client
side
deployment
manager,
we
have
another
component
that
runs
where
the
client
makes
the
RPC.
So
then,
from
the
client
side,
whenever
the
client
makes
an
RPC
will
invoke
an
up
call
inside
this
component
of
the
deployment
manager,
then
we
have
a
centralized
component
for
every
deployment
manager
which
we
implement
on
something
that
is
essentially
a
an
at
CD
kind
of
service
to
provide
replication
and
fault
tolerance
for
these
components.
B
B
So
let's
take
a
look
at
what
happens
exactly
when
an
RPC
is
made
to
a
SATA
to
a
sapphire
or
Amino
run
micro
service.
So
when
you
start
the
micro
Service,
the
Sapphire
deployment
kernel
will
actually
instantiate
the
deployment
managers
automatically.
So
let's
say
we're
trying
to
replicate
this
micro
service.
So
what
will
happen?
Is
the
deployment
manager
will
receive
an
up
call
saying
that
the
micro
Service
has
been
created,
at
which
point
it
will
create
replicas
of
the
micro-service
on
to
other
kernel
servers?
B
B
So,
let's
look
at
exactly
what
happens
with
a
primary
backup
sort
of
leader
based
replication
protocol,
so
we
first
stand
up
three
copies
of
the
micro
service
for
a
consensus-based
kind
of
leader
based
replication
protocol.
We
designate
one
of
the
micro
service
instances
as
the
leader
and
then
when
any
other
micro
service
makes
over
RPC
to
this
micro
service.
B
B
So
essentially
what
would
happen
is
we
would
need
to
just
create
an
instance
of
the
micro
Service,
the
same
code
in
the
cloud
and
then
just
forward
calls
from
the
code
that
was
running
on
the
IOT
device
or
phone
to
the
cloud
instance
and
so
depending
on
which
of
the
to
run
faster.
Then
we
can
make
a
decision
about
where
to
actually
run
that
code.
We
can
sort
of
do
the
same
thing,
essentially
in
reverse
to
cache
data
from
a
micro
service
locally
on
the
mobile
device.
So
what
happens?
B
B
So
we
can
compose
deployment
managers
as
well.
It's
done
by
chaining
deployment
managers,
so
you
can
imagine
every
time
you
make
an
RPC.
The
call
goes
through
a
series
or
a
sequence
of
deployment
managers,
but
of
course
you
could
imagine
that
this
rapidly
gets
very
complicated.
So
we
don't
imagine,
people
would
be
chaining
a
lot
of
these
deployment
managers
together
all
right
so
five
years
ago,
when
I
did
this
research,
we
did
a
little
experiment
and
I'll
show
you
the
experimental
results,
although
the
demo
that
we're
going
to
show
later
is
probably
much
more
interesting.
B
B
It
should
change
this
game
essentially
from
something
that
is
a
cloud
server
based
game
to
appear
to
peer
application,
and
then
we
were
able
to
do
the
same
thing
where
we
just
replicated
the
micro
service
on
both
players
devices.
So
reading
the
state
of
the
board
game
became
very
fast,
but
then
every
time
the
player
made
a
move,
they
would
have
to
update
both
copies
of
the
board
game
on
both
devices
which
increased
the
write
Lansing.
So
I'm
gonna
skip
this
next
experiment
because
it
sort
of
shows
something
very
similar.
B
I
will
also
say
that
the
the
amino
Run
system
does
support
multiple
programming
languages
through
the
use
of
grail
vm,
and
so
this
was
one
of
our
goals
to
be
able
to
be
somewhat
programming
language
agnostic.
So
you
can
essentially
write
your
amino
run,
application
and
deployment
managers
in
any
of
these
languages.
A
About
the
next
steps,
it's
still
early,
we
have
lot
of
ways
in
which
we
would
like
to
extend
I
mean
no
run
in
the
future.
Today,
micro
service
migration
only
works
for
the
state
stored
into
the
but
inside
the
micro
services,
but
there
can
be
local
files,
a
dynamic
state
where
we
are
not
migrating.
As
of
now,
you
have
to
work
on
that
and
we
need
to
support
definitely
need
to
support
more
language.
We
support
very
few
now
with
the
support
of
Calvin.
A
We
are
going
to
extend
it
and
we
want
to
build
some
more
DMS
to
integrate
with
external
systems
like
load,
balancers,
sto,
etcd,
tik
v,
and
at
the
end
we
still
need
to
build
some
good
edge
applications
and
verify
that
everything
works
well,
at
least
on
the
qubit
rather
than
under
normal
cuban.
It
is.
A
A
C
B
So,
okay,
so
so
the
question
was
whether
the
evaluation,
the
experiment
that
I
showed
was
a
live
migration
or
not.
So
the
particular
example
I
showed
was
not.
It
was
a
change
of
one
line
of
code
and
then
standing
up
the
service
again,
but
the
demo
we
have,
if
you
want
to
look
at
it
online,
is
actually
live.
Migration.