►
From YouTube: Towards a Standardized Application Definition Model for Kubernetes - Phil Prasek & Sudhanva Huruli
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Towards a Standardized Application Definition Model for Kubernetes - Phil Prasek, Upbound & Sudhanva Huruli, Microsoft
With multiple Kubernetes application models emerging to capture the complex set of cloud resources and their connectivity, how do these approaches stack up and is there a path towards a standardized Kubernetes application model that becomes the unit of scheduling across clusters, regions, and clouds? In this talk we’ll explore two emerging application models: the KubernetesApplication in Crossplane (a multi-cloud control plane) and the Open Application Model (OAM) from Microsoft and Alibaba. We’ll provide an overview of strengths and opportunities of each approach and directions towards converging around a standardized application model as part of the newly formed CNCF SIG: sig-app-delivery.
https://sched.co/ZelS
A
A
And
then
you
have
a
question
of
do.
I
want
to
run
in
cluster
stateful
services,
or
do
I
want
to
use
cloud
services,
so
I'm
not
getting
a
page
at
3am
for
things
like
databases
and
caches
and
buckets,
and
then
there's
the
configuration
of
the
app,
whether
it
be
in
environment,
variables
or
config
maps
or
secrets
to
get
access
to
the
endpoints
that
your
app
needs
to
use.
A
So
then
you
take
that
in
combination
with
the
ops
behavior,
this
can
be
like
auto
scaling,
ingress,
config
security
groups,
health
monitoring
logging,
all
that
kind
of
stuff.
So
that's
really
what
goes
into
an
application
definition,
and
then
you
can
take
that
content
and
package
it
up.
However,
you
like
using
tools
like
helm,
which
is
great,
for
you-
know,
bundling
up
a
bunch
of
yaml
and
templating
that
you
can.
You
know,
take
a
helm,
template,
output
and
pipe
it
into
customize.
For
you
know,
customizing
the
configuration
there.
A
Once
I
have
my
container
images,
I
might
reach
for
something
like
a
docker
compose
and
so
that'll
get
me
up
and
running
on
my
local
dev
laptop,
pretty
quickly
I'll,
probably
be
pulling
in
some
in
cluster
stateful
services
like
postgres
or
redis,
and
you
know
I
might
even
be
able
to
sneak
that
on
to
my
endeavor
test
cluster
depending
on
you
know
the
environment
that
I'm
running
in,
but
at
a
certain
point,
somebody's
going
to
say
you
know,
hey
look.
We
really
should
be
running
staging
and
prod,
looking
very
similar
to
each
other.
A
And
then
you
have
to
get
you
know
the
secrets
for
accessing
those
cloud
services
for,
like
your
database,
plumbed
into
your
deployment.
So
there's
a
lot
of
like
intertwined.
You
know,
collaboration
that
needs
to
go
on,
and
then
you
need
to
layer.
On
top
of
that,
you
know
kind
of
the
auto
scaling
behavior
ingress.
A
But
if
you're,
creating
bespoke
infrastructure
configurations
oftentimes,
just
getting
this
whole
process
working
can
take
days
or
weeks,
oftentimes,
just
shy
of
like
a
whole
month
to
get
all
the
app
config
going
into
production
in
a
stable
way.
So
it
can
be
a
huge.
You
know
time
sync
and
definitely
not
as
efficient
as
it
could
be.
A
Is
that
you're
really
gluing
together
multiple
tools
and
they
have
multiple
management
models
and
multiple
representations
of
state
and
oftentimes?
These
are
inconsistent
across
the
different
environments,
and
so
it
becomes
increasingly
difficult
to
master
the
interactions
and
the
failure
modes
across
all
these
tools,
and
that
typically
results
in
you
know
error
prone
deployments
and
and
difficulty
and
just
being
able
to
understand
what's
going
on.
A
On
top
of
that,
there's
often
no
clear
ownership
in
terms
of
the
various
aspects
of
the
app
config
and
the
cloud
services
and
all
the
interactions
between
them.
And
so
when
a
change
is
made
in
one
aspect
of
the
configuration,
it
can
often
cause
unintended
consequences
and
override
behavior
in
other
aspects
of
the
configuration,
and
often
these
issues
are
only
found
at
deploy
time
and
so
hopefully,
most
of
the
time.
This
is
caught
like
in
the
staging
environment,
where
you
just
keep
turning
the
crank
over
and
over.
A
A
So
so
what
are
we
looking
for
in
an
app
model?
You
know
if
you're,
just
running
on
your
local
laptop
using
docker
compose
is
great.
It's
a
self-contained
app
model
you
can
use
in
cluster
stateful
services-
and
you
know
life
is
good.
Then
you
need
to
get
it
into
kubernetes.
So
you
know
you
can
use
compose
with
the
k
as
a
tool
to
convert
the
docker
compose
into
kubernetes
core
resources.
A
But
it
doesn't
give
you
a
case
native
declarative
management
experience
and-
and
so
sometimes
you
know,
we'll
see,
companies
spinning
up
gui
portals
for
provisioning
infrastructure
and
that
that
does
you
know
kind
of
as
an
alternative
to
using
the
infrastructure's
code
tools
in
the
pipelines,
and
that
does
provide
a
separation
of
concerns.
But
it
doesn't
really
give
you
something
you
can
automate
very
easily
and
it
doesn't
give
you
that
that
kubernetes
native
experience.
A
So
what
we've
seen
come
onto
the
scene
here
in
the
last
year
or
two
are
service
operators
here
towards
the
the
center-
and
this
includes
you
know:
gcp
config,
connector,
aws,
service
operator,
azure,
service
operator,
crossplane
providers,
and
what
these
do
is
they
bring
in
the
individual
cloud
services
as
kubernetes,
crds
and
they're.
The
low
level
managed
resources
that
provide
a
high
fidelity
representation
of
that
cloud
service.
So
you
can
drop
a
kubernetes
cr.
A
You
know
custom
resource,
which
is
just
a
yaml
file
for
a
database
or
a
cache
and
it'll
go
out
and
provision
that,
for
you
and
some
of
the
service
operators
do
a
good
job
of
letting
you
just
drop
an
entire
config
of
you
know
hey.
If
I
want
a
secure
database,
that's
production,
ready
and
monitored,
and
all
these
things
I
might
need
you
know,
5
or
10
or
even
15
different
resources,
and
so
I
want
to
control,
apply
that
entire
directory
of
config,
and
so
it
does
give
me
a
kubernetes
native
declarative
experience.
A
So
you
know
if
we
kind
of
move
up
to
the
the
top.
Another
option
is
just
to
say:
I
don't
want
to
deal
with
infrastructure
at
all,
just
giving
me
a
platform
as
a
service.
Give
me
a
pass.
You
know,
heroku
style,
you
know
kind
of
experience
and
most
of
these
passes
are.
You
know,
built
on
kubernetes
these
days
and
some
aren't.
I
mean
you
have
like
cloud
foundry
and
you
know
they
get
they
migrate
over
to
kubernetes,
and
you
know
you
have
open
shift
and
then
some
more
you
know
modern
ones.
A
So
what
we
see
in
a
lot
of
kind
of
the
the
medium
to
larger
companies
that
we
work
with,
is
you
know,
kind
of
a
internal
cloud
platform
team
or
a
cloud
platform
or
a
platform?
Ops
team
be
created
with
the
charter
of
you
know,
providing
these
organizational
best
practices,
security
policies
and
a
running
platform
that
just
makes
it
easier
for
app
teams
to
use
and
then
go
and
get
that
running
out
of
the
gate.
A
A
And
ultimately,
we
really
want
extensibility
via
the
kubernetes
api,
and
we
don't
want
a
limiting
pass
abstraction.
That's
too
abstract
and
not
extensible
or
a
gui
portal
that
doesn't
allow
us
to
extend
it.
We
want
something
that
says:
hey
if
I
want
to.
You
know,
use
a
new
technology
in
my
platform,
and
I
want
to
make
that
available
for
use
within
my
app
model.
I
should
be
able
to
compose
and
use
any
kubernetes
crd,
any
kind
in
my
model
definition
and
ultimately
we
want
to
get
this
streamlined
path
from
dev
laptop
to
production.
A
So
it
probably
goes
without
saying,
but
you
know
we
want
to
be
able
to
use
the
app
model
with
git
as
a
source
of
truth.
You
want
to
be
able
to
use
existing
tools
like
home,
customize
flux,
and
we
want
to
be
able
to
use
our
existing
deployment
workflows.
So
we
don't
have
to
you
know,
drop
everything
that
we've
done
to
date
and
replace
it
with.
You
know
the
new
way
of
doing
it.
So
if
we
look
at
what
you
know,
a
modern
application
looks
like
this
is
the
simplest
possible.
A
You
know
modern
application
with
our
php.
You
know
web
app
here
and
a
redis
back
end,
but
those
are
effectively
two
components
of
this
simple
app
and
they
have
different.
You
know
aspects
and
characteristics.
In
terms
of
do
I
want
auto
scaling
manual
scaling.
You
know
for
my
ingress
route
through
my
api
gateway.
How
do
I
want
that
configured
which
security
group
do?
A
I
want
to
kind
of
control,
you
know
who
has
access
to
what
and
on
what
networks
and
so
forth
and-
and
so
that,
basically
defines
you
know
the
app,
and
so
if
we
were
to
separate
those
aspects
into
what
I
want
to
run
and
how
I
should
run
it.
We
basically
get
this
separation
of
concerns,
and
so
we
have
the
components.
A
So
if
we
look
at
this
in
combination
with
you
know
what
we
have
with
the
open
application
model,
there
are
five
kinds
or
resource
types,
so
there's
a
workload
which
we
talked
about,
which
is
basically
what
I
want
to
run.
There's
a
component
which
is
an
instance
of
a
workload
that
I
can
compose
into
an
application
and
then
there
are
traits
and
scopes
which
are
operational
behaviors
that
I
can
apply
to
a
component.
A
So
I
can
apply
a
trait
to
a
component
that
modifies
the
behavior
and
effectively
overlays
configuration
onto
that
in
a
defined
way.
And
then
I
have
scopes
that
can
basically
group
resources
together
and
I
can
use
that,
for
you
know,
networking
scopes
or
health
scopes
and
these
types
of
things-
and
I
can
put
all
of
that
into
an
app
config,
an
application,
config
and
then
just
deploy
that.
And
so
what
we'll
see
is
that
you
know
with
our
php
app
here.
You
know
we
have
the
php
as
a
workloads
container
image.
A
We
have
redis,
which
is
our
you
know,
acme
corp,
you
know
secure.
You
know
scalable
redis,
that
we've
defined
that
might
have
you
know
a
handful
of
resources
bundled
into
it,
because
we've
composed
those
together
using
crossplane,
for
example,
and
then
we
have
you
know
traits
and
scopes
in
our
app
config
that
are
bound
to
those
components
that
define
the
operational
behavior
of
the
application,
and
the
great
thing
is
is
that
these
are
all
kubernetes
api
resources,
and
so
I
can
you
know,
version
control.
I
can
use
get
ops.
A
I
get
all
the
benefits
of
you
know,
being
able
to
use
all
the
tooling
that
works
with
the
kubernetes
api
and
not
just
cubecontrol,
or
you
know,
customize.
You
know
and
kind
of
modifying
those
resources,
but
even
things
like
the
terraform
kubernetes
operator.
Right
I
mean
I
can
use
any
existing
tooling
that
I
want,
since
it's
based
around
the
kubernetes
api,
and
so
when
we
look
at
the
separation
of
concerns
across
you
know
these
different
roles,
you
know
the
app
dev
can
create
their
building
blocks
the
container
images
for
their.
A
You
know
web
ui,
their
service.
You
know
apis
the
platform.
Ops
team
can
create
their
infrastructure
composite
resource
definitions.
I
wanna
secure
postgres,
you
know
on
a
scalable
redis
and
then
I'm
gonna
go
ahead
and
compose
those
so
that
they're,
easy
to
consume,
building
blocks
that
an
app-ops
person
or
you
know,
role-
can
compose
into
an
application
configuration
by
dropping
components
in
there
and
then
associating
traits
and
scopes
to
those
components.
B
Thanks
phil,
so
what
I'm
going
to
show
is
how
we're
going
to
deploy
these
this
micro
service
based
application,
that's
backed
by
postgres
sql
to
a
kubernetes
cluster
using
ohm
and
crossplane.
So
we're
going
to
use
crossplane
to
deal
with
all
things
infrastructure.
So
crossplane
is
going
to
manage
the
connection
to
our
backend
azure
cloud
provider.
B
So,
first,
I'm
going
to
run
through
what
it
looks
like
from
an
infrastructure
operator's
perspective,
so
I've
cheated
a
little
bit
and
I've
already
got
a
kubernetes
cluster
on
my
machine
powered
by
kind
and
on
it
I
have
installed
crossplane
and
crossplane
is
going
to
be
the
control
plane.
That's
going
to
manage
all
of
my
infrastructure
for
me.
So
if
I
do
a
kubernetes
get
cross
plane,
I
can
look
at
and
see
that
I've
configured
the
backend
azure
provider
already
next.
B
So
here
I'm
defining
the
schema
for
what
the
postgresql
instance
looks
like
and
what
needs
to
be
declared
when
I'm
creating
postgres
so
to
apply
this
because
it's
a
kubernetes
resource
I
can
apply
apply
this
just
like.
I
would
any
other
kubernetes
resource.
So
I
go
ahead
and
do
cuddle
apply
and
it
gets
created.
B
Next,
the
schema
is
created,
but
I
still
want
to
expose
this
to
developers
and
operators
and
that's
where
the
infrastructure
publication
comes
in
the
infrastructure
publication
makes
sure
that
the
infrastructure
definition
I
created
is
actually
available
to
the
operators
and
developers,
and
likewise
this
is
also
something
that
I
can
just
do.
A
group
cuddle
apply
to.
B
The
third
bit
of
infrastructure
and
the
part
that
I
find
the
coolest
and
where
crossplane
really
kicks
in,
is
something
called
a
composition.
A
composition
is
the
thing
that
takes
different
infrastructure
components
and
puts
them
together
into
one
unit.
So
in
this
case,
because
I'm
using
the
azure
provider,
I
know
that
azure
has
a
few
things
that
I
need
to
declare
in
order
for
me
to
get
postgres,
I
need
to
create
something
called
the
resource
group,
the
actual
postgres
sql
server
itself
and
the
postgres
firewall
rules.
B
The
last
step
for
the
application
for
the
infrastructure
operators
is
to
expose
the
necessary
workload,
definitions
and
trade
definitions.
Now
these
are
own
concepts
in
ohm.
A
workload
definition
is
something
that
the
infrastructure
operator
can
expose
for
app
devs
to
actually
run
an
instance
of
something.
In
this
case
those
are
containerized
workloads
and
a
postgres
sql
instance.
B
So
the
infrastructure
operator
is
saying:
hey
on
this
particular
environment.
You
can
run
containers
and
you
can
run
postgresql
instances
traits
in
ohm
augment
the
way
certain
workloads
run,
and
in
this
case
the
only
trait
I'm
exposing
is
something
called
as
a
manual
scalar
trait
and
let's
go
ahead
and
see
what
that
does
when
we
get
to
the
actual
components
in
ohm.
B
Next,
we're
going
to
transition
and
look
at
what
the
application
developer
has
to
do.
As
phil
mentioned,
the
application
developer
is
responsible
for
prescribing
what
needs
to
run
so
because
I'm
running
five
micro
services,
I'm
going
to
declare
each
of
those
as
an
home
component
within
those
components.
You'll
notice
that
I
have
a
kind
here
for
the
workload.
So
this
is
a
kind
postgres
sql
instance
requirement
which
tells
crossplane
that,
in
order
to
run
this
component,
you
need
to
go
ahead
and
actually
create
something
in
azure.
That
is
a
postgresql
instance.
B
If
you
look
at
all
the
other
components
that
I'm
creating
they're
all
of
type
containerized
workload,
there
are
two
things
that
I
want
to
call
out
here.
One
is
in
the
component,
I'm
specifically
calling
out
how
much
storage
I
need,
and
if
I
go
back
to
the
infrastructure
definition
you'll
notice
that
that's
something
that
was
required.
B
The
other
thing
I
want
to
call
out
is:
there
are
certain
parameters
that
the
application
developer
exposes
in
a
component,
and
these
parameters
are
something
the
operator
operator
can
take
and
override,
so
they
can
configure
how
certain
things
run.
So
in
this
case,
you
want
to
make
sure
that
things
like
the
database
secret
are
something
that
you
absolutely
need.
B
Now,
at
the
start,
I
did
a
get
kdf
crossplane,
which
showed
what
crossplane
is
managing.
If
you
take
a
look
at
this
command
now,
you'll
see
that
there's
a
lot
more
things
that
crossbones
looking
after
instead
of
just
the
provider,
all
the
infrastructure
publication,
the
definition
and
all
the
ohm
constructs
from
trade
definitions
to
components
are
things
that
cross
planes
actually
managing.
B
If
I
do
a
keg
at
pods,
you'll
notice
that
there's
still
nothing
running,
everything's
declared
but
nothing's
actually
running
out
quite
yet
to
get
things
running
we
shipped
over
to
the
app
office
persona.
These
personas
don't
necessarily
need
to
be
different
people,
but
they
are
separate
tasks
that
are
streamlined
for
each
persona.
B
B
So
we're
just
going
to
put
a
watch
on
this
that
data
api
microservice
connects
to
back-end
postgres,
which
in
azure
takes
some
time
to
come
up.
So
while
that
spins
up
I'm
just
going
to
stop
sharing
my
screen
and
run
through
the
rest
of
the
slides,
this
should
take
around
four
minutes.
So
we'll
come
back
in
in
four
minutes.
For
this.
B
So
I
want
to
go
ahead
and
talk
about
the
the
kubernetes
app
model
and
what
the
ecosystem
looks
like.
We
created
a
magic
quadrant
based
on
what
phil
mentioned
earlier,
where
the
y-axis
is
really
the
separation
of
concerns,
and
the
x
is
talking
about
how
kubernetes
native
the
tools
are.
We
have
docker
compose,
which
is
a
fantastic
tool
for
entry-level
developers
and
also
just
as
a
low
barrier
of
entry
into
the
container
and
kubernetes
ecosystem.
B
Next
we
have
tools
such
as
terraform
cloud
formation
and
arm,
which
are
all
infrastructures
code
tools,
and
here
you
can
describe
your
kubernetes
core
resources
and
it's
a
step
towards
having
a
separation
of
concerns,
and
it's
not
quite
kubernetes
native
yet,
but
it
is
declarative
if
you
go
further
down
the
x-axis.
This
is
where
you
get
the
kubernetes
resources
and
the
service
operators
that
phil
mentioned
earlier.
So
here
everything
is
a
core
kubernetes
resource,
whether
it's
stuff
that
the
clouds
are
representing
as
kubernetes
crds
or
kubernetes
core
resources
themselves.
B
B
I
want
to
touch
a
little
bit
on
where
the
community
started
and
what's
coming
up
next,
so
when
microsoft
initially
kick-started
this
project,
I
think
it
was.
At
the
beginning
of
last
year,
we
partnered
with
alibaba
cloud
to
create
the
spec
and
soon
after
upbond
joined
with
its
crossplane
folks,
to
actually
contribute
to
the
specification.
B
B
Om
is
definitely
in
its
early
stages,
and
one
thing
I
want
to
call
out
is
when
crossplane
joined
us,
we
actually
changed
the
spec
up
a
large
amount
from
what
it
was
before
they
joined
to
what
it
was
after.
So
there's
still
a
long
ways
to
go
and
there's
still
a
lot
more
contribution
that
we
can
take
from
people
across
the
ecosystem
and
really
just
a
call
to
action
to
come,
join
the
community
and
help
us
improve
app
development
in
in
the
ecosystem.
B
So
if
I
do
a
query,
get
pods
now
you'll
see
that
the
data
service
is
connected.
All
of
the
demos
and
if
I
go
to
the
azure
portal-
and
I
do
a
refresh
you'll-
see
that
crossplane
has
now
provisioned
a
postgres
sql
instance
in
azure.
For
me,
the
demo
steps
that
I
followed
were
right
from
the
cross
plane
dock.
So
it's
nothing
magical.
B
B
I
already
had
opened
it
from
an
earlier
demo,
so
now,
if
I
hit
the
localhost
880
you'll
see
that
the
service
comes
up,
I
can
just
do
a
refresh
on
the
flights
data
see
what
kind
of
flights
are
running
across
the
states
in
the
world
right
now.
I
think
this
is
the
service
that
takes
the
longest
to
pull.
I
should
have
done
weathers
for
for
one
that
was.
B
B
There
you
go
so
you
can
take
a
look
at
the
weather
across
the
states
and
the
world,
it's
very
high
across
the
us,
so
that
just
puts
a
wrap
on
the
demo.
So
what
we
saw
there
was
how
you
can
compose
a
microservice
based
application
using
crossfling
to
abstract
the
infrastructure
concepts
away
from
the
platform
team
and
then
ohm
to
create
that
division
between
app
ops
and
app
devs.
B
Here
are
some
links
to
get
involved
with
us.
Om.Dev
is
a
great
link
that
has
the
rest
of
the
links
like
the
community
sessions,
our
email
list,
our
slack
channels,
crossplan,
has
its
own
community
with
its
own
slack.
It
has.
It
has
its
github
page,
and
the
last
thing
I
want
to
call
out
is
that
there
are
two
other
talks
that
are
happening
at
kubecon
europe
or
coupon
virtual.
I
don't
know
what
to
call
it.
B
A
A
And
so
you
can
just
drop
in.
You
know
like
a
simple
yaml
declared
a
vmo
file
and
then
provision
alongside
your
applications,
whatever
infrastructure,
your
applications
need
and
then
that
will
go
on
through
cross
plane,
reach
out
to
your
cloud
provider
and
provision,
those
and
then
basically
bring
the
secrets
down
and
then
allow
you
to
consume
those
services
from
your
kubernetes
applications.
A
So
great
question
there
there
was
another
one
about.
I
saw
that
crossplane
is
a
controller
operator
project.
So
have
you
thought
about
providing
it
via
operator
hub?
And
yes?
So
if
you
go
to
blog.crossplane.io
it's
the
third
blog
down
and
we
talk
about
how
crossplane
has
been
published
operator
hub
already
and
there's
an
integration
with
openshift
there.
That
makes
some
of
the
managed
services
available.
A
So
you
can,
you
know,
use
cross
plane
for
provisioning,
your
managed
services
from
your
cloud
provider,
and
so
I
definitely
recommend
checking
that
out
for
more
detail.
But
when
I
think
about
cross
plane,
there's
really
like
three
layers
and
there's
the
the
base
layer
that
provides
the
primitives.
Those
are
the
cross,
plane
providers
and
then
there's
cross
plane
composition,
which
sits
on
top,
which
allows
you
to
compose
without
writing
any
code.
A
All
of
those
primitives
into
your
own
infrastructure,
abstractions
your
own
platform
apis
and
then
you
can
publish
those
as
ohm
open
application
model
workloads
that
can
then
be
consumed
and
composed
into
an
home
application,
and
this
is
all
designed
to
be
layered
so
and
you
can
mix
and
match
whatever
you
want.
So
you
can
just
use
the
providers
at
the
base
layer.
You
can
use
composition,
you
can
use
them
by
itself
or
you
can
use
all
of
them
in
combination
with
each
other.
So
yeah
good,
good
question.
A
A
The
kubernetes
resources
directly
there
that
would
be
made
up
of
cross-plane
primitives,
and
so
then
you
can
basically
use
those
and,
and
then
the
really
beautiful
thing
about
being
behind
the
kubernetes
api
is.
Is
that
if
one
person,
you
know,
writes
a
great
composition
in
cdks
and
then
publishes
that
that
you
can
then
compose
it?
A
When
will
crossplane
own,
be
ready
for
production,
both
terraform
and
cross
planer
v0.12,
but
in
terms
of
functionality,
transformations
and
ecosystem
cloud
providers.
The
difference
is
huge
yeah.
So
this
is
a
great
question.
When
we
get
a
lot,
there
are
some
folks
that
are
starting
to
use
crossplane
in
production
now
and
we're
rapidly
going
towards
one
own.
So
we'd
like
to
get
a
couple
more.
A
That's
similarly
progressing,
and
so
definitely
by
end
of
the
year,
I'm
expecting
to
to
be
one,
oh,
but
potentially
sooner
so
yeah,
that's
kind
of
where
we're
at
with
with
that
and
definitely
encourage
everybody
to
join
crossplane
slack.
So
it's
just
and
there's
the
ohm
channel
in
cross
plane
slack
that
if
you
have
questions
about
folks
from
microsoft
and
alibaba,
are
there,
along
with
the
folks
from
upbound
so
yeah.
A
B
In
this
case,
but
the
industry
is
moving
towards,
you
know
these
two
folks
being
the
same
persona.
So
in
such
a
scenario,
how
does
this
help?
I
did
respond
to
to
the
question
in
the
chat
to
check
that
out,
because
you
only
have
like
30
seconds
but
super
quick.
I
think
ohm
doesn't
necessarily
state
that
these
two
personas
need
to
be
different.
B
They
could
be
the
same
person
just
the
tasks
are
different
and
kind
of
clearly
delineated,
so
they
can
focus
on
the
right
things
and
also
this
these
two
technologies
kind
of
set
up
the
platform,
for
you
know,
services
in
in
the
cloud
or
third-party,
where
the
infrastructure's
hidden
and
at
that
point
you're
only
dealing
with
application
constructs.
So
that's
how
it's
supposed
to
help
developers
and
kind
of
this
whole
devops
persona,
that's
being
created.