►
From YouTube: Open Application Model: Application-centric DevOps Approach - Andy Shi , Alibaba Cloud
Description
Open Application Model: Application-centric DevOps Approach - Andy Shi , Alibaba Cloud
Open Application Model is an open source spec and framework to encourage application-centric DevOps approach. It does so by separating the concerns of developers and DevOps. This talk will walk through the "Why" and "How" of such an approach. Andy will also compare OAM with other CD pipelines by showing some examples.
A
Now
remember:
in
the
old
days
we
used
to
do
everything
in
one
application.
We
would
write
business
logics.
We
would
write
the
middleware,
which
is
a
database
and
message
queues,
and
we
will
also
have
operational
tasks
in
one
application,
but
then
the
application
becomes
too
big
and
there
are
too
many
dependencies
and
really
slow
to
iterate
through
and
we
decided
to
break
it
apart.
A
A
A
A
A
Of
course
it's
it's
a
modern
day,
ford
right,
but
which
one
is
easier
to
drive.
Ironically,
it's
still
the
modern
day
fault,
it's
easier
to
drive.
So
how
does
that
happen
and
why
it
happened
right?
So
it
turns
out
that
the
key
to
adoption
is
really
the
level
of
abstraction
or
the
interface
exposed
to
the
driver
and
not
how
complicated
it
is
under
the
hood.
A
Now
the
problem
is
still
there
who
will
define
the
apis
or
resources.
Well,
especially
when
you
extend
the
pipeline
to
handle
more
devops
tasks
since
users
don't
want
to
deal
with
kubernetes
directly
right.
These
tasks
in,
for
example,
will
be
roll
out
canary
deployment,
monitoring,
auto
scaling,
etc.
A
Now
the
other
approach
which
is
really
popular
today
is
called
githubs,
where
we
say
the
git
is
the
source
of
choose,
that's
great,
but
the
users
have
to
define
all
those
apis
and
yaml
files
right.
So
it
doesn't
really
shield
the
users
from
dealing
with
those
boats
and
nuts
of
kubernetes
and
don't
forget
it's
not
just
the
raw
kubernetes.
It's
also
the
whole
ecosystem
right.
So
we're
talking
about
the
cncf
landscape
right.
How
many
projects
are
there?
So
what
I'm
saying
is,
regardless
of
how
you're
mapping
it?
A
A
We
hope
it
to
be
great.
Just
like
the
cars
right.
Let's
explore
this
example
a
little
bit
so
in
this
example,
I'm
wrapping
two
istio
apis
gateway
and
virtual
service
and
create
a
new
resource
called
canary
and
expose
that
to
the
user.
So
the
user
will
only
specify
the
service,
the
versions
right
and,
of
course,
the
weight
of
traffic,
and
they
don't
have
to
learn
gateway
virtual
service
of
istio.
A
A
They
need
to
maintain
several
pipelines
or
two
chains,
but
if
you
think
about
it,
that's
still:
okay,
as
long
as
they're
willing
to
learn
and
willing
to
pay,
it
still
beats
dealing
with
kubernetes
directly,
but
it's
really
bad
for
platform
of
pipeline
builders,
because
their
day
two
lives
will
become
harder.
We
are
forced
to
reinvent
the
wheels
every
time,
even
though
we
should
not
be
right.
There
are
so
many
projects
around
kubernetes
or
cloud
native
ecosystem.
A
Remember
the
cars
we
talked
about
earlier
right
in
car
industry,
even
though
each
car
looks
and
feels
differently
under
the
hood.
They
share
many
parts.
It's
generic
parts
now
we're
not
saying
that
every
pipeline
should
behave
the
same
but
say
similarly
to
cars.
There
should
be
common
apis
or
common
resources.
They
can
take
that
can
be
taken
advantage
of
right
right
now.
A
A
A
Right
in
turn,
it
will
make
the
teams
more
focused
and
be
efficient,
which
is
a
goal
of
cloud
native
movement.
What
happens
or
what
about
the
application-centric
view?
Right,
application-centric
view
is
a
view
from
the
perspective
of
applications.
Now,
today,
most
the
tools
are
focusing
on
the
perspective
of
infrastructure
and
cluster.
A
A
A
Really,
the
choice
is
about
how
flexible
it
can
be
when
it
comes
to
do
the
abstraction.
Nevertheless.
Nevertheless,
we
would
like
to
introduce
a
middle
layer
in
between-
or
in
this
case
it's
just
the
crd
modeling
layer.
So
this
term
modeling
is
borrowed
from
application
development.
There's
a
term
called
data
modeling.
A
A
A
A
The
key
native
deployment,
unlike
the
kubernetes
deployment,
it
will
create
revisions.
What
we
are
doing
here
is
really
to
automate
that
revision
logic
and
only
expose
the
fields
that
people
are
familiar
with
because
they
deal
with
deployment
more
right,
so
these
are
the
same
fields
that
they
will
use
when
a
specifying
and
deployment
resource.
A
So
these
are
some
examples
of
how
we
think
the
abstractions
should
be
done
and
so
far
we've
discussed
the
principles
and
methods
so
the.
Why
and
how?
If
you
agree
with
this,
you
think
this
makes
sense.
I
would
like
to
introduce
to
you
oem
the
project
that
I'm
working
on.
Oem
stands
for
open
application
model.
A
A
A
Now
in
oam
it
has
certain
concepts.
One
of
them
is
component
and
workload.
These
are
the
generic
form
of
we
just
what
we
just
saw
in
the
micro
services
and
manage
managed
services.
The
map
to
the
cloud
native
architecture
now
platform
builders
can
define
their
own
workload
schemas.
Here
you
may
choose
to
simply
wrap
around
deployment
right
and
to
filter
out
those
fields
that
you
see,
you
think
that's
not
relevant,
or
you
can
combine
deployment
and
service
right
into
a
web
server
workload.
The
next
part
is
called
traits
traits
are
operational
tasks.
A
A
Well,
they
normally
come
from
platform
builders
or
you
can
use
the
modeling
crd
methodology
to
modify
the
existing
crd
from
another
project,
but
the
key
here
is
that
they
are
abstracted
at
the
proper
level
right.
You
remember
what
we
did
for
to
argo
row,
rollout
right
for
end
users.
They
don't
have
to
learn
a
particular
project
right
and
for
the
platform
builders.
They
don't
have
to
reinvent
the
wheels
all
the
time.
A
A
It
specifies
the
needed
information
and
guidelines
for
resources
to
be
defined
as
work
levels
and
trades.
Also,
it
regulates
the
metadata
needed
to
manage
large
amount
of
resources,
for
example,
which
traits
will
conflict
with
each
other
right
many
traits
actually
will
conflict
with
each
other.
So
you
need
to
see
the
warning
messages.
A
Oem
also
currently
provides
an
sdk
to
help
the
development
of
trades
and
workloads.
Eventually,
what
we
want
is
to
have
an
ecosystem,
a
repository
of
open
source
workloads
and
trades,
so
that
all
platform
builders
can
benefit
from
now.
The
goal
of
oem
is
to
help
platform
builders.
It
provides
the
building
blocks
for
platform
builders,
but
it
will
not
dictate
what
the
pipeline
or
two
chain
of
paths
look
like
or
what
it
does
right.
This
is
still
the
the
job
of
the
platform.
A
Builders,
and
also
it's
not
the
final
design
oem
is
the
middle
layer,
so
you're
free
to
add
another
layer
of
abstraction
at
the
ui
level,
let
it
be
a
gui
or
cri
right
and
decouple
even
more
from
the
back
end,
the
better
the
api
level
and,
of
course,
you're
you're
responsible
for
the
for
the
core
business
values
right.
We
are
only
providing
the
building
blocks
for
the
common
features.
A
If
you're
interested
in
this,
please
join
us
and
we'll
be
more
than
happy
to
have
you
here's
some
information
of
our
am
we
have
a
bi-weekly
community
meeting
and
we
have
a
twitter
account
and
you
can
check
out
the
git,
repo
or
the
website.
Please
follow
us
and
join
us
and
we'll
be
happy
to
facilitate.