►
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
App Operator: The Hidden Persona - Ria Bhatia & Sudhanva Huruli, Microsoft
As enterprises look to deliver quality software as part of their business, two roles have been naturally created: the developer and the infrastructure administrator. Technologies such as Kubernetes have tackled the problem of managing the infrastructure. However, there is still a gap for how we manage applications on top of these systems. As a result, infrastructure operators and developers are forced to deal with concepts that are outside the scope of their roles. This talk will focus on the importance of having an application operator and the duties of this role in an enterprise embracing cloud native technologies.
https://sched.co/Nrw7
A
So,
hey,
hey
guys,
I
hope
it
runs
having
a
wonderful
coop
gun.
So
far.
Our
talk
today
is
gonna,
be
focused
on
the
application
operator
persona.
So
we're
gonna
talk
a
little
bit
about
the
importance
of
operations
to
managing
cloud
native
applications.
My
name
is
sedan.
Wa,
sometimes
colloquially
referred
to
as
but
mainly
by
Rhea,
and
you
wanna
introduce
yourself.
A
Yeah
I
knew
both
work
on
the
same
team,
so
this
talk
is
gonna,
be
pretty
abstract.
It's
not
really
gonna
dive
into
a
lot
of
like
technological
details,
but
if
anybody
has
any
questions
throughout
the
presentation
just
feel
free
to
stop
was
and
we're
open
to
having
a
discussion
any
point
during
the
talk:
no
okay,
so
a
little
bit
about
the
operator.
So
operations
is,
you
know
responsible
for
managing
everything
from
infrastructure
to
applications.
A
So
at
the
very
beginning
it
is
operators
and
responsibilities
to
choose
the
infrastructure
and
traditionally,
when
you're
on
premise,
this
refers
to
your
computer,
networking
storage
and
your
security
standards.
So
the
operator
is
responsible
for
choosing
the
technologies
that
are
gonna
back
these
and
they're
responsible
once
that's
done
to
actually
deploy
and
monitor
the
infrastructure,
so
they
responsible
for
building
out
the
tool
chain
to
make
sure
that
it's
easy
for
them
to
deploy
and
then
thereafter
monitor
that
infrastructure.
A
A
No,
so
even
within
the
operator
role,
when
we
talk
about
the
word
operator,
there's
a
ton
of
roles
that
fit
into
this
category.
Traditionally,
there
have
been
systems,
admin
who
are
responsible,
for
you
know
administering
the
VM,
so
administering
the
server's
when
there
needs
to
be
an
increase
in
capacity.
There's
the
network
engineers
that
we
see
very
often
in
a
large
enterprises-
and
these
are
responsible
for
things
like
IP
allocation
subnetting-
how
we,
where
the
applications
are
deployed,
what
kind
of
network
rules
are
applied.
A
You
have
the
IT
systems,
admin
who
are
more
like
who
work
more
with
developers
and
make
sure
that
the
developers
have
working
development
machines
and
have
write
security
access
groups.
You
have
something
known
as
the
sack
ups,
which
is
responsible
for
making
sure
that
all
the
enterprise's
security
standards
are
passed
down
to
the
actual
operators
and
the
app
ops.
You
have
something
called
the
database
admin
who
is
the
responsible
for
actually
administering
the
database
I
throw
this
talk.
A
So
clearly
the
operational
realize
you
can
see
has
a
lot
of
variants.
So
there's
a
lot
of
different
things.
An
operator
can
do
and
an
operator
who
does
roll-x
that
one
enterprise
might
do
something
completely
different,
a
different
enterprise.
So
if
I
say
you
know,
I'm
an
IT
systems
admin,
a
particular
Enterprise
I
could
move
to
a
different
one
and
it'll
be
completely
different,
and
one
of
the
challenges
with
operations
has
always
been
the
challenge
of
operating
on
different
environments.
So,
with
the
dawn
of
public
cloud,
you
have
this
computer
networking.
A
Storage
happen
in
two
different
places,
so
you'll
have
a
completely
separate
stack
on
Prem
and
then
in
public
cloud.
Certain
things
are
managed
for
you,
like
you,
know,
virtual
network,
our
VMs
and
the
availability
of
VMs,
but
typically
when
the
operators
are
building
out
these
tool
chains
such
as
CI,
CD,
monitoring
and
safe
delivery,
pipe
lines.
They
have
to
duplicate
this.
B
C
A
So
I
mean
Surya
and
I.
Both
work
on
the
container
computing,
which
is
responsible
for
aks,
which
is
our,
which
is
our
managed
kubernetes
offering,
and
even
there
like
what
we
see
is.
Customers
still
have
to
worry
like
if
customers
have
an
on-premise
setup
or
even
if
they
don't
they'll,
still
be
doing
things
like
bring
in
their
own
network.
Where
do
they
have
a
network
that
already
has
some
applications
and
they
want
you
use
that
same
network
for
their
kubernetes
cluster,
so
they
still
have
to
deal
with
a
lot
of
the
infrastructure
concepts.
A
And
one
of
the
things
that
I
wanted
to
talk
about
was
with
with
kubernetes
making
kind
of
applications
more
accessible,
because
that's
really
what
it
did.
It
came
by
it
obstructed
away
the
infrastructure,
and
it
gave
this
lure
that
you
know
applications
are
easily
accessible
and
developers
can
interact
with
this
thing
to
deploy
their
apps
that
you
know
the
operator
role
is
kind
of
going
away,
but
I
would
argue.
A
The
kubernetes
in
the
ecosystem
only
makes
the
operations
role
even
more
important
and
creates
a
more
well-defined
separation
between
infrastructure
operations,
which
is
you
know,
those
folks
are
responsible
for
the
lower
level
things
in
your
enterprise,
like
your
on-premise
setup
and
then
the
folks
who
are
responsible
for
just
operating
the
applications.
So
if
you
have
a
common
API
surface
on
top
of
the
infrastructure,
you
can
create
a
separate
role
for
those
people
who
are
responsible
for
the
delivery
of
applications
on
top
of
kubernetes,
the
monitoring
of
those
applications
and
then
the
safe
delivery
of
them.
A
This
makes
the
roles
more
streamlined
and
concrete.
So
you'll
have
those
folks
who
are
responsible
only
for
the
infrastructure
and
then
those
are
responsible
just
for
managing
the
applications,
and
this
division
enables
the
developers
to
just
focus
on
their
roles,
which
is
just
delivering
value
for
their
end
customers
and
from
the
customers
that
we've
spoken
to
having
this
clear
separation
allows
people
to
a
higher
for
talent,
which
means
that
you
can
hire
infrastructure
operations
who
are
good
at
what
they
are.
A
So
I
saw
this
a
little
bit
and
the
idea
that
kubernetes
came
by
and
it
created
a
division
between
infrastructure
and
applications
is
very
true,
so
it
creates
this
API
surface.
That
makes
it
super
easy
to
get
started
with
containers
and
deploy
applications
on
top
of
it,
but
some
of
the
things
that
it
makes
easier
can-can
you
can
lure
you
in
and
then
it'll
becomes
very
complex
really
quickly.
So
the
analogy
that
I
like
to
use
is
math,
which
is
you
know,
you
start
off
learning
math
and
you
know
you
learn.
A
1
plus
1
equals
2
and
it's
super
easy
and
really
quickly
you
get
into
like
really
complex
and
it
becomes
a
very
big
beast.
So,
for
example,
if
you
were
to
deploy
a
hello
world
application
and
kubernetes
as
a
developer,
the
quick
starts
are
very
easy
and
you
think
you
know
you
can
get
a
mini
cube
cluster
on
your
local
machine
and
you
can
deploy
a
hello
world
application
and
you're
up
and
running.
A
Really
quick,
but
the
day
to
ops
have
you
know
actually
deploying
this
thing,
setting
up
an
ingress
setting
up
Auto
scale
policies
to
support
your
customers
and
managing
all
of
those
quickly
becomes
very
cumbersome,
and
you
don't
want
your
developers
doing
that.
You
want
a
bunch
of
folks
dedicated
to
application
operations
to
actually
take
care
of
that
task.
A
So
I
we
think
that
there's
room
for
neural
in
the
ecosystem
that
sits
on
top
of
kubernetes,
which
is
definitely
an
infrastructure
Orchestrator,
and
that
is
the
app
pops
and
the
Apple
ops
role
is
responsible
for
just
delivering
the
applications,
monitoring
them
taking
care
of
things
like
safe
deployment
and
then
securing
the
traffic.
So
as
the
developer
you're
responsible
for
just
building
your
code-
and
you
don't
really
care
about
the
fact
that
it
runs
on
kubernetes,
underneath
the
hood,
the
application
operator
would
make
that
decision.
A
For
you
as
a
developer,
you
you
don't
really
have
to
care
about.
You
know
how
safe
deployment
practices
are
done
in
your
enterprise,
so
you
would
write
your
code.
You
would
iterate
on
it,
upgrade
it
and
then
the
application
operator
would
take
care
of
doing
ok,
let's
use
service
missions
to
actually
do
the
Canaria
deployments
and
we're
gonna
do
we're
gonna
fold.
It
follow
the
canary
pattern
to
actually
do
safe
upgrades,
but
again
as
a
developer,
you
wouldn't
care
about
this
you're,
just
caring
about
writing
new
code.
A
So
these
are
the
duties
you
know
digging
into
those
duties
a
lot
more.
So
the
delivery
of
applications
includes
you
know,
setting
up
and
using
those
CI
CD
pipelines
to
deliver
the
apps,
and
you
can
do
it
deliver
this
to
multiple
environments.
By
virtue
of
Cabrini's
being
the
common
API
surface,
you
can
set
up
and
manage
the
monitoring
agents
on
kubernetes
and
you'll
get
a
common
control
plan
to
actually
monitor
these
applications,
and
this
also
includes
building
out
that
alerting.
A
Safe
deployment
includes
performing
upgrades
and
maintaining
availability
during
upgrades-
and
this
is
where
things
like
so
smashes
with
sto
and
traffic
actually
come
into
play.
The
last
one
is
securing
traffic
and
there's
actually
a
wider.
This
actually
falls
into
wider
category
of
just
security
in
general.
It's
not
just
about
securing
your
traffic,
but
also
making
sure
that
the
data
that
the
application
accesses
is
storage,
security.
A
But
even
in
on
kubernetes
the
application
operator
in
order
to
accomplish
all
these
tasks,
has
many
technologies
they're
disposable,
to
actually
get
this
done.
So
these
are
just
some
of
the
ones
that
we
found
just
by
doing
a
quick,
google
or
bing
search,
and
if
you
want
to
do
things
like
deliver
applications,
you
need
to
go
and
not
only
pick,
but
you
need
to
learn,
Jenkins
and
need
to
learn
Brigade
and
there's
a
bunch
of
tools
for
you
to
get
this
job
done.
A
If
you
want
to
monitor
your
applications,
there's
Prometheus
for
finai
data,
dog
dynaTrace
and
the
list
just
goes
on
and
as
an
app
ops,
you're
responsible
for
choosing
one
of
these
and
then
picking
the
right
one
for
safe
deployment
and
securing
traffic.
This
kind
of
falls
into
network
and
security
and
with
the
dawn
of
service
mesh
last
year,
there's
been
a
lot
of
technologies
that
are
available
to
actually
get
this
job
done.
A
The
point
being
that,
in
order
to
actually
manage
applications,
the
application
operator
needs
to
learn
a
lot.
They
need
to
learn
all
those
technologies
they
need
to
actually
set
it
up
and
setting
it
up
involves
them
dealing
with
the
kubernetes
cluster,
which
is
not
necessary
as
an
application
operator.
You
just
want
to
care
about
how
the
application
is
delivered
and
how
its
managed
and
you
shouldn't
need
to
care
about
the
underlying
infrastructure.
A
The
last
one
is
that
there
can
be
different
implementations
and
support
across
environments,
so
some
of
these
might
work
well
in
one
environment,
and
some
of
them
might
not
work
well
in
other
environments,
and
this
leaves
the
next
point
of
leaky
abstractions,
which
is
when
you're
trying
to
set
up
a
thing
like
service
mesh
on
kubernetes
and
you're,
trying
to
deploy
Co.
You
have
to
deal
with
a
lot
of
the
Emal's.
B
D
D
Three
years
ago
we're
managed
kubernetes
became
a
huge
thing,
and
a
lot
of
us
have
created
these
managed
community
services
past
that
about
one
of
the
packard
years
ago,
I'm
almost
to
maybe
surrealist
kubernetes
became
a
thing
that
also
that
was
a
huge
overloaded
term
that
encompassed
functions.
Containers
in.
D
As
a
service
containers
such
as
spin
up
on
the
fly,
so
that's
kind
of
what
we
branded
as
service
kubernetes,
it's
a
completed
term
that
we
use
in
marketing
a
lot
and
you
can
see
a
lot
of
you
just
walk
through
the
boots
and
walk
down
the
sponsored
boots,
you'll,
see
probably
kubernetes
or
know
both
kubernetes
there.
All
of
that
that
was
kind
of
also
in
the
next
phase
of
innovation,
where
we're
consistently
trying
to
figure
out
how
do
we
abstract
away
more
of
the
infrastructure
for
customers?
That's
very
sorry.
D
To
delayed
the
cloud
we
wanted
to
abstract
away
bare
metal
and
VMs
on
Prem,
and
then
we
wanted
to
abstract
away
what
it
means
to
putting
what
it
means
to
put
humans
together
and
that's
where
a
man
service,
man,
services
came
along
and
then
Teresa
realist
kubernetes.
But
we
think
there's
something!
That's
gonna
come
after
this.
So
when
we're
thinking
about
what
else
could
be
attractive
way,
and
why
would
customers
who
want
that?
Well,
they
don't
actually
care
about
managing
a
distributed
system
right.
Customers
are
just
here
to
deploy
their
apps
and
see
them
running.
D
They
care
about
their
business
code.
So
while
we
continue
to
get
there,
there's
probably
something
else
that
would
hopefully
attract
wait,
maybe
even
keep
it
needs
itself
and
then,
if
the
entire
management
of
kubernetes
were
dispute
system
up
to
somewhere
someone
else,
possibly
a
cloud
provider
and
possibly
some
another
operations
team,
possibly
there's
a
couple
things
that
are
starting
to
get
into
that
space.
So
Rio
from
Rancher
is
a
good
example
where
they're
trying
to
have
people
just
deploy,
applications
and
we'll
get
into
it
a
little
bit
later,
but
also
Kay
native.
D
So
the
roles
for
the
DES
landscape-
we
sasame
basically
brought
up
the
new
role
of
an
application
operator,
maybe
not
so
new.
All
this
application
operator
would
sit
in
a
space,
that's
passed
to
the
vetti's,
so
they
won't
actually
interact
with
human
eyes
itself.
They
wouldn't
interact
to
the
hearing
aids
API.
Only
infrastructure
operators
would
act
within
that
space
because
karate
is
too
hard.
D
You
still
have
to
manage
a
lot
of
stuff,
and
it's
not
really
for
just
it's
not
for
developers
to
deploy
applications
and
not
really
even
for
out
the
application
operators
to
deploy
and
run
applications.
Kuber
nights
just
gives
you
the
infrastructure
bits
for
that,
alright,
so
Kay
native,
if
they've
branded
themselves
also
as
serverless
kubernetes,
I
would
argue
it's
a
little
bit
of
a
step
further
than
that
they're
giving
you
a
bunch
of
building
blocks
for
applications
to
run
on
top
of
that,
so,
for
example,
they
have
serving
which
will
help
you
with
functions.
D
They
also
have
auto
scaling,
so
an
auto
scaling,
trait
or
auto-scaling
component
within
que
native.
So
if
you
want
to
scale
from
zero
to
ax
you're
able
to
do
so
with
just
installing
a
native
so
and
then
Rio
Rio
also
uses
que
native,
but
they've
built
a
really
nice
UI
through
Rancher,
and
they
have
a
bunch
of
different
load,
balancing
and
agent
CP
routing
rules,
canary
deployments,
so
they're
using
a
service
mesh
and
they're
pulling
that
for
you
under
the
hood.
D
D
We
are
basically
with
CRTs
and
production
of
custom
resource
definitions,
we're
creating
these
new
flavors
of
keeping
at
ease,
because
now
every
cluster
can
have
all
this
extra
functionality.
But
when
you
go
and
take
a
pod
stack
from
say
a
Kay
native
deployment
and
move
it
on
to
maybe
a
deployment
in
Amazon,
it's
not
gonna
work
the
same
without
you
deploying
it
infrastructure
bits
first
and
the
same
thing
with
Red,
Hat,
their
distribution
and
then
rancher.
So
all
of
these
and
then
even
Microsoft
in
it
even
other
cloud
providers.
D
A
lot
of
us
are
writing
our
own
custom
c
or
DS
to
give
customers
an
easier
time
and
more
functionality
and
have
the
kubernetes,
but
really
what
we're
doing
it's
kind
of
fragmenting
the
community.
So
this
is
a
quote
that
I,
it's
just
something
that
I
wrote
up
so
I'm,
just
gonna
read
it.
We
promised
flexibility
and
portability
to
use
of
kubernetes,
but
with
the
introduction
of
CR
DS
custom
resource
definitions,
they
add
extra
functionality
while
still
looking
and
feeling
like
kubernetes,
but
this
means
we're
closed
using
these
fear.
D
Ds
are
no
longer
no
longer
portable
to
any
kubernetes
cluster
they're
portable,
if
you
have
this
year,
DS
as
that
flavor
already
installed,
so
we're
changing,
basically
the
landscape
with
kubernetes
powers,
fragmenting
it
and
it's
a
not-so-secret
killer
of
OSS
communities.
If
we
take
an
example
from
Linux
back
in
the
days,
there
was
probably
12
to
15
different
distributions,
and
now
we
only
here
a
three
or
four.
We
could
argue
that
kubernetes
is
taking
that
same
route
and
keep
NCR.
Ds
are
most
likely.
D
So
what
if
we
could
use
a
common
API,
just
like
sasame,
talked
about
on
top
of
the
infrastructure
layer,
so
we
could
avoid
this
fragmentation
and
we
could
continue
as
a
community
building
together.
This
is
just
an
open
question.
If
we
don't
exactly
know
what
the
future
holds,
but
what
we
do
is
Rio
things
like
Rio,
K,
Natives
and
all
these
other
implementations
of
co2
use
that
are
popping
up
everywhere
are
probably
not
going
to
be
the
solution.
D
D
D
A
And
some
of
the
customers
that
even
we
work
with
especially
the
really
large
ones,
have
have
built
this
layer
on
top
of
qu
brandies
them
stuff,
so
their
developers
never
have
to
interact
with
it.
So
a
lot
of
the
large
enterprises
are
trying
to
get
away
from
exposing
kubernetes
to
their
I'm
customers
and
building
their
own
version
of
something
like
Rio,
which
you
know
they
call
it
micro
pods,
but
really
it's
just
providing
application
functionality
like
things
like
canary
deployments
and
auto
scaling.
A
These
are
constructs
that
are
application
oriented
and
they
just
happen
to
use
kubernetes
underneath
the
hood
so
they're,
creating
like
a
UI
surface
that
exposes
just
that
and
doesn't
really
expose.
You
know
HPA
and
all
the
other
kubernetes
details
to
actually
just
get
the
job
done.
So
we
think
this
is
gonna,
be
a
really
hot
space,
especially
with
things
like
korea
on
KDE
know,
coming
out.
I
think
the
next
coop
con
in
San
Diego
is
just
gonna,
be
focused
a
lot
on
on
announcements
related
to
this
space.
B
D
So
helm
is
really
good.
It's
almost
still
like
an
application.
It
was
trying
to
be
an
out
for
your
focus
tool
to
help
people
deploy
applications
on
top
of
kubernetes,
but
you
still
have
to
deploy
everything
you
still
have
to
manage
your
service
master.
You
still
have
to
manage
all
of
the
components
that
helm
is
probably
talking
to
my
home.