►
From YouTube: Panel: Emerging Trends in Cloud Engineering: Platform as product, APIs, self-service & more
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Panel: Emerging Trends in Cloud Engineering: Platform as product, APIs, self-service & more - Alex Jones, DevOps Institute Ambassador, Brian Gracely, RedHat Open Shift, Katie Gamanji, CNCF & Viktor Farcic, Shipa Moderator: Daniel Bryant, Ambassador Labs
The session aims to provide insights on the trends shaping the cloud native industry including the rise of platform teams, the need for increased automation and self service, Kubernetes as a universal control plane and the importance of organizing teams around APIs. Panelists will share insight, lessons learned as well as predicting technology and ecosystem trends for 2021.
A
So
welcome
everyone
to
the
emerging
trends
in
cloud
engineering
panel
that
will
focus
on
platforms,
products,
platform,
apis,
developer,
self-service
and
more.
We
have
a
fantastic
lineup
of
panelists
today,
genuinely
privileged
to
be
amongst
these
folks,
including
alex
jones,
brian
gracely,
katy,
kimanji
and
victor
farsec
I'll.
Let
them
introduce
themselves
in
just
a
second
I'm,
your
host
daniel
bryant,
I'm
currently
director
of
devrel
and
ambassador
labs,
where
I
focus
on
helping
engineers
build
platforms
and
deliver
applications
on
kubernetes.
B
Sure,
hello,
everyone,
my
name,
is
katie
gamanchi
and
currently
I
am
the
ecosystem
advocate
at
cncf
or
cloud
native
computing
foundation.
I
have
been
in
this
role
for
almost
half
a
year,
having
my
first
anniversary,
there
well
half
anniversary,
and
my
responsibility
within
this
role
is
to
pretty
much
lead
the
end
user
community.
So
these
are
the
vendor
mutual
organizations
that
use
cloud
native
tooling,
but
at
the
same
time
to
bridge
the
gap
between
these
practitioners
and
the
projects
within
the
ecosystem
and
yeah.
I'm
going
to
finish
off
with
this
one.
D
E
A
Excellent
next,
I
appreciate
all
that
sounds
perfect.
So
we'll
start
off
by
asking
the
question
of
what
does
a
modern
platform
or
I
often
say,
pass
platform
as
a
service.
Look
like
we
had
the
rise
of
infrastructures,
code,
containers,
kubernetes
and
many
of
us
are
hanging
back
to
the
days
of
heroku
of
cloud
foundry
where
it
was
git
push
master
and
we
were
good
to
go
right.
What
do
what
do
you?
All?
Think
of
modern
paths
encompasses.
D
I
believe
that
that's
the
next
step
in
evolution
of
kubernetes,
I
mean
we
know
that
that
modern
platform
is
going
to
be
kubernetes
based,
that's
certain
today,
and
I
think
that
we
are
just
starting
building
platforms
like
that
and
when
I
say
platforms
of
that,
I
mean
heroku-like
right,
because
I
think
there
is
some
kind
of
misconception
that
developers
will
adopt
kubernetes.
I
think
that
that
will
never
happen.
B
Actually,
I
I
actually
I'm
over
the
same
opinion
here.
I
think
there
is
always
like
an
evolution
cycle
we
go
around
when
it
comes
to
deploying
applications.
We
had
this
cycle
when
it
came
to
the
vms,
so
pretty
much.
How
can
we
make
best
use
of
our
compute
at
the
time
we
had
the
configuration
as
code
that
was
heavily
dominated
by
tools
such
as
ansible
or
salt
at
the
time,
and
I
think
we
kind
of
go
undergoing
the
same
patterns,
but
with
it
with
different
technology.
B
That's
where
we
have
kubernetes
coming
around
and
now
we
again
making
the
best
usage
of
our
space,
but
now
we're
using
containers
and
they
pretty
much
the
linux
primitives
that
linux
kernel
primitives
with
secrets
and
namespaces.
We
have
different
ways
to
describe
our
configuration
from
playing
yaml,
we
transitioned
to
templating
with
helm
charts.
Now
we
have
crds
to
further
customize
the
experience
of
our
developers,
and
now
I
think
we
are
at
a
moment
where
we
trade,
like
we
have
the
we
have
the
ecosystem
there.
B
E
It's
interesting
just
to
follow
from
katie's
statement
there
that
kelsey
hightower
came
out
with
a
really
great
sort
of
sentence
around
that
most
people
want
to
want
a
paz,
but
the
requirement
is
it
has
to
be
built
by
them
right
so
taking
all
these
commodity
tools
and
wrapping
it
into
your
own
kind
of
flavor.
To
give
you
your
own
paths,
I
thought
that
was
kind
of
kind
of
a
good
take
on
it
right.
D
D
E
C
C
The
the
question
is
like:
are
you
looking
for
highly
opinionated
sort
of
one-off
platforms
and
those
will
fit
certain
use
cases?
Where
do
you
want
something
you
know?
Kubernetes
gives
us
a
foundation
to
do
a
lot
of
things.
Is
that
a
better
way
to
solve?
You
know
the
breadth
of
problems
that
most
companies
have.
A
I
like
that
brian,
and
that
actually
leads
nicely
on.
Thank
you,
everyone,
but
that
leads
nicely
onto
the
next
question.
Is
we
frequently
now
talk
about
platform
as
a
product?
It
should
be
designed
as
a
product
managed
as
a
product
and
released
and
controlled
as
a
product
which
I
totally
buy
into
my
my
day
job.
How
does
the
implementation
of
this
differ
from
the
traditional
approaches?
Many
of
you
sort
of
mentioned.
E
I
think
from
my
own
experience,
there's
a
bias
towards
reuse
and
proliferation.
These
days
platform
as
a
product
is
essentially
a
way
of
mandating
and
ensuring
your
survival
within
the
ecosystem,
and
that
you
are
wrapping
up
all
of
the
domain,
specific
knowledge
and
the
components
that
you
need
to
be
successful,
and
you
know
I
think
of
some
of
these.
You
know
aforementioned
products
that
are
really
popular
in
the
ecosystem
and
heroku
really
being
kind
of
the
nostalgic
gold
standard.
E
But
if
you
were
to
rebuild
heroku
in
the
case-based
environment,
it
would
look
very,
very
different,
and
I
think
that
it's
really
imperative
that
we
understand
that
there
is
no
panacea
currently
and
really
when
we
think
about
platform
as
a
product.
Currently
it's
something
that
is
extensible
right,
so
there
can
be
community
reuse
as
well
as
building
on
top
of,
and
we've
seen.
Many
of
those
already
today.
D
The
the
place
where
I
think
that
many
or
one
of
the
main
reasons
why
many
platforms
failed
in
in
the
past
is,
I
believe
that
they
all
tended
to
go
to
extremes
either
be
extremely
opinionated
and
satisfy
let's
say
developers
and
completely
leave
operators
and
sys,
admins
and
sres.
You
know
people
who
are
making
sure
that
systems
are
running
properly,
unsatisfied
or
like
kubernetes
is
today
that
he
satisfies
one
group
and
it
doesn't
satisfy
the
other
right,
so
it
usually
goes
into
extreme
extremely
opinionated.
D
Doesn't
work
for
sysadmins
works
for
cisadmins
developers
cannot
use
it
and
that's
why.
I
believe
that
we
are
now
in
a
good
spot
that
we
have
that
we
have
kubernetes,
it
does
satisfy
c-service,
it
does
what
it
needs
to
do,
and
what
we
are
missing
is
that
layer
on
top
that,
that's
why
I
believe,
heroku
in
a
way
failed
or
docker's
form
failed
as
well.
They
started
with
from
that
other
direction.
C
Yeah,
I
think
I
think
it's
interesting
as
we
get
into
thinking
about
it
as
a
product.
We've
we've
sort
of
moved
past.
The
idea
of
like
is
the
decision
sort
of
buy
versus
build
something
yourself
right,
take
a
lot
of
the
parts
together
and-
and
now
it's
it's
more
a
matter
of
like
if
I
have
a
platform,
whether
it's
you
consume
it
as
a
managed
service
or
you
consume
it
as
software,
it's
does.
C
Does
that
the
way
that
that
thing
is
delivered
as
a
platform
meets
your
needs
so
like
as
an
example,
so
there
was
a
threat
on
on.
I
think
hacker
news
yesterday
or
the
day
before
that
was
you
know.
Kubernetes
is
really
complicated
because
it
comes
out
so
frequently.
How
do
I
keep
up
with
updates
and
and
one
side
of
the
argument
was
well,
who
cares
just
spin
up
another
cluster
and
move
your
stateless
applications
over
there,
and
when
you
put
that
sort
of
response
in
front
of
anybody
who
does
anything
stateless?
C
You
know
it's
somewhere
between.
You
know,
or
you
know,
kind
of
face
palm
and
I
think
we
need
to
realize
like
delivering.
The
platform
is
really
important:
delivering
updates
and
making
it
simple
for
people
to
consume,
but
but
there's
even
parts
of
that
that
that
are
hard
for
people
right,
like
the
three
or
four
months
cycle
of
kubernetes,
is
really
hard
for
an
organization
that
has
an
application.
They
don't
touch
nearly
as
quickly
right.
There
is
an
aspect
of
that.
That's
you
know,
lift
and
shift
or
modernize.
A
A
Is
this
clear
definition
of
personas,
so
it's
gone
through
a
few
iterations,
but
now
it's
focused
on
component
owners
which
are
mere
kind
of
developers,
application
operators,
kind
of
sre,
like
I
think,
slight
reliability,
engineering
like
and
infrastructure
operators,
which,
for
me,
are
the
kind
of
classic
platform
folks.
This
is
admin.
Folks
do
yeah
and
I
do
like
the
the
three
distinct
personas
rather
than
the
classic.
Perhaps
devon
ops
thing:
do
you
all
see
that
in
your
day,
jobs?
Do
you
see
perhaps
the
three
personas
there?
Do
you
like
that
part
of
the
oem
spec?
E
So
so
I
can
speak
a
little
from
a
financial
perspective
where
there's
a
highly
regulated
set
of
protocols
to
which
you
have
to
follow,
and
you
know
it
very
much
is
reflected
in
there
being
a
clear
distinction
between
operational
staff
who
can
touch
clusters.
Who
can
you
know,
deal
with
infrastructure
and
debug,
then
the
sre
team,
who
may
well
be
you
know,
observing
telemetry
and
making
iterations
on
application
code
and
then
you've
got
their
counterparts
with
the
development
cycle
team
and
if
you
were
to
draw
sort
of
a
venn
diagram.
These
all
touch
slightly.
E
You
know
between
the
three
groups,
and
so
it
is
nice
seeing
a
recognition
there,
and
the
thing
that
I
really
like
about
the
spec
is
that
it
looks
to
sort
of
unite
the
the
users
and
the
platform
builders
right
within
a
single
single
specification.
So
it's
it
very.
Much
is
reflective
of
what
we're
seeing
in
the
industry.
B
I
can
actually
bring
an
example
from
my
pastorals
as
well,
and
I
think
this
kind
of
segregation
between
different
roles
and
different
personas
that
happened
organically
for
us,
which
was
quite
likely,
but
initially
we
started
as
one
team
which
provisioned
infrastructure
as
a
service,
and
that's
if
we're
looking
at
the
team.
Topologies
that's
going
to
be
a
type
free,
and
at
that
point
we
would
just
pretty
much
build
for
the
demand
we
have
from
our
developers
straight
away.
However,
there
is
not
too
much
of
upskilling
going
on.
B
There
is
not
too
much
of
support
that
we
could
provide
continuously
and
that
kind
of
transition
into
a
a
team.
Actually,
our
team
divided,
where
we
have
our
platform
team,
which
just
focused
on
the
infrastructure
provisioning,
and
then
we
had
our
cloud
management
team
which
would
focus
on
that
ops
kind
of
culture
and
towards
the
end,
we
moved
towards
the
sre
model,
where
we
have
an
srt
included
as
well,
and
then
we
have
this
kind
of
collaboration
when
it
comes
to.
B
We
don't
just
provision
platform,
we
upskill,
but
at
the
same
time
we
can
push
back
on
feature
development
and
based
on
the
slos.
We
can
bring
things
that
would
really
empower
our
teams
forever.
Now,
why
I'm
saying
that?
Is
that
all
of
these
kind
of
free
teams
that
we
have
it
was
an
organic
kind
of
development
of
all
of
these
personas
that
we
see
in
first
by
the
open
application
model
as
well
and
at
the
time
we
had
to
provision
all
these
components.
B
We
had
to
create
our
own
methodologies
and
pretty
much
bring
build
the
tooling
of
bringing
the
tooling
house
which
will
allow
us
to
deliver
this
particular
or
to
deploy
our
application
using
these
models.
Now,
with
with
this
spec,
it's
already
there.
So
it's
kind
of
nice
to
see
this
further
confirmed
within
the
community,
but
at
the
same
time
it
brings
a
benchmark
and
standard
which
means
that
now
we
have
the
fundamentals.
B
C
Yeah,
I
think
what
katie
I
think.
What
katie
highlights
in
in
reality
is:
is
that
middle
that
middle
tier,
that
middle
identity
is
the
one
that's
going
to
end
up
being
the
most
fluid
right
on
at
any
given
time
they
may
be
more
infrastructure
oriented,
especially
if
let's
say
you're
moving
an
application
from
on-premises
into
the
cloud,
for
example,
or
even
cloud
to
cloud
and
then
at
other
times,
they're
they're
going
to
have
to
be
sort
of
more
the
application-centric
sre.
D
What
I
believe
is
kind
of
missing
from
that
description
is
describing
who
who
are
users
of
each
of
those
groups
which
is
often
overlooked?
They
tend
to
be
in
a
silo
right,
I'm
in
charge
of
infrastructure,
I'm
in
charge
of
this
or
that.
Well,
I
believe
that
the
real
move
forward
is
that
to
acknowledge
that
application,
sres
application
operators,
infrastructure
operators-
they
are
their
users-
are
developers
they're
they're
supposed
to
build
services
that
can
be
consumed
by
developers,
they're
not
supposed
to
actually
really
create
infrastructure.
They're
not
supposed
to
deploy
any
applications.
D
A
B
B
It's
going
to
be
pretty
much
innovation
because,
as
a
vendor,
you
don't
have
to
concern
yourself.
How
can
you
merge
your
components
with
the
platform?
The
standards
are
already
going
to
be
there.
So,
as
a
vendor,
you
can
focus
on
how
to
deliver
value
to
your
customers
of
minimal
agencies,
so
you
really
focus
on
on
your
customers
and
what
you
can
bring
to
them
straight
away
for
the
end
users.
On
the
other
side,
when
we're
talking
about
open
standards,
it
means
extensibility.
B
Now
what
it
actually
means
here
is
that,
as
an
end
user,
you
can
choose
multiple
tools
with
the
same
well
kind
of
trying
to
solve
the
same
problem,
but
you
can
benchmark
between
them
and
it's
easier
now,
because
you
have
that
one
platform
with
the
standards
integrated
or
the
interfaces
already
available.
You
just
injure
switch
in
between
them
and,
of
course,
when
you're
looking
into
the
entire
ecosystem
that
pretty
much
translates
into
interoperability,
which
means
that
we
have
an
ecosystem
which
is
quite
colorful
in
terms
of
the
technologies
out
there.
B
E
E
It
means
that
we
can
use
the
hotel
collector
and
have
a
guarantee
that
there
is
a
sort
of
a
longevity
to
this
project
and
that
vendors
are
coming
together
to
design
a
solution
that
will
benefit
the
users
and
also
allow
us
a
degree
of
choice
right
in
that,
if
vendors
are
compliant
and
they
conform
to
these
these
protocols
and
these
specifications,
then
we
know
that
we
can
have
this
path
to
migration.
Whatever,
should
we
choose
to
do
in
terms
of
our
business
direction?
C
Yeah,
I
I
think
I
think,
both
of
you
guys
both
of
you
point
out
something.
That's
that's
sort
of
indirectly
important.
We
used
to
do
standards.
We'd
have
these.
I
think
standards,
bodies,
the
ieee
or
wcc3,
or
whatever
the
nice
thing
about
them
being
community
based
now
and
especially
open
source
based.
C
Is
you
not
only
get
standards
that
come
with
code
but
but
to
a
certain
extent,
sort
of
the
economic
viability
of
those
standards
work
themselves
out
so
like
open
telemetry
is
a
great
example,
but
there
you
know,
there's
been
others
and
and
for
for
people
that
are
customers
or
users
of
it.
They
want
to
know
that
as
much
as
as
they
want
to
know
that
it's
a
standard
right,
they're
betting,
on
a
technology
they
want
to
know,
is
it
going
to
be
around
for
a
while?
C
Is
there
going
to
be
people
that
support
this?
I
don't
want
it
to
be
fragmented,
because
it's
not
good
for
it's
not
good
for
alex's
business
model,
it's
not
good
for
anybody
else's
business
model.
So
I
think
we've
reached
a
point
now
where
it's
evolved,
where
it's
it's
not
only
the
standard
which
is
great,
but
we
get
code,
but
there's
also
a
certain
amount
of
sort
of
economic
darwinism.
If
you
will
so
you
know
that
the
thing
that
you
ultimately
pick
is
going
to
be
more
viable
than
just
paper.
A
Very
nice
we're
going
from
a
java
background.
I
can
definitely
recommend
the
or
definitely
recognize
the
paper
specs
right,
like
ejvs
and
so
forth,
so
yeah
very
good,
very
good.
I
think
it's
a
sort
of
wrapping
up
question
now:
we've
covered
sort
of
some
of
the
apis
and
the
benefits
of
specs
I'd
love
to
get
your
thoughts
on
whether
kubernetes
is
somewhat
becoming
a
centralized
control
plane.
These
days,
it's
almost
a
universal
control
plane,
I
guess
the
rise
of
custom
resources
operators.
I
think
you've
already
mentioned
ryan.
A
C
You
know
for
for
some
yeah
having
done
this
for
for
a
while
with
communities.
I
think
it
is.
I
think
it's
a,
I
think
of
it
as
more
sort
of
a
foundation
for
what's
going
to
build
on
those
control
planes,
so
whether
that
control
plane
is
is
at
the
service
mesh
level,
whether
it's
sort
of
this
cross
networking
thing
like
submariner
and
other
projects,
I
think
it's
a
it's
a
really
really
good
foundation,
and
what's
going
to
get
interesting
with
it
is,
you
know,
does
the
control
plane
is
it?
Is
it
multi-cloud?
C
Is
it
sort
of
cloud
to
edge?
That's
where
I
think
we've
got
a
lot
of
flexibility,
but
the
nice
piece
is
we're
not
we're
not
kind
of
shifting
the
underlying
sand.
So
I
feel
really
good
about
that
and
I
think
you
know
like
we're
coming
up
into
kubecon,
but
kubecon
we
used
to
call
it
kubecon,
because
that
was
the
dominant
technology.
Now
cube
is
sort
of
the
the
sort
of
safe
and
boring
piece
of
the
pieces,
and
you
know
it's
control
plane
con
and
what
will
that
evolve
to
which
is
really
exciting?.
B
B
The
boring,
as
I
mentioned,
and
this
again
has
been
seen
by
the
fact
that
the
kubernetes
source
code
has
been
changed
for
our
time,
because
at
the
beginning
it
had
everything
integrated
within
it.
So,
for
example,
the
runtime
component
would
be
very
deeply
integrated
there
same
with
the
storage,
but
now
these
are
components
which
develop
completely
independently.
They
have
their
own
landscape
and
they
own
pretty
much
vendors
and
community
around
it.
B
So,
just
based
on
that,
we
see
that
kubernetes
is
getting
slimmer
like
the
binaries
for
for
the
kubernetes,
and
I
think
this
is
the
way
to
go
forward
becoming
slimmer.
It
means
it's
out
there,
it's
stable,
it's
reliable
and
people
can
use
reuse
it
for
anything
that
they
can
build
on
top
of,
and
I
think
there
is,
I
think,
kills
the
height
or
mentioned
this
guarantee
is
a
platform
to
build
other
platforms.
So
I
think
this
kind
of
encapsulates
that
quite
nicely.
D
And
this
one,
no,
I
I
I'm
quiet
mostly
because
I
I
completely
agree
I
I
don't.
Usually
people
associate
kubernetes
as
with
the
machine
that
runs
containers
to
me.
That's
definitely
not
the
main
benefit.
It's
all
about
its
api.
It's
about
the
scheduler,
and
we
see
I
mean
we
can
see
already
that
in
action,
people
are
running
mac,
farms
based
on
kubernetes,
api
right
or
control,
plane,
we've
seen
with
crossplane
managing
your
infrastructure,
with
again
with
crossplane
with
api
and
so
on
and
so
forth.
D
I
mean
we've
been
scheduling,
vms
as
if
they
are
containers
as
well
right.
So
I
would
even
make
a
prediction
that
kubernetes
control
plane
will
outlive
containers
even
right.
That's
that's!
That's
the
real!
The
real
power
of
kubernetes
is
in
a
control
plane,
not
in
the
fact
that
it
can
run
containers
in
in
your
cluster.
A
A
I
I
believe
that
the
api
is
probably
the
a
good
api,
often
outlives
the
implementation
right
as
a
final
outro
question
we're
going
dangerously
close
to
time
now,
I'd
like
to
get
like
the
tweet
size
version
right,
so
280
characters
of
where
you
think
the
most
innovation
in
software
delivery
is
going
to
happen
in
the
next
five
years.
Is
it
languages?
We
saw
dark
land
things
like
that?
A
Is
it
architectures
dreaded
nano
services
or
is
it
platforms
things
like
serverless
platforms
built
on
top
of
so
they
are
and
other
abstractions
in
terms
of
using
the
control
plane,
the
kubernetes
control
plane?
Is
it
yeah?
Perhaps
platforms
are
going
to
be
the
most
exciting,
so
languages,
architectures
or
platforms
where's,
the
most
innovation
going
to
come
from
kt
I'm
going
to
pick
you.
B
I
was
actually
hoping
you
wouldn't
because
I'm
I
think,
like
all
of
these
areas
are
going
to
be
quite
in
development
within
the
next
years,
but
I'm
actually
quite
biased.
In
this
perspective,
I
because
I've
been
following
the
platform
space
for
for
a
while.
Now
I'm
be
following
it
quite
closely,
I
think
here
is
where
there's
a
lot
of
dynamics,
but
again
I'm
seeing
this
from
my
own
kind
of
bubble
of
technologists
around
this
area.
B
So
I
think
when
it
comes
to
the
platforms,
I
think
there
is
definitely
an
improvement
when
it
comes
to
how
we
use
the
platforms,
how
we
deliver
that
developer
excellence,
operational
excellence,
simplifying
it,
we
still
are
like
hanging
around
yaml
manifests
which
we
shouldn't,
and
we
even
try
to
push
this
to
our
developers.
It's
still
the
case,
I
think,
moving
away
from
that
is
definitely
going
to
be
a
step
forward
and
personally,
I'm
quite
excited
to
see
how
we
can
use
some
of
these
platforms
to
deliver
these
applications
to
the
age.
B
This
is
something
again
which
I'm
following
quite
closely,
but
I
would
like
to
see
how
this
can
be
achieved
seamlessly,
but
at
the
same
time,
to
ensure
that
kind
of
obstructed,
propagation
of
applications
to
closer
well
to
areas
closer
to
the
user
is
pretty
much
at
the
edge.
So
yeah
from
my
perspective
is
going
to
be
the
platforms.
But
again
my
view
is
biased
here.
C
C
You
know
people
pushing
the
boundaries
on
what
you
can
run
on
these
environments,
what
you
can
distribute,
how
big
or
how
small,
but
I
think,
we're
going
to
keep
seeing
that
so,
whether
it's
you
know
architectures
to
make
apps
simpler
or
architectures
to
to
you
know
sort
of
deliver
applications
across
multiple
environments.
I
think
we're
going
to
keep
seeing
that
that
expand
quickly.