►
From YouTube: Accelerating the Journey to Hybrid Cloud with Konveyor OpenShift Commons Gathering KubeCon NA
Description
Accelerating the Journey to Hybrid Cloud with Konveyor
Amith Singhee (IBM) | James Labocki (Red Hat)
OpenShift Commons Gathering KubeCon NA
November 17 2020
Modernizing applications to realize the benefits of hybrid cloud can be a daunting task. Konveyor is a community of people passionate about helping others modernize and migrate their applications to the hybrid cloud by building tools, best practices, and providing advice on how to break down monoliths, adopt containers, and embrace Kubernetes. In this presentation you will learn about the Konveyor community, it's tools, and see a live demonstration of a recently open sourced tool - move2kube - which can help customers migrate application from cloud foundry and swarm to Kubernetes.
468596 Accelerating the Journey to Hybrid Cloud with the Konveyor Community
A
So
today
we're
going
to
talk
about
a
bunch
of
different
projects
or
one
project
in
particular,
but
we
do
want
to
let
you
know
that
there
are
a
number
of
toolkits
and
web
services
that
red
hat
and
our
partners
in
the
community
are
working
on.
The
first
is
actually
migration
toolkit
for
applications,
which
helps
you
break
down
your
applications
specifically
java
applications
and
helps
you
understand
how
you
can
modernize
them,
so
this
would
include
migrating
from
something
like
spring
boot
to
quarkus
and
modernizing
your
applications
to
see
if
they
can
run
on
openshift.
A
Another
toolkit
we're
working
on
is
called
migration
toolkit
for
containers.
This
is
a
toolkit
that
helps
you
migrate,
your
applications
between
different
kubernetes
clusters.
In
this
case,
specifically,
it
was
designed
to
help
customers
move
between
openshift
version,
3
and
openshift
version
4.,
so
it
will
migrate,
your
namespaces
your
objects
and
your
persistent
data.
A
And
while
this
is
an
officially
supported
toolkit
from
red
hat,
we're
excited
that
it's
been
open,
sourced
and
really
they're
going
to
talk
to
you
about
how
it
can
help.
You
increase
the
efficiency
of
moving
from
from
swarm
and
from
cloud
foundry
to
a
kubernetes
environment
and
how
it
was
developed
and
and
they'll
actually
give
you
a
demonstration
of
that
today.
A
So
really,
what's
important
here
is
how
not
only
just
the
toolkits
that
we're
developing,
but
how
we're
going
about
developing
this
in
the
red
hat
fashion.
We
are
we've
open
sourced
all
these
tools
and
we
are
actually
actively
developing
them
in
a
community
called
the
conveyor
community
and
the
conveyor
community
is
really
red.
Hats
really
attempt
to
start
building
a
catalyzed
community
around
the
tools,
best
practices
for
how
you
break
down
monoliths,
how
you
adopt
containers,
how
you
embrace
kubernetes.
So
we're
excited
about
this.
A
B
B
The
move
to
give
starts
off
with
any
of
these
source
platforms,
and-
and
the
first
thing
it
does-
is,
discovers
your
deployment
specification
on
the
source
platform.
So
if
you've
got
containers
running
on
docker
swarm
or
an
application
running
on
cloud,
foundry
you'll
go
and
discover
everything.
That's
needed
to
be
to
specify
that
that
particular
deployment.
C
B
It
provides
three
different
mechanisms
for
that
containerization.
You
can
choose
a
docker
file
based
containerization
approach,
so
you
actually
get
a
docker
file
out
of
the
process.
You
can
use
cloud
native,
build
packs
if
you're
coming
from
something
like
cloud
foundry
or
you
can
use
s2i
source
to
image,
to
go
directly
from
your
source
code
into
container
images
running
on
openshift
after
translating
into
a
kubernetes
model.
Move
to
cube
then
adds
in
the
best
practices
and
features
that
are
relevant
for
kubernetes
that
were
not
relevant
in
the
source.
B
It
can
generate
an
operator
to
deploy
that
application
easily
and
it's
starting
to
support
certain
k-native
capabilities
in
particular
k
native
serving
and
the
team
has
also
started,
generating
some
artifacts.
How
to
move
to
cube
for
tecton
pipelines
overall
end
to
end
move
to
cube,
really
tries
to
provide
you
an
integrated
tool
that
performs
discovery
of
your
deployment,
spec
containerizes
them,
where
relevant
translates
over
to
kubernetes
and
then
optimizes
and
customizes
all
the
way
to
a
set
of
deployment.
Artifacts
that
you
can
use.
B
C
C
Motor
cube
can
cater
to
very
complex
scenarios
where
you
have
multitudes
of
applications
with
different
characteristics
or
you
can
handle
the
simpler
use.
Cases
too,
and
motor
cube
has
a
capability
to
be
integrated
without
a
human
interaction
or
with
a
human
interaction.
Let's
see
how
each
of
these
flows
can
be
embodied
in
motor
cube,
motor
cube
can
be
consumed
in
two
different
ways:
one
as
a
command
line
tool
or
as
a
web
interface
as
a
command
line
tool.
You
can
get
it
installed
using
the
curl
command
that
you
see
here.
C
C
C
C
It
will
then
interact
with
you
and
create
all
the
target
artifacts
that
are
necessary
for
deploying
that
application,
which
you
can
then
put
it
into
your
csd
pipelines
or
directly
deploy
to
your
cluster
for
more
complex
scenarios.
Motor
cube
can
be
consumed
as
a
two-step
process
or
a
three-step
process
in
a
two-step
process.
First,
you
do
the
plan,
where
you
point
your
motorcube
to
the
source
folder,
which
analyzes
the
source
folders
and
give
it
give
you
a
plan
of
the
different
services.
It's
identified
that
and
how
it
is
planning
to
translate.
C
You
can
then
edit
it
and
give
hints
to
motorcube
on
doing
a
better
translation.
Once
you
have
the
plan
ready,
you
can
invoke
the
translate
phase,
which
will
then
create
all
the
target
artifacts
for
you,
and
then
there
is
an
optional
step.
If
you
want
to
analyze
all
the
runtime
artifacts,
you
can
do
the
moto
cube
collect
and
it
will
automatically
look
at
all
your
runtime
instances
that
are
in
context
in
your
terminal.
C
For
example,
if
you
have
a
cloud
foundry
instance,
it
will
get
all
the
information
of
all
the
build
packs
and
also
the
information
on
the
kubernetes
clusters
that
are
there.
We
look
at
what
information
it
collects
in
a
short
while,
but
this
information
can
then
be
put
as
part
of
the
source
folder
that
you
point
to
in
the
plant
phase,
which
will
then
look
at
all
of
them
together
and
guide
you
through
the
process
of
using
them
as
part
of
the
plan,
and
also
the
translate.
C
C
The
samples
folder,
as
you
can
see,
has
multiple
different
kinds
of
applications
in
this
we'll
go
through
a
few
of
them
to
look
at
the
major
capabilities
of
motor
cube.
The
first
one
that
we
are
going
to
look
at
is
a
e
to
e
flow,
where
there
are
two
applications:
a
golang
application
and
a
nodejs
application.
This
could
be
a
cloud
foundry
application
or
it
could
be
a
normal
application.
You
are
deployed
to
your
vms.
C
So
now
it
says
that
it
has
identified
two
services
and
it's
asking
they
want
to
translate
all
of
them,
and
then
it
says
that
okay
or
in
the
both
the
services
I
can
translate
using
multiple
containerization
techniques,
it
might
be
docker
file,
sdy
or
cloud
native
buildback.
So
in
this
case,
let's
just
go
with
a
docker
file
and
then
it's
saying
what
do
you
want
to
create?
Do
you
want
to
create
a
yaml
files,
or
do
you
want
to
create
head
charts
or
k
native
artifacts?
C
C
May
it
be
ibm
kubernetes
or
openshift
or
azure,
aws
or
gcp,
or
you
can
have
your
own
custom
ones,
which
you
will
look
at
shortly
and
then
it's
asking
what
are
the
services
you
want
to
expose
externally?
So
you
can
select
whatever
you
want
to
expose
externally.
Then
it's
asking
where
your
registry
is
I'm
just
going
to
point
to
the
registry
us.icr.io
and
then
it's
asking
the
namespace
in
which
you
want
to
deploy,
I'm
going
to
do
to
m2k
demo
and
then
I'm
going
to
specify
my
pull
secret.
C
Once
I
mention
that
it's
asking
for
information
on
your
secret
by
default,
if
I
don't
give
any
secret,
it
will
create
http
ingress
endpoint.
If
I
give
a
secret,
it
will
create
a
https
endpoint
for
us,
so
I'm
going
to
go
with
defaults
for
everything
else,
including
the
csd
pipeline,
and
now
it
has
created
the
artifacts
for
you
in
the
folder
called
my
project,
since
we
did
not
override
the
default
project
name.
C
So,
let's
see,
what's
inside
this,
my
project
folder,
it
has
created
multiple
artifacts,
there's
a
readme
which
does
guides
you
on
the
next
steps.
But
essentially
there
are
many
scripts
in
the
base
level
like
build
images,
copy
sources
and
even
a
doc
compose
file
and
a
few
others
which
we
can
use
to
install
in.
C
In
addition
to
that,
it
has
created
a
sample
operator
for
you
and
which
is
a
helm
based
operator.
Also,
it
has
created
a
ci
cd
pipeline
for
you.
This
cicd
pipeline
uses
this
containerization
script.
Since
we
mentioned
to
move
to
cube
to
create
docker
files
for
us,
it
has
created
a
docker
files
and
scripts
that
can
build
the
images
using
the
docker
files.
C
So
the
first
thing
we
will
do
is
go
into
the
folder
and
look
at
other
artifacts.
The
first
thing
that
we
need
to
do
is
to
copy
the
sources,
so
the
containerization
scripts
that
you
saw
are
all
docker
files
and
stuff,
but
it
requires
a
source
code
for
it
to
be
able
to
build.
So
let's
do
the
copy
sources
and
then
point
the
source
to
the
folder
that
we
gave
as
input
to
motor
cube.
In
this
case
it's
e
to
e
flow,
and
once
we
do
that
the
files
are
copied.
C
C
So
here
we
are
going
to
do
the
helm,
install
and,
let's
see
what
happens
so
now,
it
is
trying
to
see
whether
there
is
a
project
by
the
name.
My
project
access,
if
not
it's
trying
to
create
one
and
it's
installing
to
the
cluster
we
just
saw
in
the
chrome,
and
it
has
exposed
the
application
in
the
form
of
this
ingress.
C
C
C
One
of
the
more
common
use
cases
is
a
docker
compose.
When
you
develop
your
application,
you
generally
create
a
docker
compose
file
and
then
you
decide
to
deploy
to
kubernetes,
and
then
you
have
to
rewrite
all
of
them
into
kubernetes.
In
this
case,
let's
try
to
take
the
docker
compose
file
and
then
deploy
it
to
kubernetes.
For
that
we
are
going
to
use
this
sample
over
here,
which
is
a
dockercompose.ml
file
which
has
a
few
services.
C
C
Now
it's
going
through
the
files
and
trying
to
help
you
with
the
translation
process.
Let's
see
what
it
comes
up
with.
What
are
the
services
it
has
identified?
It
has
found
three
services,
apa
service,
a
redis
service
and
a
web
service.
So
it's
asking
whether
to
translate
all
three
of
them,
and
it's
saying
that
okay,
these
are
containerized
ones,
the
images
excess.
So
you
can
reuse
them.
Do
you
want
to
reuse
the
container
images?
I
say
yes
and
then
I
create
okay,
it's
asking
whether
you
want
help
chart
or
direct
pianos
or
knee
to
artifacts.
C
It
will
create
the
my
projects
folder
again,
let's
look
at
what
is
there
in
the
my
projects
folder
now
now,
since
this
is
a
pre-containerization
environment,
the
container
files
are
already
there
and
only
the
kubernetes
artifacts
are
created.
It
has
created
deployment
artifact
for
you,
your
service
yaml,
the
ingress
and
for
the
different
services.
C
The
next
flow
that
we
are
going
to
see
is
a
combination
of
multiple
language
stacks
with
java
go
python
and
stuff
which
needs
to
be
containerized
and
then
put
into
kubernetes.
Let's
see
a
quick
example
of
that
for
that
what
we
are
going
to
do
is
to
we
are
going
to
take
this
language
platforms
folder,
which
has
multiple
applications
which
are
going
to
be
translated.
C
So
for
this
we
are
going
to
use
a
two-step
approach.
The
first
is
a
plant
phase
and
for
plan.
We
are
going
to
input
this
as
a
folder,
and
once
I
give
this
language
platforms,
it's
going
to
go
through
each
and
every
file
in
there
and
combine
them
and
trying
to
make
sense
out
of
them
and
then
come
up
with
a
plan
for
you,
which
you
can
then
curate
in
addition
to
the
default,
integrated
containerization
techniques.
Motorcube
also
supports
extending
the
contentization
techniques
in
this
source.
C
Folder
it
there
is
an
extended
containerization
techniques
that
is
being
part
of
the
source
folder.
Here
you
see
this
java
gradle,
where
there
is
a
m2kdf
direct
and
then
a
docker
template
is
docker
file.
So
motorcube
can
understand
this.
Folder
and
treat
it
as
one
of
the
containerization
techniques.
It
will
use
this
condensation
technique
to
containerize
the
different
folders
wherever
it
is
feasible.
We
will
see
in
this
example
how
that
is
going
to
work
out,
so
it
has
created
a
m2k.plan
for
us,
which
is
essentially
a
yaml
file.
C
So
here
is
a
file
that
we
are
going
to
see,
so
it
has
multitudes
of
options,
it
has
different
services
and
the
different
information
it
has
collected
and
the
different
ways
in
which
that
app
application
can
be
containerized
to
help
us
with
the
condensation
process.
What
we
are
going
to
do
is
to
use
the
translate
command
to
take
us
through
the
curation
of
the
plant.
For
that
I
am
just
going
to
do
a
translate
minus
c,
which
is
the
curate
for
the
plan,
so
it
asks
what
are
the
folders
that
needs
to
be
containerized.
C
In
this
case.
These
are
the
applications.
I
need
to
containerize
so
asking
me
options
and
it's
asking
what
are
the
condensation
techniques
you
want
to
support
and
for
each
of
the
folders?
Now
it's
asking
for
each
of
the
folders.
I
know
different
ways
of
contacting
containerization,
which
one
do
you
want
to
use,
for
example,
for
nodejs
I
can
create
a
docker
file
for
php.
I
can,
for
example,
choose
s2y
for
python.
I
can
use
cloud
native
build
pack
and
then
for
ruby.
C
I
can
use
a
docker
file
and
for
golang
I
can
use
joker
file
for
java
gradle.
I
can
use
a
docker
file
now
when
I
choose
docker
file
based
condensation
for
java
credit.
It
is
giving
me
two
different
ways
in
which
it
can
create
a
new
docker
file.
For
us,
one
is
using
the
inbuilt
technique,
m2k
asset,
slash,
docker
file,
slash
javagrader,
or
it's
pointing
to
a
folder
in
our
source,
which
is
java,
gradient
folder
that
you
see
here.
So
it
has
automatically
used
this
to
try
and
containerize
the
folder.
C
C
Once
it's
done,
our
contentization
scripts
are
all
ready.
So,
let's
look
at
the
output,
so
here,
if
you
notice
what
it
has
done
is
it
has
created
the
yamls
for
us
for
each
of
the
folders
and
the
services
is
identified.
It
has
created
the
deployment
artifacts,
the
service
artifacts
and
the
ingress
as
required,
and
also
created
a
simple
docker
compose
file
for
you,
so
that
if
you
want
to
test
the
images
locally,
you
can
do
that.
C
C
For
example,
1.9
version
of
kubernetes
has
a
few
artifacts
which
are
in
b1
beta
1
version,
for
example
like
deployment,
whereas
1.17
might
support
v1
version
of
deployment
and
when
you
try
to
deploy
the
v1
beta
1
on
your
cluster,
which
supports
only
v1,
you
will
get
an
error.
Moto
cube
can
help
you
with
that.
In
addition
to
that,
it
can
also
help
you
change
flavors.
Let's
say
you
want
to
use
the
best
features
of
openshift.
C
C
There
are
some
api
applications
with
the
deployment
as
service
and
your
radius
with
the
deployment
and
service,
and
then
your
ingress
deployment
and
service.
We
are
going
to
use
a
single
step
approach
to
do
this
translation
before
that
from
the
previous
flow.
Let's
remove
the
plan
file
which
was
created
now.
Let's
do
motor
cube,
translate
minus
s
and
then
point
to
the
samples.
C
So
now
it's
going
through
each
under
every
kubernetes
artifact
and
trying
to
understand
what
is
there
and
what
needs
to
be
translated.
It
has
identified
three
services:
let's
go
with
all
three
of
them:
reuse
them
and,
let's
still
say,
we
want
a
health
shot
out
of
this,
and
then
we
want
to
target
openshift
and
what
services
we
want
to
expose.
C
Let's
expose
the
web
hello
and
let's
go
with
the
defaults
for
everything
else,
and
once
it's
all
done,
it
has
created
a
my
project
folder,
let's
look
at
what's
in
there,
so
it
has
created
a
hem
shot
for
us
which
has
a
deployment
config
image
stream
and
sir
service
yama.
So
it
was-
and
it
has
also
created
a
root
instead
of
a
class
because
we
are
targeting
an
openshift
cluster.
C
So
with
a
very
simple
approach,
you
can
move
between
clusters
quite
easily
with
the
help
of
motor
cube.
The
next
floor
we
are
going
to
look
at
is
a
cloud
foundry
translation.
Here
we
are
going
to
use
the
sample
called
cloud
foundry
over
here.
There's
multiple
artifacts,
as
you
can
see
over
here.
Let's
start
motor
cube
plan
phase
on
it.
Before
that
we
are
going
to
use
a
three
stage
process.
C
C
C
So
this
is
a
runtime
information
of
the
particular
application
that
you
are
trying
to
translate.
Similarly,
it
has
also
collected
some
target
cluster
information.
Since
kubernetes
cluster
was
in
context,
it
was
able
to
collect
information
about
the
storage
classes,
supported
by
it,
the
apa
versions
and
also
the
priority
between
them.
You
can
always
edit
it
to
give
hints
to
motor
cube
on
which
api
versions
to
support.
C
C
Phase
for
while
it
when
we
start
the
plan,
it's
going
to
combine
the
runtime
artifacts
with
the
source,
artifacts
and
all
the
information
that
it
can
understand
out
of
it
and
going
to
come
up
with
a
plan
for
us.
Let's
look
at
what
is
in
the
plan,
so
it
has
created
a
plan
for
us.
So
let's
get
that
plan.
C
So
in
the
plan
here
you
can
see
some
information.
There
are
different
options
and
one
of
the
options
is
to
containerize
the
application
using
cloud
native
buildback,
and
it's
saying
I
can
cut
analyze
it
using
two
different
ways
where
cloud
foundry,
image
or
google
image,
and
then
it
is
saying
it
can
use
the
source
artifacts
and
also
the
runtime
information
and
combine
all
of
them
and
do
the
translation.
C
C
So
as
soon
as
I
select
translate,
let's
say
I'm
interested
only
in
cloud
native
buildback.
There
are
two
images
for
on
which
I
can
target
and
then
what
kind
of
artifacts
are
required?
What
kind
is
cluster
here?
You
can
see
there
is
a
new
cluster
type
that
is
listed
at
cluster.yaml,
which
is
your
custom
cluster,
which
that
you
have
collected
once
you
do
that
it
can
create
all
the
artifacts
for
you
in
the
my
project.
So
let's
look
at
what
is
that
so
here
it
has
created
all
the
deployment
conf.
C
Similar
to
all
the
command
line
flows,
we
can
also
use
the
web
ui
for
do
the
translation.
It
has
all
the
capabilities
that
we
saw
in
the
command
line
tool.
For
that
all
you
need
to
do
is
to
head
over
to
the
moto
cube
ui
repository
clone
it
and
do
a
docker
compose
app.
So
let
me
take
you
through
the
simple
flow
of
that
I'm
going
to
go
to
the
motoki
view
by
repository
and
then
I'm
going
to
use
this
docker
compose
yaml
and
translate
it.
C
As
you
can
see,
there
is
a
pre-existing
project
called
demo.
This
is
because
there
is
already
an
existing
workspace
folder
into
which
there
was
an
pre-existing
project,
so
you
can
just
start
it
in
that
same
folder,
and
you
will
see
all
your
previous
projects
listed
in
addition
to
that,
let's
create
a
new
project
called
cubecon
and
let's
go
to
the
details
of
it
and
let's
upload
our
first
asset.
The
first
asset
that
we
are
going
to
upload
is
the
docker
compose
file
that
we
got
there.
C
It
is
in
the
folder
called
ui
local
workflow
and
we
are
going
to
upload
a
zipped
version
of
that
file
and
as
soon
as
we
upload,
the
file
is
available
there
and
we
create
a
plan
and
it
is
going
in
the
background
trying
to
create
the
plan
for
the
docker
compose
file.
We
just
selected
once
a
plan
is
available.
We
can
see
the
different
services
there
for
now.
Let's
look
at
a
previous
project
for
which
we
had
already
created
the
plan.
C
If
there
are
more
services,
it
will
be
listed
that
and
which
we
can
again
curate,
and
once
that
is
done,
we
can
go
to
the
target,
artifacts
tab
and
click
on
translate
and
go
through
the
same
qa
flow
that
we
just
went
through
from
the
command
line.
All
the
features
that
we
saw
in
the
command
line
tool
are
available
through
the
ui
tool,
and
this
we
can
download
with
as
a
zip
file,
that's
a
quick
overview
of
motocube's
capabilities
and
the
demo
flows.
C
Now,
let's
look
at
the
different
requirements
for
motor
cube
depending
on
the
source
platforms.
It
can
gracefully
scale
depending
on
the
data
available
if
there
are
manifest
files
alone
available
or
source
code
is
additionally
available
or
runtime
instances
available
in
case
of
cloud
foundry
and
then
create
the
right
artifacts,
depending
on
what
is
available.
C
Similarly,
for
docker
compose
to,
depending
on
the
docker
compose
files
available
or
if
source
code
is
available,
it
can
create
the
right
destination
artifacts
we
have,
there
is
only
source
applications
where
which
needs
to
be
containerized.
Motor
cube
can
handle
that
too
and
can
create
the
right
artifacts
with
that.
I
would
like
to
hand
it
over
to
amit
for
a
quick
overview
of
s
case
study.
We
had
with
motor
cube.
B
B
It
had
with
custom
containers
written
in
node.js,
and
it
had
some
middleware
containers,
for
example
mongodb
and
data
power,
and
we
wanted
to
actually
do
the
translation
over
to
openshift,
get
the
application
running
on
openshift
and
then
compare
that
with
the
process
where
everything
was
done
manually
and
to
prove
to
ourselves
whether
we
actually
do
see
productivity
gains.
So
the
table
here
actually
shows
you
some
of
the
results.
B
It
shows
six
task
groups
ranging
from
discovering
relevant
assets,
translating
artifacts
that
are
easy
to
translate
the
ones
that
are
more
complex
to
translate,
adding
in
features
and
best
practices
for
open
shift,
customizing
and
then
right
sizing
for
the
configuration
and
deploy.
Now.
In
this
case,
the
manual
activity
was
actually
an
estimate
and
the
move
to
cube
activity
was
actually
done
in
practice
and
we
saw
a
very
nice
9x
productivity
gain
for
this
roughly
100
container
scenario.
B
Of
course,
this
can
go
up
and
down
a
bit
depending
on
your
source
platform
and
the
skills
of
the
user
and
and
specific
scenario
of
the
user,
but
this
was
a
great
proof
point
that
really
convinced
us
to
go
further
and
build
this
tool
out
further
for
a
variety
of
other
platforms,
and
this
is
our
closing
slide.
Thank
you
for
your
time.
Listening
to
us
here,
you
see
various
links
out
in
the
community,
all
housed
within
conveyor.