►
Description
Guest Speaker: Zohaib Khan, Practice Lead and Manager PaaS Community of Practice at Red Hat
A
A
Well,
hello
and
welcome
everybody
again
to
another
OpenShift
Commons
green
tea
and
I'm
really
pleased
today
to
have,
though
ed
Khan
from
Red
Hat
he's
the
classic
practice
lead
for
application,
migration
and
modernization,
which
is
a
big
title
for
someone
who
is
really
brought
a
lot
of
hands-on
experience
with
customers
and
helping
them
on
tunicate
deployments
at
Oulton
shift
work
and
asking
here:
can
you
give
his
thoughts
on
moving
from
legacy
to
cloud
native
and
he
sort
of
identified
three
patterns
of
modernizing
applications?
Then
I
thought
were
really
insightful.
A
B
You
Diane
hi
everyone,
as
Diane
said
I,
am
the
practice,
lead
and
Red
Hat
consulting
for
application,
migration
and
modernization,
and
today
I'm
going
to
be
talking
about
the
journey
from
legacy
to
cloud
native,
especially
when
you
have
a
large
portfolio
of
applications
and
how
we
can
actually
navigate
through
that,
and
you
know,
modernize
the
the
portfolio.
There
are
three
patterns
that
we
have
identified
by
working
with
various
customers
in
the
field
and
I'm
happy
to
present
on
this
topic
for
you.
B
So
let's
get
started
so
first,
just
a
little
bit
of
background
with
respect
to
the
adoption
of
emerging
technologies
by
enterprise
customers.
This
is
from
the
enterprise
IT
adoption,
which
they
track,
how
enterprises
actually
adopt
emerging
technologies.
So
one
of
the
key
trends
that
they
have
pointed
out
was
enterprises
actually
are
towards
the
maturity
cycle
of
the
technology
option
in
in
in
in
most
of
the
cases,
reason
is
that
you
know
there
are
company.
There
are
companies
who
experiment
with
the
technology,
but
most
of
the
enterprise
IT
wants
to
adopt
technologies.
B
B
You
know
the
before
starters,
either
so,
typically
the
dynamics
in
that
variety,
the
way
it
works
is
that
they
are
mostly
aligned
with
the
business
mission
and
IT
is
generally
considered
as
a
cost
Center,
which
is
an
enabler
for
most
emerging
tech.
Our
Y
is
usually
unknown
in
the
beginning,
so
you
know,
if
you
take
out
Facebook
Google
Yahoo
and
you
know
Amazon,
for
example,
the
rest
of
the
companies
usually
want
to
adopt.
You
know
something
you
know
when
they
know
pretty
much.
B
What
are
the
use
cases
that
they
can
address
with
them,
and
what
is
the
clear
are
why
so
you
know
majority
of
the
times
you
know
these
shops
adopt.
You
know
emerging
tech
at
a
significant
maturity
of
that.
If
not
you
know
towards
the
end,
there
are
a
few
other
things
that
are
also
critical
as
part
of
the
enterprise
IT.
B
You
know
organization,
there
are
skill,
sets
that
people
have
that
they
want
to
continue
to
use
and
continue
to
apply,
and
we
have
seen
that
whenever
we
talk
to
the
customers,
they
would
want
to
do
the
same
thing
even
in
the
cloud
room.
You
know
want
to
use
the
same
languages
same
procedures,
but
obviously
with
the
new
flavor.
There
are
existing
processes
that
you
know
add
to
organizational
inertia
and
obviously
there
are
existing
systems
that
these
companies
have,
that
you
know
sort
of
you
know
introduce
inertia
in
terms
of
you
know
momentum.
B
B
You
know
when
they,
the
IT
shops,
where
you
know,
if
you
look
at
the
amount
of
resources
you
know
and
money
they
have
generally,
the
70%
of
that
is
allocated
towards
maintenance,
where
30%
is
towards
innovation
or
new
things.
This
is
a
generalization.
Obviously,
we
have
seen
numbers
as
80/20
90/10,
but
we
haven't
seen.
50/50
reason
is
that
most
of
the
IT
span
generally
goes
towards
elas.
You
know
towards
maintaining
the
current
systems,
keeping
the
lights
on
that
kind
of
stuff.
So
you
know
this
equation.
B
Sort
of
tells
us
that
you
know
the
most
of
the
money
and
resources
are
dedicated
to
keeping
the
status
quo
and
one
of
the
things
that
prompted
me
to
think
about.
This
is
what,
if
we
can
help
the
customer
change
this
equation
in
such
a
way
that,
even
if
we
move
the
needle,
maybe
10
percent
towards
the
innovation,
those
are
real
resources,
real
money.
You
know
real
stuff
that
customers
can
use
to
develop
new
processes
to
develop
new
systems
or
enhance
new
systems.
B
Take
care
of
technical
that
and
sort
of
start
look
looking
at
modernization
as
a
real
thing
in
order
to
improve
the
productivity
you
know
of
their
shops,
and
that
was
one
of
the
key
drivers
of
introducing
modernization
at
that
scale
for
the
entire
IT
portfolio.
I'm,
going
to
briefly
talk
about
this,
where
we
talk
about
CIOs
and
CTOs,
their
main
challenges
are
among
many.
B
You
know
how
do
they
rebalance
and
maintain
innovation
so,
based
on
the
previous
slide
that
I
mentioned,
you
know
this
is
obviously
in
a
struggle
also
to
avoid
vendor
lock-in
and
in
the
licensing
model.
So
you
know
granted
that
you
a
piece
of
software
10
years
ago,
and
now
it's
come
out
or
dies,
but
you're
still
logged
into
a
proprietary
vendor.
You
know
there's
no
reason
for
you
to
not
move
to
open-source
equivalent.
You
know,
after
a
long
period
of
time,
when
you've
already
paid
a
lot
to
you
know.
B
You
cannot
necessarily
take
your
heavy
systems,
you
know
in
in
the
cloud
you
know
if
you
want
to
go
more
agile
and
also
you
know,
adopt
new
processes
and
technology.
So
these
are
the
key
challenges
that
CIOs
and
CTOs
face
today.
But
the
underlying
theme
of
all
this
is
how
do
they
actually
rally
their
troops
and
you
know,
put
a
structure
plan
in
place
to
modernize
their
portfolio
that
will
allow
them
to
realize
these.
These
challenges,
you
know
as
all
these
challenges,
so
you
know
the.
Why
should
we
even
care
about
modernization?
B
You
know
what's
what's
what's
really
the
value
of
it?
First
of
all,
you
know
modernization
enables
experimental
approach
to
product
development.
This
has
long
been
a
challenge
in
a
typical
enterprise.
Where
we
see
the
typical
release
cycles
are
anywhere
from
six
months
to
nine
months.
We
generally
see
one
release
a
year,
maybe
two
for
a
large
portfolio
of
systems
and
they
generally
go
through
a
very
large
funnel
of
you
know,
synchronization,
where
a
lot
of
environment
is
locked
down,
for
you
know
a
single
release
of
multiple
systems.
B
Most
companies
are
not
even
ready,
so
one
of
the
key
benefits
of
modernization
is
that
it
allows
them.
It
enables
them
to
not
only
think
in
that
direction,
but
also
realize
that
potential
there's.
It
also
has
a
good
side
effect
of
creating
high-performance
teams
that
improve
the
quality
of
work,
and
you
know,
frankly,
people
like
to
do
this
kind
of
stuff
that
helps
in
terms
of
recruiting
and
retaining.
You
know,
good
talent
and,
generally,
you
know,
drives
the
overall
improvement
in
quality.
Some
of
the
key
things
that
modernization
drives
are
you
know
frequent
deployments.
B
The
rate
of
frequent
deployment
goes
up
if
there's
a
faster
time
to
recovery
from
failures.
So
if,
let's
say
in
a
typical
six
months,
release
cycle,
if
something
critical
goes
down
or
does
not
work
out,
and
we
realize
as
part
of
production
deployment,
then
usually
the
entire
release
is
backed
out.
So
if
this
touches
1015,
you
know
7/8
time,
whatever
systems,
all
those
systems
are
going
to
be
impacted
one
way
or
the
another
another.
B
Whereas
when
we
look
at
modernization,
it
gives
you
a
framework
I'm
going
to
show
you
how
it
gives
you
a
framework
in
terms
of
you
know,
to
allow
you
to
isolate
your
failures
and
be
able
to
recover
from
it
very
easily
also,
it
leads
to
shorter
lead
times.
So
if
the
business
comes
up
with
an
idea
that
they
want
to
get
out
quickly,
they
really
don't
have
to
wait
for
six
months
and
then
also
lowers
the
failure
rate
change.
So
these
are
some
of
the
key
benefits
that
why
we
should
consider
modernization.
B
There
are
organizational
aspects
to
it,
so
you
know
it's
not
gonna
be
just
technology
enable,
but
the
whole
idea
is
that
we
use
technology
as
the
enabler
and
put
a
structure
in
place
that
would
allow
organizations
to
actually
do
it
in
a
more
structured
fashion.
Oh
this
is
one
of
my
favorite
slides
that
I
talk
about
with
my
customers.
So
if
you
go
on
the
Left
we
look
at,
you
know
we
started
with
application
lifetimes,
where
it
tooks
months
or
even
years,
to
develop
the
systems
and
years
and
decades
to
run
them
so
those
systems.
B
You
know,
obviously
we
are
talking
about
systems
that
have
been
developed
20-25
years
ago
or
even
longer,
and
the
lifecycle
of
those
systems
were
very
long.
You
know
before
they
were
considered
for
any
type
of
significant
change
as
we
move
forward.
You
know
we
have
gone
from
you
know,
years
and
months
of
development
to
weeks
and
months
of
development
and
systems
now
run
from
months
to
years
before
they
are
considered
for
a
big
change
and
the
latest
trend
is
you
know
it.
The
business
wants
everything
out
in
days
in
a
matter
of
weeks.
B
Even
like
you
know
three
three
weeks,
four
weeks,
let's
say,
and
then
you
know
the
the
the
system
is
out
there.
You
know
we're
talking
about
apps
iPhone
apps.
You
know
mobile
apps
integration
points.
You
know
web
apps,
for
example,
that
real
customers
are
using
and
suddenly
we
want
to
introduce
new
changes
as
a
result
of
that
in
a
matter
of
weeks.
Even
so,
these
are
the
dynamics
that
that
exists
today
and
inherently
they
are
pushing
us
to
look
at
deeply
across
development
processes,
application,
architectures
deployment,
packaging
and
application
infrastructure.
B
You
know,
as
we
made
our
transition
from
you
know.
Decades
to
years
we
have
changed
a
few
things.
We
have
an
adaptive
virtual
servers.
For
example,
data
centers
are
still
around.
We
have
moved
from
monolithic
to
entir
systems
and
we
most
organizations
are
either
in
the
process
or
have
a
flavor
of
agile
now
in
place.
But
as
we
continue
to
push
the
envelope-
and
you
know
when
the
demand
is
increasing,
so
much
that
you
know,
we
need
to
get
something
out
the
door
in
a
matter
of
days.
B
We
need
to
look
at
you
know
what
processes
are
going
to
enable
that
what
application
architectures
are
the
ones
that
align
with
that
kind
of
approach
and
also
similarly,
packaging
and
the
application
infrastructure.
This
is
not
meant
to
be
all
in
or
nothing
kind
of
proposition.
So,
for
example,
we
still
have
customers
that
are
deploying
monolithic
applications
on
virtual
servers.
That
is
still
possible.
B
You
know
through
that
journey,
so
let
me
give
you
an
example
of
I
told
you
about
how
the
typical
release
cycle
work
so
over
here
we're
looking
at
monolithic
release
cycles
and
generally
you
know,
we
have
a
release
plan
that
governs
multiple
systems,
and
part
of
that
is
you
know
when
the
release
plan
is
scheduled
for
analysis
and
the
you
know,
development.
We
have
several
teams
that
go
in
parallel
and
start
the
development
effort.
You
know
if
this
is
one
system
or
multiple
systems.
B
You
know
the
tendency
is
that
we
can
staff
one
or
more
developers
to
make
modifications
to
one
or
more
systems.
At
the
same
time,
you
know,
given
that
this
release
plan
touches
all
these
components,
but
then
something
weird
happens,
which
is
these
everything
has
to
be
synchronized
for
integration,
testing,
QA
testing
and
UAT
test,
which
means
that
there
are
environments
that
are
locked
down
nobody's
allowed
to
make
a
change,
and
things
have
to
be
synchronized
and
sequenced
very
carefully.
B
B
Now,
let's
say
if
you
find
bugs,
if
you
find
bugs
and
as
part
of
the
development,
that's
the
most
cheapest
to
fix
in
terms
of
time
and
money.
But
if
you
find
bugs
and
integration
QA
or
let's
say
UAT,
which
is
usually
they'll,
ask
tap,
then
you
know
it
has
to
go
back
to
the
developers
and
get
it
fixed,
but
there's
a
cost
associated
with
if
the
cost
of
time
cost
in
terms
of
environment
costly
in
terms
of
people's
time,
so
the
cost
actually
slightly
increases.
If
the
bugs
are
found.
B
Contrast
that
with
a
micro-services
mase
release
cycle,
obviously
I'm
making
a
lot
of
generalizations
here.
But
the
idea
over
here
is
to
present
that
when
we
talk
about,
you
know
modernization
and
going
cloud
native.
One
of
the
key
things
that
we
consider
is
to
have
micro
services
based
architectures
and
what
they
allow
us
to
do
is
something
very
you
know
something
very
phenomenal
which
is
called
independent
deployability.
So,
typically,
the
systems
can
go,
be
governed
with
their
own
individual
release
plans,
and
so
that's
number
one.
B
So
we
basically
decouple
you
know
the
release
releases
of
systems
and
you
know
take
out
the
unnecessary
dependency
so
that
each
system
can
actually
march
at
their
own
pace,
granted
that
they
have
to
implement.
You
know
similar
type
of
mandates
from
the
business
or
new
functionality,
but
the
release
can
be
decoupled,
so
there's
no
need
to
synchronize
at
the
release
planning
side
side
on
the
development
side.
You
know,
there's
a
plethora
of
options
to
choose
the
development
languages,
so
some
systems
can
continue
to
remain
in
Java.
B
If
that's
the
key
technology,
others
can
be,
you
know
developed
in
nodejs
Python.
So,
for
example,
if
you
want
to
experiment
quickly,
you
want
to
see
you
know
getting
something
out
the
door.
Sometimes,
no
dear,
can
get
you
those
cycles
quickly
and
get
to
the
one
dot
or
release
quite
fast,
and
that's
probably
the
team
that
you
may
want
to
have
to
get
ideas
out
quickly
to
test
that
and
be
able
to
get
the
feedback
and
once
it
matures
to
a
degree
that
it
now
becomes
an
enterprise
system.
B
Well,
all
system
continues
to
run
and
one
of
the
benefits
that
we
see
as
a
result
of
this
is
let's
say:
if
a
bug
is
found
in
one
of
these
systems,
then
it
can
be
passed
for
that
particular
system
without
impacting
the
others.
So
there
is
no
need
to
synchronize
the
environments,
as
you
can
see,
there's
no
need
to
hold
up
other
people's
releases.
Other
systems
releases,
because
you
know
we
don't
have
one
single
database
that
locks
everybody
down
or
we
don't
have
one
environment
anymore,
that
locks
everybody
down
or
we
don't
have
one.
B
You
know
thing
or
one
team
anymore,
that
locks
everybody
down,
so
we
have
potentially
scaled
up
by
adopting
this
new
architecture.
New
way
of
you
know,
writing
cloud
native
applications
in
such
a
way
that
gives
us
flexibility
to
deploy
independently,
and
this
is
one
of
the
key
benefits
that
most
customers
don't
realize
at
the
onset
that,
in
order
for
you
to
be
able
to
release
quickly,
independence
is
key.
So
I
just
wanted
to
highlight
that
you
know
this
is
one
of
the
key
benefits
that
you
know
as
part
of
the
modernization.
B
Now
we
all
have
hundreds
of
systems
running
in
production
right,
we're,
not
gonna,
shut
them
down
and
suddenly
start
rewriting
them
from
scratch,
and
you
know
tell
the
business:
hey,
you're,
not
gonna,
do
anything
for
the
next
nine
months
or
a
year.
You
just
pay
us
and
we're
just
gonna
continue
to
build
the
new
systems.
That's
never
going
to
happen.
So
what?
What
do
you
do?
B
Let's
say
when
you
have
a
large
portfolio
of
legacy,
applications
that
is
delivering
value
in
the
business
and
and
it's
critical
to
the
business
flows,
but
you
still
have
to
modernize.
You
still
have
to
move
forward.
You
still
have
to
leverage
the
benefits
of
modernization
to
deliver
faster
and
everything
else
that
comes
with
it.
You
know,
so
let's
talk
about
a
structured
approach
of
how
to
move
forward
with
it,
and
this
is
distillation
of
you
know
of
our
work
that
we
have
done
with
various
customers
in
the
field.
B
So
the
idea
is
that
when
we
deal
with
the
application
portfolio,
we
can
actually
analyze
that
portfolio
and
be
able
to
apply
one
or
more
of
these
patterns
so
that
we
can,
in
a
structured
fashion,
develop
a
capability
that
allows
the
app
team
or
an
app
dev
manager.
If
he
has
1015
systems
or
a
VP.
Who
has
you
know,
hundreds
of
systems
or
a
CTO
who
has
even
hundreds
and
thousands
of
systems,
put
a
very
structured
approach
in
place,
so
the
three
patterns
are
lift
and
shift
augment
and
completely
right.
B
So
let's
see
what
they
look
like
in
action,
so
I'm
gonna
move
to
this
slide.
So
the
whole
idea
is
that
you
have
a
defined
starting
point
and
you
have
a
defined
point
of
maturity
for
your
modernization
age.
So,
in
this
slide
you
can
see
the
three
steps
that
I
presented.
The
idea
is
that
these
are
three
steps,
but
they
they
can
be
for
four
steps:
five
steps:
the
idea
is
that
there
is
a
starting
point.
B
There
are
some
intermediate
points
on
the
way
and
there
is
a
point
of
maturity
that
we
want
to
realize
so
generally
for
lift
and
shift.
We
start
with
a
set
of
systems.
There
are
cleanly
architected,
have
clear
separation
of
concerns
and
in
terms
of
our
target
state
you
know
for
proud
native.
We
recommend
you
know
developing
towards
micro-services
type
of
application,
architectures
deployed
on
some
kind
of
a
container
platform
that
will
allow
you
to
grow.
B
You
know
dynamically,
so
the
idea
is
that
you
basically
wrap
your
microservices
and
a
South
Pole
units
that
wrap
the
data
and
configuration
and
everything
goes
together.
So
there
is
no
more
shade
databases,
there's
no
more
shared
configurations.
The
entire
idea
is
that
this
is
independently
deployable.
So,
let's
see
how
that
looks
like
and
how
do
we
actually
go
from?
B
You
know
starting
point
to
the
point
of
maturity,
so
the
first
step
in
the
lift
handshape
is
we
lift
the
existing
runtimes
into
containers,
but
we
leave
the
the
harder
bits
which
are
the
data,
the
configuration,
the
messages
where
they
are
so
in
the
first
step
we
are
going
to
take.
You
know
in
this
particular
example:
I'm
showing
that
application,
which
is
cleanly
architected
with
UI
business
logic,
persistence.
That
was
the
typical
architecture
that
everybody
was
developing
back.
You
know
10
years
ago,
for
example.
B
So
if
you
have
this
kind
of
separation
or
even
better,
you
have
clean
separation
in
terms
of
mist.
You
know
vertical
entities,
you
can
actually
easily
lift
them
into
containers
and
deploy
them
into
containers
while
continue
to
use
your
Oracle
or
Sybase,
or
you
know,
sequel,
server
or
whatever
you
know
wherever
they
are.
B
You
know
a
massive
change
up
front.
This
paradigm
will
allow
you
to
get
to
get
into
a
position
where
you
can
now
quickly.
I
trait-
and
you
know-
improve
your
system
while
continue
to
deliver
business
value.
So
we
are
not
telling
the
business
that
we
are
shutting
down
the
system
for
eight
months
nine
months
here,
whatever
and
not
delivering
any
value.
B
B
One
of
the
key
benefits
of
this
first
step
is
that
we
introduce
a
new
development
and
ops
methodology
that
will
train
the
development
team
and
the
ops
team
to
be
able
to
deal
with
cloud
native
application
deployments
down
the
line.
So
this
is
where
we
introduce
our
fully
automated
CI
CD
tool
chain.
This
is
where
we
introduce
our
you
know:
container
based
development
workflows.
This
is
where
we
introduce
disposable
environments
that
can
be
stood
up,
let's
say
with
open
shift
and
that
will
allow
teams
to
scale
independently.
B
You
know
without
you
know,
you
know
choking
everyone
at
the
same
time,
so
we
have
you
know,
but
just
with
this
single
step,
we
have
actually
eliminated
so
many.
You
know
choke
points
in
the
release.
Train
that
you
know
the
business
can
see
the
value
right
away
now.
The
next
step
quickly
is
as
part
of
the
step
two
now,
since
we
are
already
running
in
a
container
platform,
we
have
the
automated
tooling
in
place.
We
are
able
to
now.
You
know,
take
piece
by
piece
and
you
know
deploy
that
in
a
microservices
architecture.
B
Now
this
approach
will
require
some
deliberation.
Some
pre
architecture-
some
you
know
in
some
cases
we
have
to
little
bit
of
be
careful
and
rewrite
the
pieces.
That
does
not
that
do
not
make
sense,
but
the
whole
idea
is
now
that
we
are
enabled
to
move
faster.
We
can
actually
take
the
time
to
to
do
this
even
on
a
regular
release
schedule,
because
you
know
we
can
open
our
change
request
that
says:
okay,
we
are
going
to
develop
microservices
X
as
part
of
this
release
cycle
and
that
release
cycle
will
also
provide
business
new
functionality.
B
So
next
pattern
is
what
I
call
augment.
We
have
heard
about
augmented
reality.
Well,
we
are
sort
of
augmenting
our
reality
we're
here
by
applying
this
pattern.
So,
let's
imagine
we
have
systems
that
are
monoliths
there.
There
are
systems
that
everybody
scared
of.
Sometimes
these
are
mainframe
systems.
Sometimes
these
are
systems
that
are
developed
over
a
period
of
years,
2025
years
that
people
are
scared
to
touch.
They
don't
want
to
make
changes.
Some
of
them
have
business
logic
installed
procedures,
even
you
know.
B
So,
if
you,
if
you,
if
you
touch
one
part
of
the
system,
then
something
else
breaks
somewhere
else,
but
the
business
is
demanding
that
we
integrate
with
mobile
or
we
integrate
with
our
partners
with
integrated
with
Salesforce
and
other
systems.
So
we
are
in
this.
You
know
situation
where
we
cannot
move
forward,
but
we
have
to
move
right.
So
the
way
we
approach
this
is.
B
Let
me
just
go
through
the
steps
for
this
one,
so
so
the
first
step
in
this
particular
situation
is
while
we
are
augmenting
our
reality
is
you
know
we
recommend
that
we
do
not
do
anything
to
the
current
running
system,
just
leave
it
where
it
is
because
generally
people
are
familiar
with
how
to
manage
its
start
and
stop
and
how
to
manage
its
errors.
So
it
has
gone
through
the
level
of
maturity
in
the
organization
in
terms
of
management.
B
What
we
recommend
is
continue
to
run
the
system
where
it
is,
but
do
two
chunks
make
two
incisions,
so
the
first
incision
is
to
expose
the
functionality
and
the
second
one
is
to
expose
the
data.
What
this
allows
you
to
do
is
call
the
functionality
from
the
outside.
So
this
could
be
your
web
service
that
you
write
that
wraps.
You
know
a
call
to
the
mainframe.
This
could
be
your
messaging
based.
B
You
know
invocation
that
you
send
a
message
and
then
there's
an
adapter
that
you
write
that
talks
to
the
mainframe,
let's
say
and
gives
you
the
response
back
and
let's
say
your
mainframe
is
responsible
for
order
booking
or
patient
records,
or
you
know,
whatever
is
relevant
to
your.
You
know,
business
need
so
suddenly
what
you
have
done
is
you
have
exposed
a
set
of
services
that
can
now
be
called
from
the
outside
using
an
integration
technology
such
as
fuse.
B
You
know-
and
you
have
enabled
yourself
to
you-
know-
use
the
legacy
as
a
back-end
now,
and
the
second
part
is
that
you
can
also
query
submit
queries,
requests
that
give
me
all
the
customers
that
has
property
X.
For
example,
so
you
know
that
is
going
to
go
back
to
the
mainframe
in
quite
the
data
and
the
mainframe
and
give
you
the
results
back.
So
you
have
essentially
enabled
yourself
to
reads
and
writes
and
updates.
These
are
the
critical
operations
that
you
know
you
would
want
to
be
able
to
do
once.
B
You
are
developing
new
functionality
right
using
mainframe
as
your
legacy
as
a
back-end,
and
then
you
develop
your
new
functionality
into
in
a
container
based
past
platform
and
provide
the
value
to
the
business
that
they
need
and
again
imagine
you're
not
telling
the
business
that
we
are
doing
a
massive
rewrite
of
the
mainframe.
You
know
everybody
has
said
that
10
years
ago
that
we
are
retiring,
wait
for
it,
and
here
we
are,
the
mainframes
are
still
around
you
know.
B
Legacy
systems
are
still
around,
but
by
doing
by
by
by
taking
an
additive
approach
such
as
this,
you
isolate
yourself
from
the
changes
that
will
happen
or
continue
to
happen
in
the
mainframe
/my
monolith,
application
and
and
can
and
start
to
deliver
new
business
value
to
the
business
right,
you're,
not
telling
them
and
I'm
shutting
down
that
system
and
I'm
retiring
in
that
system.
Everybody
will
laugh
at
you.
B
The
second
step
is
now
that
we
are
at
a
point
that
we
are
now
delivering
new
functionality
to
do
business
by
enabling
these
integration
points
and
developing
in
the
new
paradigm.
Now
suddenly,
we
can
actually
take
one
piece
at
a
time
and
deploy
that
as
a
micro
service
as
part
of
our
regular
release.
B
So
if,
let's
say
there
is
a
customer
feature
in
the
mainframe,
like
ok
give
me
all
the
customers
or
update
the
customer
or
create
customer,
we
can
actually
model
that
as
a
micro
ServiceNow
and
move
that
entire
set
of
functionality
into
one
or
more
set
of
micro
services
that
are
particularly
aligned
and
stop
using
mainframe
for
any
customer
needs
anymore.
So
we
will
still
use
mainframe
for
other
needs,
but
let's
say
for
a
customer,
then
we
will
go
to
the
micro
services.
Similarly,
you
know
we
can
do
this
for
orders.
B
We
can
do
this,
for
you
know
health
records.
We
can
do
this
for
patients.
You
know
you,
you
get
the
picture
that
you
now
can
actually
take
feature
by
feature
and
start
putting
into
the
new
world,
because
you
have
essentially
made
yourself
independent
in
terms
of
you
know.
Latching
onto
you
are
not
dependent
on
mainframe
/
monolithic
system,
release
cycles,
anymore
right
and
eventually,
let's
say
I
mean.
If,
if
we
get
to
that
point,
you
can
put
actually
look
at
returning.
The
mainframe,
no
pun
intended.
B
Third
type
of
pattern
is
what
I
call
rewrite
base
modernization,
and
this
is
sometimes
necessary
because
we
have
systems
that
are
end-of-life,
that
are
written
such
a
long
time
back
that
there's
no
way
that
anybody
is
familiar
with
it.
So
people
don't
know
how
to
change
it
anymore.
Now,
the
next
step
or
the
look
the
only
step
forward
is
for
us
to
start
to
rewrite
it.
Let's
say
the
platform
that
is
running
on
is
going
out
of
end-of-life
when
there's
not
going
to
support
that
anymore.
B
You
know
Solaris,
let's
say
if
you're
running
in
Solaris
or
if
you're
running
in
something
that
is
going
out
of
support,
then
you
have
to
get
out.
You
have
no
choice
right.
So
if
you
find
yourself
in
this
kind
of
paradigm,
obviously
this
is
a
hard
situation
to
deal
with,
but
the
structured
way
to
deal
with
is
you
know
what
we
recommend
is
may
develop
feature
parity,
so,
instead
of
just
saying
that
I'm
going
to
start
rewriting,
you
know
the
new
system.
B
What
we
recommend
is
just
make
a
list
of
features
that
are
critical
to
the
business
that
in
in
the
old
world
in
this
and
then
start
mapping
features
into
the
new
world
of
micro
services
based
cognitive
applications.
So
if
you
had
ten
features
that
the
business
wants
to
use
from
this,
make
sure
that
those
ten
features
are
implemented,
so
you
sort
of
achieve
the
feature
parity.
B
The
reason
this
is
important
is
because
it's
easy
to
start
writing
new
systems,
but
it's
hard
to
finish
that
you
know
because
of
scope
creep
because
of
new
things
that
the
business
continued
to
request.
So
once
you
start
writing
or
once
you
announce
that
I'm
writing
a
new
system,
you
know
everybody,
you
know,
guess
what
you
know,
everybody's
gonna
come
and
say:
can
you
do
mobile
integration
for
me?
Can
you
do
Salesforce
for
me?
B
Can
you
you
know
give
me
this
report,
you
know,
can
you
do
X,
you
know,
so
you
will
continue
to
receive
new
requests.
That's
the
reality
of
life,
but
now
what
you're
doing
is
that
you're,
making
an
explicit
decision?
You're
saying
that
yes,
I,
will
add
a
new
feature,
but
I
also
have
to
maintain
the
feature
parity.
B
So
maybe
I
will
port
five
features
from
the
older
one
and
add
five
new
features
in
this
one
in
this
release
cycle
and
then
the
next
release
cycle,
and
then
that
actually
cycle
and
that's
how
you
can
more
structurally,
you
know
approach
the
retirement
of
the
older
system,
so
you
can
actually
prioritize
what
makes
more
sense
for
your
business
needs,
but
they're,
adding
new
functionality
or
retiring.
You
can
optimize
for
that,
and
that
becomes
very
important.
B
So,
let's
see
how
these
patterns
actually
compare
with
each
other,
as
I
said
that
generally
people
think
that
rewrite
is
the
easiest
one.
But
what
we
have
found
is
the
rewrite
is
easier
to
get
started
or
very
hard
to
finish
because
of
the
things
I
just
described,
lift
and
shift
turns
out
to
be
the
easiest
to
finish
and
faster
to
finish,
because
what
you're
doing
is
that
you
are
not
actually
making
any
application
changes
in
the
first
cut.
B
B
For
the
buck,
if
you
have
an
application,
that
is
the
best
candidate
for
it,
and
what
we
have
seen
is
that
augment
is
one
of
the
more
common
patterns
that
apply
to
collateral
of
applications,
because
you
know
there
are
portions
of
applications
that
can
be
lifted
and
shifted,
but
some
portions
do
require
you
to
actually
peel
the
onion,
and
you
know
take
that
piece
and
rewrap:
it
shrink
wrap,
hair
down.
You
know
we
are
connected
and
then
deploy
in
the
new
world.
So
you
know
chances
are
that
you?
B
We
will
see
a
combination
of
these
patterns
to
be
applied
together
for
one
or
more
systems,
and
that's
going
to
be
the
vast
majority
of
it.
There
is
going
to
be
a
class
of
systems
that
will
be
a
good
candidate
for
rewrite,
but
the
whole
idea
is
that
we,
you
know
on
the
on
the
scale
of
cost
of
migration
and
time.
We
can
see
that
how
these
patterns
play
out
and
divide
our
portfolio
in
such
a
way
that
we
can
prioritize
for
the
first
one.
B
So
perhaps
when
we
start
marching
towards
modernization-
and
we
have
inventoried
the
system,
you
know
we
can
actually
make
some
educated
decisions.
So
one
of
the
key
questions
is
what
is
what
is
the?
What
does
that
roadmap
look
like?
So
if
we
have
a
portfolio
of
applications
and
now
we
have
to
move
forward
across,
let's
say
hundreds
of
applications.
B
You
know
what
what
what
roadmap
can
we
suggest?
So
this
is
obviously
a
generic
roadmap
that
I
present
to
the
customers,
but
the
whole
idea
is
that
we
sit
down
with
the
customers
and
them
all
of
this
specific
roadmap
for
their
own
needs.
So,
as
you
can
see,
the
starting
point
usually
for
lift
and
shift,
is
customer
coming
from
non
open
source,
middleware
applications.
These
are
your
applications
that
are
running
in
you
know
your
proprietary
stack,
so
the
first
step
that
we
recommend
is
enable
yourself
on
the
open
source
so
get
on
to
Red.
B
Hat
JBoss
stack
if
you
are
not
using
it,
because
first
of
all,
we
have
clearly
architected
JBoss
portfolio
to
be
nimble
and
curved
ready
right
and
you
get
the
benefit
of
paying
less,
because
we
are
a
lot
more
affordable
than
your
other
vendors
and
just
within
chances
are
that
we
will
be
fraction
of
your
maintenance
cost.
Even
so,
just
for
that
thing,
it's
for
the
price
of
the
ticket.
It's
worth
the
price
of
admission
right.
So
that's
the
first
step
that
we
recommend.
B
B
That
is
about
to
be
retired.
We
will
work
with
you
to
develop
the
feature,
parity,
the
list
of
features
and
keep
developer
capability.
Mapping
from
where
you
are
and
where
you
want
to
go,
we
will
then
set
up
and
train
with
the
you
know
you
sort
of
hands-on
workshop
so
that
you
can
actually
decide
which
technologies
which
open-source
technologies
you
want
to
go
forward
with,
and
part
of
that
is
to
develop
cloud
native
application.
You
know
as
part
of
your
effort.
B
B
Augment
versus
you
know
something
else,
and
we
use
that
data
to
basically
develop
a
plan
of
action,
and
that
plan
encompasses
your
entire
portfolio
and
gives
us
very
good
starting
points.
In
terms
of
you
know
how
we
actually
proceed
forward-
and
you
know
this
is
a
structural
approach
that
we
can
put
in
place
as
a
result
of
that,
so
you
know
we
have
started
to
field-test
this
already
with
a
lot
of
our
customers
and
we
have
seen
good
results.
B
You
know
with
this
approach
and
we
are
continuing
to
move
forward
with
this,
especially
you
know
the
the
initial
challenge
challenges
were
when
we
have
a
massive
portfolio
of
applications.
How
do
we
actually
deal
with
that?
And
how
do
we,
actually,
you
know,
put
some
structure
around
it,
so
we
we
now
have
a
methodology,
we
have
a
roadmap
and
we
also
have
a
set.
A
B
Tools
that
we
use
so
there
are
some
real
life
examples
that
I
wanted
to
show
you.
So
this
is
an
example
of
real-life
customer
that
had
a
very
large
web
application
and
the
problem
that
they
were
going
through
was
at
the
time
of
Black
Friday.
They
servers
froze
and
they
they
had
no
I,
no
way
to
actually
add
more
capacity,
so
we
actually
worked
with
them
using
the
left-hand
shift
and
we
were
able
to
deploy
key
components
in
the
container
based
platform
that
allowed
them
to
scale
very
fast.
B
Secondly,
there's
a
valuable
application
with
a
huge
day
in
in
a
mainframe,
and
they
start
this
customer.
The
challenge
was
the
the
user
sessions
were
equal
to
the
DB
connections.
So
if
it
reaches
a
certain
point
you
know
and
that
there
are
no
name
or
database
connections
available,
then
the
system
came
to
a
complete
halt
and
in
this
particular
case
we
applied
an
augment
pattern.
We
introduced,
we
actually
took
the
features
and
and
and
and
ported
them
into
micro
services,
layer
and
introduced
database.
B
B
We
generally
start
with
the
discovery
workshop,
which
is
generally,
you
know
at
no
charge,
but
then
we
engage
with
our
customers
in
the
design
workshop
that
we,
you
know
remember
when
I
showed
you
the
slide,
that
has
the
list
of
applications
and
then
categorize
them,
and
we
run
the
windup
analysis,
and
then
we
make
a
plan,
that's
what
the
design
workshop
is
and
then
eventually
you
know
we
work
with
you
to
scale
up
in
terms
of
migration
and
modernization.
So
it's
it's
really
a
no
Big
Bang
approach,
very,
very
structured,
very
flexible.
B
You
know
so
we
we
have
been
doing
this,
for
you
know
as
two
and
a
half
years
now,
in
with
very
very
successfully
before
we
put
this
structure
in
place.
You
know
we
had
mixed
success,
mixed
results,
but
now
we
have
fine-tuned
our
process
to
actually
hone
in
on
using
this
as
a
very
structure
approach
moving
forward.
So
that
brings
me
to
the
end
of
my
slide
deck
and
I.
Thank
you.
B
B
If
the
customer
is
also
moving
to
the
cloud
as
part
of
this
effort
and
traditionally
they
they
have
not
been
part
of
the
cloud,
then
obviously
those
security
concerns
have
to
be
evaluated
as
part
of
this
migration
effort.
But
you
know,
generally,
you
know
I,
you
know,
I
have
not
seen
the
security
considerations
change.
B
What
what
happens
is
that
when
we
move
to
the
container
based
paradigm,
you
know
the
customers
are
not
sure
how
to
you
know,
security
scan
those
or
how
to
patch
those,
and
those
are
the
new
set
of
processes
that
we
we
put
in
place.
So,
yes,
there
are
some
additions,
and
so
there
are
new
things
as
part
of
this,
but
generally
you
know
the
the
security
infrastructure
and
there's
generally
the
security
stuff.
You
know
we
try
to
work
within
those
confines.
B
Another
question
is
ideas
on
how
to
convince
customer
to
get
on
these
paths.
Clarify
are
why
you
know.
Frankly,
if
the
customer
is
not
already
thinking
about
modernization,
then
I
don't
know.
If
you
know,
maybe
this
is
the
type
of
customer
who
has
really
not
thought
through.
You
know
about
moving
forward
into
any
kind
of
based
architecture.
Yet
so,
if
we
have
that
type
of
a
customer-
and
they
have
not
thought
about
it,
then
you
know
this.
Usually
you
know
what
I?
B
What
I
see
is
that
they
have
this
thing
at
the
back
of
their
head,
but
they
don't
know
how
to
get
started,
and
when
we
present
this,
you
know
the
general
feedback
that
I
get
is
yes,
you
know
this
is
a
very
structured
approach
and
we
actually
can
work
with
you
on
this.
But
you
know
if
the
customer
has
not
decided
to
move
to
the
cloud
for
various
reasons,
then
this
could
be
just
the
catalyst
that
they
need.
You
know,
I
have
seen
several
customers
who
are
traditionally
on
the
fence,
and
you
know
they.
B
They
haven't
moved
forward
for
various
reasons,
but
when
we
give
them
this
kind
of
approach,
which
is
smaller
to
start-
and
you
know,
can
scale
up
according
to
their
needs,
they
feel
much
comfortable.
I
wish
I
had
a
general
answer
for
you,
but
you
know
in
this
case
it
depends
on
customer
to
customer.
B
B
You
know
just
I'm
talking
about
in
some
cases,
even
less
than
three
months
where
we
have
actually
successfully
moved
the
workload
from
the
on
container
base
to
container
based
environment
very
very
quickly,
and
that
has
allowed
customer
to
realize
that
workflow
automation,
you
know,
and
efficiencies
and
standing
up
multiple
environments
quickly.
So
when
we
develop
the
roadmap
with
them,
we
try
to
maximize
with
the
quickest
wins
first
and
I.
Think
that's
where
the
our
wise
can
be
adjusted
or
fine-tuned
for
the
customer
needs.
A
B
B
We
actually
use
methodologies
from
the
wind
event
design
to
model
what
are
the
bounded
context
and
define
those
bounded
context
and
use
that,
as
our
you
know,
transaction
boundary
or
process
boundary
or
micro-services
boundary
to
move
functionality
from
the
legacy
to
the
new
paradigm
or
cognitive
product.
So
you're
absolutely
right
like.
If
you
are
not
careful,
then
you
can
end
up
with
micro
service
that
can
act
same
as
monoliths
because
of
the
dependencies.
So
the
whole
idea
is
that
when
you
actually
decide
to
move
something
from
legacy
to
micro
services,
you
have
to
model.
B
Where
is
the
transaction
boundary?
What
what
are
your
key
aggregates?
That
model
the
system
in
terms
of
define
the
transaction
boundary
or
a
typical
boundary
context?
And
using
that
knowledge
you,
you
then
start
to
port
your
code
or
your
system
into
the
micro
services.
Well,
the
whole
idea
is
that
it
should
be
all
encompassing
show
that
you
should
not
unnecessarily
be
crossing
the
transaction
boundaries
from
one
micro
service
to
the
other.
Now
there
will
be
cases
where
you
know.
B
Multiple
micro
services
will
depend
on
each
other
for
data
and
some
other
stuff,
and
that's
where
we
have
the
you
know
messaging,
where
you
have
the
set
of
micro
services
that
control
the
main
transaction
but
notify
the
downstream
micro
services.
Let's
say
why
event
domain
events,
and
that
way
you
know
you
can
actually
implement
a
set
of
systems
with
micro
services
that
are
fully
independent
in
their
own
transaction
context,
but
act
as
a
group
when
it
comes
to
you
know:
key
business
functionality.
B
A
Okay,
cool:
my
network
has
been
going
up
and
down,
but
your
recording
is
perfectly
fine
and
I
can
hear
you
so
there's
a
you
and
I
think
you've
answered
most
of
the
questions
that
are
in
the
in
the
chat,
but
there's
a
good
set
of
conversation
going
here.
The
entire
deck
will
be
made
available
for
everybody
who
is
listening
to
this.
Are
there
any
other
questions
that
folks
have?
If
you
pop
them
in
to
the
into
the
chat
we
can
continue.
A
B
A
All
right:
well,
thanks
and
I'm
glad
we
got
to
have
this
presentation
today
and
I'm
sure
we'll
have
a
few
more
patterns
in
the
future,
but
I
do
love
the
augmented
reality
one
because
that's
that's
the
world.
We
all
live
in
I,
think
or
we're
going
to
soon
take
care
everybody,
and
we
will
talk
to
you
all
soon
and
if
you're
coming
to
Berlin
travel,
safe,
that's
March,
28th
and
hopefully
you'll
get
to
see.
Zoe
been
person,
yeah,
pretty
sure
he's
got
sessions
at
the
Red
Hat
summit
coming
up
in
Boston
and
May.