►
From YouTube: Interoperability in Cloud Native Continuous Delivery - Dr. Michael Garbade, Education Ecosystem
Description
Interoperability in Cloud Native Continuous Delivery - Dr. Michael Garbade, Education Ecosystem
Cloud native has become an important approach that enables organizations to increase the agility of applications and accelerate the transition of ideas into products for the end-users. In addition, the management of cloud-native applications through new paradigms such as continuous delivery has allowed organizations to venture into the market with their products much faster. In spite of these benefits, the cloud native and continuous delivery environments have some challenges, chief among them, interoperability. In this session, we shall discuss the lack of interoperability and the reasons it poses a challenge to achieve it. We shall use examples of common cloud native technologies and how the lack of common standards poses challenges in interoperability.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
So
what
is
intel
when
we
talk
about
interoperability?
What
are
we
trying
to
kind
of
like
say
we're
very?
What
are
we
trying
to
achieve?
Why
is
interoperability
between
different?
You
know
cic
tools.
Cicd
processes
are
important
right,
so
interoperability
is
an
idea
of
significant
value
to
any
open
source
community,
any
private
enterprise
or
any
government
organization.
A
That
is,
you,
know,
dealing
with
cicd
processes
every
day,
because
ci's
interoperability
helps
every
organization
every
unit
to
kind
of
avoid
some
of
the
common
problems
that
you
know
that
is
very
known
in
cicd
environments,
such
as
duplicated
information
across
different
teams,
lack
of
cohesion
between
developer
teams.
Assistance
of
you
know
several
tools
that
do
the
same
thing
right,
but
are
used
by
different
team
members,
because
the
people
have,
like
you
know,
background
experience
using
these
tools
and
they
don't
want
to
change
or
switch
to
other
tools
right.
A
A
So
let's
talk
about
types
of
interoperability
or
the
levels
of
internal
probability,
so
there
are
two
types
of
internal
probability.
If
you
want
to
kind
of
break
it
down,
one
is
semantic,
you
know
intel
probability
and
one
is
technical.
It's
all
probability
if
you
want,
you
can
also
call
it
like
partial
in
terms
of
probability
and
full
or
complete
interoperability
right.
Patreon.
Interoperability
is
like
if
two
and
cicd
systems,
for
example,
can
kind
of
like
exchange
information
or
exchange
data
right
or
communicate
with
each
other,
because
they
have
like
the
same
programming
language.
A
Basically,
they
are
built
with
java
or
they
are
building
ruby
and
so
like.
That's
like
it's
partial
interpretability,
it's
more
like
limited
internal
probability
right
and
it's
limited
by
specific
variable
constraint
and
the
constraint
could
be
like
they
must
have
the
same
programming
language
or
they
must
be
from
the
same
service
provider
right
and
that's
like
the
concept
of
semantic
interoperability.
So
it's
kind
of
like
you
have
interoperability
between
two
different
systems,
but
it's
not
like
100
interoperability.
A
In
all
cases,
then,
there
is
like
the
full
or
complete
interoperability
that
full
of
complete
interoperability
is
like.
You
have
two
different
systems:
they
can
be
written
in
two
different
languages,
java,
ruby,
python,
php
or
they
can
be
from
two
different
service
providers,
so
they
can
be
from
two
different
open
source
communities
right
and
this
ci
cd
systems
still
communicate
with
each
other,
whereas
you
can
still
exchange
information
as
if
they
were
built
by
the
same
service
provider
right.
A
So
those
are
the
levels
of
interoperability
that
exists
so
just
think
of
it
as
semantic
as
limited
and
check
the
kind
of
probability
of
like
you
know,
unlimited
or
you
can
also
call
it
ashram
and
complete.
You
know
intel
probability
so
and
between
these
two
extremes
they
are
also
like
you
know.
They
are
also
like
ranges
between
them,
but
you
can
kind
of
like
look
up
limited
and
you
can
look
at
full
operability.
A
The
ideal
place
we
want
to
be
like
with
all
ci
cd
systems
is
that
all
of
them
are
technically
a
problem.
That
means
they
are
fully
interoperable,
no
matter
which
programming
language,
whether
it's
written
in
java,
whether
it
was
driven
by
a
ruby
team
when
I
was
working
by
a
python
team,
whether
it
was
written
by
a
php
team
or
a
singular
plus
team,
whatever
you
want
different
ci
cd
systems
to
complete
the
entire
problem.
A
A
A
You
know
put
it
on
the
slides
any
names
of
ncd
tools,
because
I'm
not
recommending
anything
I
mean,
but
I
assume
all
of
you
know
like
all
the
different
cicme
tools
like
jenkins
jenkins
x,
ms
asia,
devops
aws,
pipeline
microsoft,
vsts,
bamboo,
good
luck,
cool
ship,
cold,
fresh
tnc,
I'm
sure
I
forgot
with
some
other
ci
cd
systems.
Now
the
problem,
the
whole
problem
with
achieving
interoperability.
When
it
comes
to
cicd
pipelines,
we
have
basically
two
titles
in
the
cd
systems.
Some
of
them
are
open
source.
Some
of
them
are
commercial
right.
A
So
the
open
source
ci
cd
systems.
It
will
not
be
hard
to
kind
of
make
them
interoperable
all
right.
It's
gonna
be
too
hard
because
the
people
building
those
systems
they
don't
have
any
like
commercial
interest,
they're,
not
doing
it
to
kind
of
make
a
profit.
So
it
could
be
like
a
a
ruby
team
that
is
like
interested
in
launching
like
a
ruby
based,
ci
cd
system
and
then
there's
like
a
phv
team.
A
Doing
the
same
thing
and
there's
like
a
python
thing
named
the
same
thing
right,
but
the
ci
cd
foundation
could
talk
to
all
these
teams
right
and
define
some.
That's
you
know
for
them
that
they
can
follow
to
make
all
the
difference.
The
icbd
tools
that
they
are
building
with
different
languages
like
completely
interoperable.
A
The
big
problem
actually
appears.
If
you
know
we
are
talking
about
commercials,
the
icd
tools
right
because
commission's
the
icd
tools,
the
companies
building
this
cic
tools,
they
are
building
them
with
intention
to
make
money.
They
are
building
them
with
intention
to
make
their
ci
cd2
different
than
competitors.
A
They
are
building
them
with
intention
to
make
this
the
icd
tool,
you
know,
have
more
value
than
open
source
the
icd
tools
right,
so
they
are
also
building
them
in
a
way
that
they
have
a
competitive
advantage
in
the
market.
So
the
core
premise
of
existence
of
this
commercial
cicv2
companies
is
like
differentiating
themselves
from
every
other.
Ic
need
to
that
exists
right.
So
if
a
company
is
main
goal
is
to
differentiate
itself
from
every
other
city
tool.
A
What
is
gonna
happen
is
this
vendor
this
service
provider
is
not
gonna,
be
really,
you
know
open,
and
you
know
making
his
the
icd
system
interoperable
with
others
the
icd
systems
right
they
want
to
keep
it
separate.
They
want
to
kind
of
like
lock
in
companies,
and
they
want
companies
to
stay
after
it's
like
using
the
sdic
system.
They
want.
You
know,
as
soon
as
the
development
team
has
kind
of
deployed
the
sdi
cd
system
in
the
airport
pipelines
that
they
can
switch
right.
A
So
this
they
want
to
build
like
highest
transaction
switching
costs,
and
that
is
actually
one
of
the
main
problems
that
one
of
the
main
challenges
that
exists
is
that
it's
gonna
be
very
hard
or
it's
gonna,
be
very
impossible
for
to
kind
of
like
make
commercials.
The
icb
systems
into
opera
will
talk
to
each
other
and
also
open
source
systems
right
because
their
vendors
are
not
willing
to
kind
of
like
open
up
their
back
and
the
back
end
of
their
software,
or
they
don't
have
any
interest
to
kind
of
in
general.
A
Ci
cd
systems
solutions
themselves
into
open
world
open
source
solutions
right
because
they
fear
that
if
they
do
that,
then
they
are,
you
know
their
solutions
become
obsolete,
but
they
still
lose
like
market
share,
that
they
will
lose
money
and
they
will
kind
of
like
run
out.
You
know
run
out
of
business
right,
so
this
is
like
the
main
challenge
that
is
actually
facing
the
cicd
community
and
cicd
foundation.
A
To
them
to
their
systems
interoperable
right,
but
the
other
challenge
that
is
also
faced
with
open
source
site
is
that
the
open
source
guys
they
normally
develop.
You
know
their
software,
they
develop
it
as
a
part-time
job
and
they
don't
have
a
lot
of
financial
resources
right.
So
if
they
have
to
make
their
system
just
the
icd
systems
interoperable,
it
means
they
will
need
to
spend
more
time.
A
They
need
to
dedicate
more
resources
in
development
of
the
spicy
needs
right
now,
so
there
is
no
financial
incentive
for
them
as
well
to
spend
time
making
just
the
icy
need
to
tools
like
right.
So,
even
if
they
are
approached
by
the
cicd
foundation
or
any
other
person,
they
have
no
need.
They
see
no
need
it's.
You
know
they
see
no
agency,
so
maybe
the
cicd
tools
right.
A
So,
let's
talk
a
bit
about.
You
know
what
kind
of
initiating
some
kind
of
like
programs,
what
kind
of
activities
the
cicd
foundation
and
other
people
in
the
open
source
community
I'm
undertaking
to
kind
of
like
stuff.
Slowly
driving.
You
know
commercial
service
providers
and
driving
open
source
teams
to
understand
the
importance
of
interoperability.
A
A
A
So
now,
let's
discuss
what
has
been
done
on
a
more
institutional
and
more
foundational,
more
like
global
level,
to
kind
of
like
bring
some
sort
of
interoperability
in
ci
cd
pipelines.
There
are
a
lot
of
companies
that
are
kind
of
like
shown
entries
or
you
know,
kind
of
like
came
forward
kind
of
like
drive,
you
know,
drive
other
companies
or
drive
or
existing
fans
and
all
people
in
the
open
source
community,
as
well
as
commercial
vendors,
to
start
thinking
seriously
about
interoperability.
A
One
such
initiative
is
the
special
interest
group,
which
was
created
in
2019
and
special
interest
with
the
special
interest
group.
The
sig
is
within
the
continuous
delivery
foundation,
so
the
cdf
foundation
and
the
special
interest
group,
the
goal
that
they
have
is
basically
is
to
come
up
with
interoperability.
A
What
is
the
meaning
of
interoperability
right
for
ci,
cd
pipelines
for
a
ci
cd
ecosystem?
So
they
want
to
kind
of
like
define
exactly
what
interoperability
means
and
how
everybody
should
understand
the
operability
right,
so
they
are
also
championing
the
need
to
collaborate
right.
They
are
kind
of
like
explaining
all
different
participants
in
the
ecosystem.
A
Why?
It's
important?
Why
is
their
benefit
that
they
need
to
collaborate
in?
You
know
achieving
interoperability
right
in
a
neutral
form,
and
they
are
also
kind
of
like
showcasing
the
challenges
that
you
know
developers
face
right
in
cicd
pipelines
every
day
because
of
the
lack
of
interoperability
right,
and
they
are
also
kind
of
like
exploring
synergies
between
cicd
projects
right.
They
are
kind
of
like
setting
up
small
projects,
and
these
projects
are
meant
to
build
like
synergies
between
different
the
icd
systems
right
and
the
idea
behind
this.
A
Like
you
know,
projects
is
like
to
build
more
collaboration
right,
complete
more
communication
and
partnership
between
different
ci
cd
service
providers,
and
the
other
thing
that
they
are
doing
is
like.
Basically,
they
want
to
reduce
the
need
right
for
users
to
implement
their
own
in-house
solutions,
because
what
is
happening
today,
right
now
due
to
the
lack
of
interoperability,
have
there
so
in
every
cicv
process
or
pipeline.
A
If
you
look
at
it,
if
you
study
it,
be
that
amazon
leader
erickson
google,
be
the
facebook
beta
small
startup,
what
happens
is
all
the
companies
they
build
their
own
like
in-house
custom
solutions
to
make
the
different
ci
cd
systems
into
our
property
right.
They
kind
of
like
to
build
some
hacks
right
to
make
the
csc
tools
interoperable
and
that
one
of
the
goals
that
sag
to
team
has
is
to
make
this
kind
of
work.
That
is
being
done.
This
hacks,
like
you,
don't
need
it
at
all.
A
A
You
know
big
enterprises
is
open
to
small
startups
right
and
the
continuous
liberty
foundation
is
investing
a
lot
of
resources
now
into
intel
probability,
and
they
want
to
kind
of
set
up
goals
that
they
want
to
achieve
yeah
for
cicd
ecosystem,
with
the
help
of
the
sig
team
right.
So
that
is
it
and
I'm
gonna
stay
around
for
any
questions
that
you
have,
and
you
know
if
you
have
generous
the
icb
questions,
you
can
discuss
it.
A
If
you
want
to
discuss
you
know
interoperability,
issues
that
you
have
faced,
you
can
discuss
it
as
well.
If
you
have
some
interoperability
experiences
to
share
and
from
your
way
from
your
own
cicd
and
pipelines,
it'll
be
very
interesting
to
hear
yeah
so
yeah,
I'm
michael
I'm
from
education
ecosystem
and
I'm
gonna
tell
you
a
bit
about
education
ecosystem
and
then
you
know
answer
any
questions.
Thank
you.
A
Education
ecosystem
is
a
project-based
learning
platform
for
experienced
developers.
We
basically
train
developers
on
how
to
build
products
using
real
projects.
We
are
a
peer-to-peer
platform,
we
have
like
very
experienced
developers
that
create
projects
and
then
other
developers
use
those
like
practical
approaches
to
kind
of
like
improve
their
skills.
On
this
slide,
you
can
see
some
examples
of
projects
that
were
built
on
education
ecosystem.
You
know,
and
these
are
cloud
native
projects
and
you
can
check
them
out
if
you
want
yeah.
A
A
Thank
you,
okay,
great.
So
some
questions
have
been
asked
like
what
are
some
of
my
top
recommendations
for
the
for
the
ci
cd
foundation.
I
would
say
number
one
is
to
focus
on
achieving
interoperability
between
you
know,
open
source
and
between
non-commercial
solutions,
because
it's
very
much
easier
for
all
this
source
groups.
A
For
all
this,
you
know
non-commercial
service
providers
to
kind
of
like
make
their
tools
make
their
their
tools
interoperable
right,
because
one
they
don't
have
any
economic
interest,
they're
not
doing
it
for
money
right.
They
are
just
providing
their
solutions
to
the
open
source
to
the
to
the
committee.
They
don't
have
any
like
intent
to
make
money.
A
So
it's
very
much
easier
to
kind
of
like
bring
all
these
groups
to
the
table
or
to
define
certain
common
standards
that
they
will
follow
when
they
are
kind
of,
like
you
know,
building
the
architecture
building
their
solution.
So
it's
very
easy
to
kind
of
like
define
a
set
of
common
standards
that
they
use
in
building
their
printers
or
their
new
releases
right.
So
that's
like
the
top
recommendation
when
it
comes
to
like
commercial
service
providers.
A
Their
commodore,
the
engine
might
look
different.
They
follow
certain
common
standards,
all
right
and
these
common
standards.
They
do
it
because
one
they
have
an
economic
benefit
right.
They
haven't
been
here.
They
have
like
a
user
benefit,
they
have
a
customer
benefit,
so
I
think
like
if
the
end
users,
that
means
companies
that
buy
you,
know
that
patches
this
cicd
solutions
right
if
those
com,
if
those
users
right
start
to
you
know,
require
that
if
I'm
gonna
buy
you,
you
know,
you
know,
I'm
gonna
buy
your
solution.
A
That
solution
must
be
compatible
with
this
understand
that
right.
So
it's
also
a
bit
of
like
education
of
the
buyer.
Companies
are
purchasing
solutions
that
they
start
to
require
that
the
cicd
solutions
that
they
buy
are
compatible
right
are
compatible
with,
like
certain
basic
industry
and
standards.
I
think
that
will
help
a
lot
it's
just
like.
If
somebody
buys
like
you
know,
if
you
buy
like
a
buy
any
electronic
device,
then
you
expect
it
to
have
an
adapter
that
works
with
other
laptops,
like
you
know,
so
this
is
how
I
see
it.
A
I
compare
it
like
you
know,
with
with
android
phones
right,
if
you
take
like
android
phones
and
if
all
android
phones
could
have
the
same
channel
technically,
all
android
phones
can
have
the
same
charger
right,
but
still
some
android
manufacturers.
You
know
four
manufacturers
still
try
to
make
their
charges
a
bit
different
right.
So
it's
a
very
similar
situation
and
I
think,
like
there
is
no
one
trick
pointing
and
fixing
it,
but
it
can
be
done
from
different
angles.
A
You
know
the
way
you
can
approach
it
from
for
conventional
solutions
is
going
to
be
very
different
than
from
the
open
source
solution.
The
open
cell
solution
is
like
the
lowest
hanging
fruits
right
because
one
they
don't
have
any
commercial
interest.
So
you
can.
The
ci
cd
foundation
can
approach
these
open
source.
You
know
groups
very
easy.
They
are
easily
accessible.
They
are
very
happy
to
kind
of
get
input
on.
A
So,
even
if
there's
a
javascript,
if
there's
a
ruby,
cica
tool,
they'll
they'll,
be
very
open
to
kind
of,
like
you
know,
have
common
defined
standards
that
all
the
different
open
source
groups
follow
right
because,
like
I
think,
if
the
open
source
groups
actually
have
common
standards
right
and
these
standards
are
embedded
in
the
c
in
this
ci
cd
solutions
that
they
release
right,
what
is
gonna
happen
is
the
end.
Users
are
gonna.
You
know
go
for
these
tools
right
instead
of
the
the
tools
that
don't
have
any
like
interoperability.
Why?
A
Because
they
will
realize
the
benefit
of
it
right
and
if
they
realize
the
benefit
of
it.
The
other
solutions
and
the
other
service
providers,
but
they
don't
have
interoperability,
are
gonna,
suffer
right
because,
if
any
end
user,
if
the
end
user
uses
the
solutions
that
is
interoperable
and
another
solution,
that's
not
interoperable.
They
will
see
the
difference.
They
will
see
the
benefit
immediately.
A
Between
the
two
right
and,
like
I
said
on
the
commercial
side,
is
gonna,
be
the
hardest
part
and
commercial
side
is
gonna,
be
one
showing
like
showing
them
clearly
and
quantifying
the
benefits
for
the
commercial
service
provider.
Why
he
should
make
you
know
his
tools
and
solutions,
interoperable
and
second,
providing
like
a
second
educating
the
buyers
of
this
service
of
this
commercial
solutions
to
like
request
to
demand
interoperability.
A
Let
me
just
go
on
the
second
question.
The
second
question
is:
are
there
concrete
deliverables
in
the
works
for
this
interoperability
isig?
So
the
group
just
started
the
sig
groups
just
started.
They
are
still
as
far
as
I
know,
they
are
still
working
out.
They
are
still
working
on
details
on
you
know
what
their
main
goals
are
going
to
be,
what
they
will
achieve.
They're
still
working
a
lot.
As
far
as
I
know,
there
are
no
concrete
deliverables
yet
because
they
are
still
in
the
beginning
stages
and
still
exploring
things.
A
A
Besides
the
general,
you
know
mission
that
they
have.
He
was
asking
more
like
whether
they
have
a
specific
defined.
You
know
metrics
and
goals
that
they're
trying
to
achieve
like
for
this
quarter
for
next
to
next
month
or
this
year.
I
I
think,
that's
what
he
is
asking
about.
Okay,
so
basically
the
other
questions
that
I
just
got
privately,
where
they
were
not
directly
with
interoper.
You
know
that
they're
not
directly
related
to
interoperability.
A
They
were
more
directly
related
to
ci,
and
you
know
what
is
ci,
what
is
the
difference
between
ci
and
what
is
continuous
integration?
What
is
continuous
delivery
and
continuous
deployment
yeah?
So
this
thing
is,
I
use
a
lot
and
continuous
just
to
keep
it
simple,
continuous
integration.
Just
imagine
that
you
have
a
source
code,
you
have
written
a
source
code
and
that
code
is
written
on
a
repo
somewhere
right
and
then
you
write
some
new
changes
to
the
code
or
you
write
a
new
feature.
A
You
write
a
new
code,
you
know
as
part
that
is
going
to
be
used
as
part
of
the
existing
source
code.
So
now
the
new
code,
you
have
written
or
changes
you
have
done
in
the
code.
You
need
to
kind
of
like
integrate
into
the
code
that
you
have
already
written,
so
that's
like
continuous
integration,
so
integrating
the
code
that
you
have
written
into
an
already
existing
code
right.
So
that's
what
you
can
call
continuous
integration
and
continuous
integration
triggers
every
time
a
build
right.
A
A
We're
going
to
have
like
a
new,
build
and
continuous
delivery
is
like
the
cool
that
we
have
just
integrated,
they're,
going
to
push
it
to
specific
environments,
you're
going
to
push
it
either
to
a
dev
environment,
they're,
going
to
push
it
to
either
a
staging
environment
or
you're
going
to
push
it
to
your
production
environment
right
and
this
is
where
continuous
deployment
content.
Continuous
deployment
is
the
idea
that
you
know
every
code
that
I
deploy.
You
know
from
development
to
staging.
It
gets
automatically
deployed
right
to
the
production
environment
right.
A
So,
ideally,
what
we
want
to
achieve
is,
like
you
know,
an
automated
pipeline,
where
changes
that
we
make
right,
that
we
make
to
the
master
branch,
the
production
microphone
that
they
get
automatically
deploy
and
that's
like
continuous
deployment
right
and
there
are
kind
of
like
different
tools
and
different.
You
know
service
providers
that
have
like
different
solutions
for
optimization
that
will
continuously
find.
There
are
other,
I
think,
the
other
presentations
that
go
more
in-depth
about.
A
You
know
continuous
integration,
continuous
deployment,
and
this
talk
is
more
about
interoperability
between
different
ci
cd
solutions.
Let
me
see
if
there's
any
other
question,
let
me
tell
you
right:
I
don't
see
any
other
question.
Let
me
see
the
other
question
that
I
helped
you
on
my
list
that
I
got
via
email
and
I
yeah
somebody
was
asking
if
I
was
part
of
the
cice
foundation.
A
No,
I'm
not
part
of
the
icd
foundation,
I'm
just
a
person
who
is
interested
in
interoperability
and
I'm
just
interested
in
cicv
the
icp
tools
and
I
have
been
following
ci
cd
intel
probability,
discussions
online
a
lot
and
I'm
gonna
see
how
I
can
contribute
somehow
to
the
sig.
You
know
team
anyone
any
way
I
can
help.
Anyway,
I
can
promote
awareness
about
about
interoperability.
A
I
think
a
lot
of
people,
don't
even
you
know,
think
about
interoperability
between
you
know
the
different
tools
and
solutions
they
use
because
they
don't
know
that
there's
another
way
of
working
right.
So
as
today,
a
lot
of
teams
they
build
like
their
own
solutions.
They
build
their
own
apps
to
make
their
different
tools
interoperable
and
that's
the
unproductive
idea
is
to
kind
of,
like
you
know,
work
in
a
new
environment
where
you
know
whether
you're
using
solution
a
solution
b.