►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
the
way
that
we're
going
to
do
this
today
is
that
bob
is
going
to
go
over
some
research
findings
that
they
have
from
a
research
that
they
commissioned
for
on
the
topic
of
app
modernization
and
then
afterwards,
marcus
is
going
to
come
on
and
tell
us
of
how
this
compares,
how
those
funds
compared
to
what
he's
experiencing
with
customers
out
in
the
field
and
once
we
get
through
both
of
those
sections,
then
we'll
have
time
for
any
questions
that
you
guys
may
have.
You
can
put
those
questions
in
the
chat
throughout
the
presentation.
A
B
Yeah,
I'm
gonna
go
ahead
and
jump
on
into
it.
I'm
excited
to
be
here
talk
about
our
findings
and
this
research
report
we
just
completed
with
wakefield
and
really
part
of
our
our
goal
here
was
to
benchmark
where
the
where
the
industry
is
with
app
modernization.
You
know
considering
we've
been
through,
maybe
10
to
20
years
about
modernization
projects.
B
Many
not
successful.
Many
are
and
we'll
talk
about
kind
of
the
the
goals
of
those
projects,
kind
of
talk
about
the
the
terms-
and
you
know
baseline,
how
people
are
looking
at
modernization
talk
about
why
things
fail,
why
things
succeed
and
maybe
some
recommendations
for
success.
So
so
we
just
completed
this
research
just
a
month
or
two
ago,
and
the
research
is
available
on
our
website
feel
free
to
dive
in
and
look
at
all
the
all
the
the
details
around
it.
B
B
So
if
we
take
a
look
at,
you
know
where
the
market
is
currently
I'd
say
that
78
of
the
market
is
really
in
this
meaty
part
of
the
middle,
where
they're
planning
to
modernize,
but
they
haven't
started
yet
many
have
just
started
and
some
have
made
progress,
but
that's
really.
The
mass
majority
is
in
that
area.
The
other
22
percent,
eight
percent,
haven't
started
at
all.
B
Fourteen
percent
have
made
significant
progress,
but
the
mass
majority
is
really
a
focus
on
modernization
as
a
key
area
of
progress,
they're
trying
to
in
many
ways
figure
out,
you
know
what's
went
wrong,
but
also
how
to
improve
it
and
move
it
forward
in
a
much
more
effective
way.
A
And
bob,
do
you
want
to
go
into
your
into
live
show
view
so
that
way
you
can
yeah
there
we
go.
A
B
Okay,
yeah,
I'm
sharing
it
and
I
am
going
to
slide
share
mode.
A
We're
seeing
it
we're
seeing
all
the
slides
and
the
main
slide.
B
There
you
go:
let's
do
it
this
way,
okay,
so
yeah!
So
the.
If
you
take
a
look
at
the
headlines
and
the
headlines
in
this
particular
survey,
79
of
modernization
efforts
are
failing
and
there's
a
high
cost
over
one
and
a
half
million.
You
know
many
are
costing
over
two
million
dollars
in
terms
of
the
overall
project,
so
it's
expensive
and
it's
taking
a
lot
of
time
over
a
year
and
a
half,
sometimes
over
two
years,
is
the
average
for
these
projects
so
they're
taking
a
long
time.
There's
a
lot
of
risk.
B
There's
a
lot
of
failure,
there's
a
lot
of
frustration
in
the
marketplace,
and
I
think
that
is
basically
the
system.
What
we've
seen
throughout
the
industry
for
the
last
probably
five
to
ten
years
now
take
a
look
at
basic
terms
of
how
you
define
app
modernization.
There's
been
a
lot
of
confusion.
I
think
in
the
marketplace
too.
What
is
modernization?
B
B
And
this
is
where
it
gets
kind
of
kind
of
interesting,
as
we
begin
to
split
the
survey
in
terms
of
the
business
leaders
perspective
and
then
the
technical
perspective
from
the
architects
who
are
actually
in
charge
and
actually
have
their
hands
on
the
project
itself,
so
executives,
look
at
app
modernization
in
terms
of
you
know.
How
do
I
increase
innovation?
B
How
do
I
lower
my
technical
debt?
Get
the
product
moving
more
quickly,
create
more
scalability
in
my
business,
and
if
you
take
a
look
at
architects,
they
can
look
at
the
other
side
of
the
coin,
where
innovation
has
a
direct
inverse
relationship
to
engineering,
velocity
and
technical
debt,
so
they
want
increased
velocity.
They
also
want
to
innovate.
They
also
want
to
increase
scalability
on
the
architect
side
or
technical
side,
but
they
also
are
beginning
to
focus
you
see
from
the
architects
the
emergence
of
the
people
side
of
things.
B
Two
it's
hard
to
retain
those
and
keep
those
developers
motivated
and
employed,
and
it's
it's
even
hard
to
organize
them
successfully,
because
monolithic
application
usually
implies
a
monolithic
team.
We
have
a
lot
of
people
working
on
the
same
thing.
It's
hard
to
break
it
into
smaller
groups.
It
was
harder
to
work
in
a
remote
environment
like
we
are
today
in
many
cases
where
we
have
remote
offices,
so.
B
B
97
of
these
organizations
are
seeing
some
level
of
pushback
in
every
modernization
project,
but
any
application
is
up
and
running
now
it's
business,
critical,
you're
running
your
business
on
it.
Key
business
flows
are
still
going
through
it,
even
though
it's
been
around
for
10
or
20
years.
The
risk
of
changing
is
very
high
executives,
also
look
at
the
cost
associated
with
that
and
the
roi
of
actually
doing
the
work.
B
The
architects
look
at
risk
also,
probably
from
a
technical
perspective,
but
they
also
look
at
once
again
the
cultural
side
of
things.
You
know,
there's
a
fear
of
change
inside
the
organization
and
there's
a
fear
of
like
losing
the
role
itself,
so
losing
their
role
and
beginning
to
you
know,
lose
their
part
of
the
organization.
B
What's
interesting,
as
you
look
at
refactoring
projects
more
and
more
we're
seeing
people
we're
able
to
maintain
that
team
and
move
them
forward,
which
is
nice.
If
you
maintain
the
logic,
you
can
help
build
a
bridge
between
the
older
technology
into
new
cloud-native
technologies
and
move
those
teams
forward.
So
a
proper
organization,
a
proper
plan
can
help.
B
You
then
move
move
the
stakeholders
forward
without
the
fear
of
losing
their
jobs,
so
it
actually
has
a
good
cultural
benefit
if
it's
organized
correctly,
so
why
you
know,
we
see
all
this,
this
fusion
number
around
application
modernization
projects
failing.
Why
are
they
failing
so
the
executives
say
one
a
failure
to
set
expectations
correctly
or
accurately,
and
that
includes
not
looking
at
the
cost
correctly,
maybe
not
understanding
the
org
structure,
that's
required.
B
This
is
interesting.
There's
there's
a
lack
of
information
available
to
build
a
clear
business
case
from
an
executive
point
of
view
and
kind
of
their
focus
on
how
these
things
are
starting
and
there's
not
a
clear
before
and
after
or
clear
understanding
between
the
technical
side
and
the
business
side
of
what
they're
trying
to
accomplish.
That
was
one
of
the
key
findings
we
saw.
Is
that
how
you
start
really
implies
and
helps
how
you
finish
in
terms
of
the
results?
B
So,
on
the
architect
side
of
things,
they
call
out
the
lack
of
intelligent
tools
and
we
talked
about
the
challenges
of
doing
the
modernization
data
which
is
being
a
very
manual
process,
takes
a
lot
of
time,
takes
a
lot
of
you,
know,
unraveling
and
unwinding
and
and
dealing
with
all
this
entangled
web
of
dependencies,
but
being
able
to
have
the
tools
that
help
you
through.
That
is
really
something
that's
been
lacking
from
an
architect's
point
of
view.
B
The
training
complexity
all
play
in
the
mineral
ability
to
set
expectations
correctly,
and
I
would
say,
the
lack
of
tools
actually
is
also
impacting
the
ability
to
set
expectations,
because
you
can't
see
inside
the
monolith
themselves.
You
can't
actually
understand
what
it's
going
to
take
to
refactor
or
modernize
that
application
you're
kind
of
just
making
a
best
guess,
and
they
all
agree
that
the
org
structure
needs
to
be
correct
around
making
this
project
successful.
B
I
go
back
to
you
know
splitting
the
view
between
and
modernization
and
the
cloud
providers
over
the
last
five
to
ten
years,
they're
really
focused
on
migration,
lifting
and
shifting
monoliths
into
the
cloud.
It's
faster.
It
improves
your
security
devops
helps
you
close
down
some
data
center
technologies,
but
really
you're,
not
modernizing
anything.
B
I
think
that's
beginning
to
be
a
an
evolution
of
understanding
how
people
are
looking
at
the
modernization
problem.
If
you
want
to
get
that
velocity
that
people
looking
for,
if
you
want
to
increase
innovation,
if
you
want
to
begin
to
get
those
that
application,
scalability,
really
you're,
not
going
to
get
that
unless
you
look
at
refactoring
re-architect
rewriting.
B
The
other
thing
that
we
also
see
around
expectations
that
some
people
try
to
do
the
quick
fix
and
that
quick
fix
happens
by
throwing
an
api
layer
on
top
of
the
monolith
and
maybe
putting
a
nice
shiny
ui.
On
top
of
it
too,
once
again
it's
kind
of
a
stop
gap.
You
get
some
benefits.
You
get
a
nice
ui
celebrate
that
the
api
provides
some
capabilities
that
you
didn't
have
with
just
the
modeler,
but
you
still
have
a
monolith.
B
You
still
have
the
issues
that
you're
unable
to
meet
those
requirements,
meet
the
goals
etc,
and
these
are
two
things
that
we
see
that
migration
versus
modernization
and
the
jumping
to
a
quick
fix
approach.
That's
why
a
lot
of
these
expectations
are
not
being
met
and
why
a
lot
of
people
are
feeling
like
modernization
is
too
risky,
there's
not
a
big
good
plan
set
in
place,
etc.
B
B
I
think
this
comes
down
to
an
understanding
of
being
able
to
look
inside
the
model
as
having
the
tools,
the
data,
understanding
where
the
technical
debt
is
being
carried,
etc,
training
and
preparing
a
staff
once
again
on
the
cultural
side
and
then
finally,
architects,
talk
about
executing
the
project
successfully,
so
having
the
right
tools
in
place,
right
plan
in
place,
etc.
So,
there's
a
planning,
an
assessment
phase,
there's
an
execution
phase
and
then
there's
the
organization
on
making
that
successful.
B
So
having
a
really
clear
plan
of
how
to
make
this
happen
is
important
having
the
tools
to
execute
it
is
important
and
having
the
staff
ready
and
trying
to
make
that
happen.
So
so,
as
we
talk
about
one
of
the
top
two
challenges
with
refactoring
and
people,
look
at
refactoring
being
the
top
option.
When
you
go
into
a
modernization
project
executives
say
it
takes
too
much
time
and
architects
say
it
takes
it's
too
difficult
and
once
again,
I
think
this
is
a
indication
of
complexity.
B
I
think
it's
a
indication
of
a
lack
of
tools
and
a
lack
of
understanding
of
what
it's
going
to
take
to
make
this
successful,
there's
a
common
basis,
the
common
language
up
front
in
terms
of
assessment
having
the
data
upfront,
you
agree
to
you
understand
the
challenges
that
you're
going
to
be
up
against.
Then
it
becomes
much
more
effective
in
terms
of
executives
understand
how
much
time
is
going
to
take
what
the
goals
are
going
to
be
in
architecture
have
a
much
better
understanding
of
the
complexity.
B
The
difficulty
to
make
this
happen,
but
right
now
it's
a
big
challenge,
but
the
challenge
is
something
that
is
you
know
you
don't
really
have
an
option.
You
need
to
be
able
to.
You
know
the
option
of
not
modernizing.
Is
you
have
to
keep
maintaining
the
model
of?
So
you
know
if
you
keep
doing
that,
it's
going
to
you're
going
to
have
an
issue
of
continuing
to
keep
up
with
the
business
requirements.
B
This
is
where
the
executives
come
in.
They
look
at
the
business
side
of
things
and
why
can't
they
keep
up
with
the
business
requirements,
because
it's
a
growing
technical
debt?
That's
weighing
you
down.
If
you
have
to
drag
on
the
application
team
then
find
developers
that
can
maintain
and
then
having
the
time
to
fix
and
add
new
features
so
features
business
requirements
talk
to
the
business
side
of
things,
testing
all
debt
and
developers
talk
about
the
technical
and
the
cultural
side
of
things,
architects.
B
When
they
look
at
the
problem
of
the
top
challenges,
maintaining
it,
it
comes
down
to
ramping
up
developers,
recruiting
developers
actually
retaining
those
developers,
organizing
the
team,
then
that
drives
the
ability
to
keep
up
with
its
growing
technical
debt
and
that
tipping
point
that
we're
all
seeing
around
technical
debt
itself
when
it
becomes
too
much
to
handle.
Then
that
translates
into
keeping
up
with
the
business
requirements
to
see
developers,
technology
and
business
requirements
once
again
pretty
consistent
in
terms
of
how
they
look
at
the
kind
of
a
reorganization
of
how
people
approach
the
problem.
B
In
my
perspective,
I
think
that's
actually
some
of
the
key
elements
that
we're
seeing
across
the
board
of
how
we
make
these
projects
much
more
successful,
so
so
key
takeaways
app
modernization
is,
is
a
is
a
key
initiative.
B
92
are
playing
two
or
I've
already
started
their
app
modernization
projects,
but
we
see
a
lot
of
failures,
they're
taking
a
lot
of
time
and
taking
a
lot
of
money.
So
the
pushback
is
something
that
everyone
deals
with,
but
having
a
strong
understanding
of
the
cost.
The
risk
and
complexity
upfront
can
help
mediate
those
issues.
So
then
it
helps
you
then
prioritize.
B
Those
going
forward
and
architects
and
executives
agree
that
the
challenges
are
there,
there's
clear
reasons
for
failure,
but
there's
also
a
path
for
success,
of
having
the
right
tools
having
the
right
training
and
focusing
on
not
only
the
technology
side,
but
the
people
side
of
things
too.
So
so
that
kind
of
wraps
up
the
wakefield
research
report
and
I'll
I'll
stop
sharing
right
now
and
kind
of
hand
it
back
to
jonathan
and
talk
more
about
it.
A
Thanks
bob
awesome
insights,
so
everyone,
if
you
have
questions
as
we
go
through
this
feel
free
to
put
in
the
chat
now
I'm
going
to
bring
out
marcus,
so
marcus
has
experience
in
the
field,
and
I
thought
it'd
be
interesting
to
get
his
insights
on
and
see
how
these
fundings
match
up
to
his
experience.
Marcus,
if
you
want
to
give
it
a
like
intro
and
yeah.
C
I
don't
want
to
waste
your
time
so
marcus
here,
hi
everyone,
I
work
as
you
can
see.
I
I
work
at
red
hat,
so
I'm
a
senior
architect
with
red
hat
services
in
the
emea
solutions
practice.
So
basically,
what
that
means
is
I'm
helping
customers
across
europe
and
the
middle
east
onboarding
applications
and
modernizing
applications
onto
red,
hat's,
spin
of
kubernetes,
which
is
obviously
openshift
and
the
whole
tool
chain
around
it.
C
So,
furthermore,
I
also
internally
at
red
hat,
lead
the
application,
modernization
community
and,
as
such,
I'm
also
well
feeding
back
our
field
experiences
stories
from
the
trenches,
if
you
will
back
into
the
conveyor
community
and
then
also
help
build
best
practices
around
that
and
so
well.
First
and
foremost,
I
would
like
to
thank
bob
for
sharing
this
and
commissioning
this
research
because
it
basically
mirrors
100
what
I
see
in
the
field
every
day.
C
So
I
encourage
every
one
of
you
to
go
to
the
v
function,
website
and
download
that
report
in
full,
because
it's
very
well
worth
reading,
so
I
I
did-
and
I
did
regret
it
so
I
just
wanted.
I
just
wanted
to
to
elaborate
on
on
on
a
couple
of
things
that
stand
out
for
me.
C
What
I
see
in
the
field-
and
maybe
that
can
can
help
you
listeners
viewers,
tackle
those
challenges
a
bit
better
or
be
prepared
when
you,
when
you
encounter
these,
as
bob
just
said
what
one
of
the
one
of
the
key
things
we
see
at
customers
is
and
what's
what's
really
really
super
important
is
making
the
case
and
that
it
sounds
super
obvious.
C
But
the
thing
is
what
we,
what
we
see
as
red
hat
services,
and
and
probably
this
there's
people
from
from
sis
redhead
partners
that
have
seen
the
same
thing
is
when
we
go
to
customers,
they
tell
us
yeah,
we
need
micro
services,
we
want
to
onboard
that
stuff
and
we
we
have
to
ask
okay.
So
that
is
the
means.
But
what
is
it
that
you're
trying
to
achieve?
Is
it
cost
reduction?
Is
it
a
reduction
of
technical
depth?
Is
it
developer
flexibility?
C
Do
you
want
to
free
up
your
developers
from
manual
and
menial
tasks,
of
keeping
the
monolith
alive,
basically
to
free
up
that
time
for
real
innovation?
Do
you
want
to
move
ahead
of
of
the
pack
of
your
competitors?
So
what
is
basically,
what
is
the?
Why?
Why
are
you
starting
this?
Why
are
you
well,
basically
investing
money
time,
people
people's
time
to
to
start
this
endeavor?
C
What
what
is
it
and
and
the
the
important
thing
is
throughout
that
whole
modernization
project
executives
will
typically,
as
bob
just
said
in
the
also
mirrors,
with
what
what
we
see
those
things
take
time.
There
is
no
pixie
dust
that
you
sprinkle
over
the
application
and
then
everything
will
be
fine.
You
have
to
invest.
C
You
have
to
invest
a
considerable
amount
of
time
to
do
that,
but
one
of
one
of
the
key
things
is:
those
executives
would
want
to
have
some
kind
of
feedback,
so
they
will
naturally
not
be
in
in
the
project
all
the
time,
but
they
would
want
some
reports
so
basically
having
a
baseline
of.
Where
are
we
starting?
What
are
we
trying
to
do?
What
is
the
application
portfolio
planning
that
properly
grouping
it
analyzing
it
assessing
it
and
grouping
it
into
well?
These
are
the
low-hanging
fruit.
C
This
is,
for
example,
something
that
we
can
provide
value
with
very
early
on
migrating
that,
because
it's
it's
very
simple
and
it
will
give
the
team
that's
doing
that
some
some
experience
how
to
handle
the
new
technology,
how
to
handle
the
how
to
deal
with
the
with
hopefully,
a
better,
better
team
structure.
C
Those
need
to
be
those
need
to
be
properly
planned
and
planned,
scheduled
and
well.
If
you
don't
have
a
baseline,
if
you
don't,
if
you
don't
know
where
you're
starting
from
then
you
can
tell
the
executives
who
are
basically
opening
their
pocket
okay.
So
this
is
what
you.
This
is
what
you
wanted,
but
this
is
where
we
started,
and
this
is
our
progress
and
and
these
are
the
improvements
so
being
part
of
the
conveyor
community.
C
There's
one
thing,
probably
once
you
look
into
polaris,
providing
some
some
dashboards
on
the
typical
software
development
matrix
in
terms
of
velocity
mean
time
to
recovery,
etcetera,
etcetera.
I
won't
dive
into
that
now,
but
this
is.
This
is
one
tool,
for
example,
that
that
can
help
you
doing
that.
But
this
is
this
is
the
one.
This
is
the
one
finding
making
the
case
that
really
stands
out,
because
if
you
start
wrong,
there
will
be
no
chance
to
really
to
really
amend
starting
on
the
wrong
foot.
Hello.
C
So
that's
that's!
Really!
That's
really
crucial,
and
so
through.
The
whole
project
also
tying
that
back
into
into
the
strategy
that
you're
following
is
also
a
super
important.
For
example,
just
one
won't
obviously
share
customer
names
here,
but
but
one
customer
was
saying
okay,
I
need
to
I
need
to
basically
my
primary
driver
is.
I
have
a
renewal
upcoming
with
vendor
abc,
and
I
was
thinking
about
moving
off
of
that
platform.
C
Anyways
and
now
so
now
is
the
time
to
not
only
migrate,
my
monoliths
from
a
to
b,
but
also
modernize
these,
because
I
have
to
touch
them
anyway,
so,
but
the
primary
motivation
for
that
was
for
that
was
cost,
so
that
will
inform
the
strategy
that
you're
that
you're
following
so
these
applications
that
are
they
had
more,
they
have,
they
have
105
applications.
Actually,
that
have
to
be
migrated
and
those
those
were
that
were
on
that
specific
platform
that
was
with
the
renewal
around
the
door.
C
They
basically
needed
to
move
these
first
and
tackle
these
first
before
before
all
the
other
ones,
although
some
of
the
other
ones
might
have
been
slightly
easier,
but
as
you
see
what
the
executives,
what
the
executive's
target
outcome
in
this
case,
cost
saving
is
also
has
a
huge
impact
on
what
comes
first.
Basically,
so
that's
that
really
stands
out.
B
Go
ahead,
no,
I
was,
I
was
gonna
chime
in
a
bit
too,
that
the
yeah
I
was
you
know
not
not
surprised
at
the
pain
and
the
issues
and
the
cost
and
all
the
different
complexities
of
doing
modernization,
but
yeah
the
resounding
kind
of
consistency
around
the
lack
of
a
business
plan,
the
need
for
a
better
upfront
planning
those
columns.
B
That's
measurable,
that's
that's
calculated
that
begins
to
you
know,
help
you
both
from
a
technical
perspective,
have
confidence
how
long
it's
going
to
take
whether
what's
the
first
service
I
want
to
pull
out
or
maybe
how
I'm
going
to
prioritize
applications
too.
Maybe
this
is
highly
complex.
It's
going
to
take
me
extra
time.
I
know
that
now
I
had
my
gut
told
me.
It
was
complex,
so
I'm
kind
of
stuck
in
the
middle
of
it,
but
I
have
these
three
other
applications,
which
are
a
little
less
complex,
still,
mission.
B
B
That's
that's
a
kind
of
a
key
kind
of
part
of
the
understanding
that
there's
an
interesting
question
here
around
rewriting
versus
refactoring
and
re-architecting,
and
so
you
know
how
to
decide
between
those
and
also
what's
the
difference,
and
maybe
we
can
also
talk
about
that
in
terms
of
refactoring.
I
would
put
on
a
spectrum
refactoring.
We
architecting
rewriting
kind
of
also
kind
of
blend
together.
If
you
have
a
monolith
and
you
want
to
begin
to
pull
out
services
out
of
that,
but
keep
the
code
itself
and
we
factor
that
particular
set
of
code.
B
Really
it's
maintaining
the
code
beginning
to
change
the
architecture
from
a
monolithic
architecture
potentially
to
a
microservice
or
cloud
native
architectures.
Typically
refactoring
is
in
in
that
mode
re-architecting
might
be
taking.
You
know
some
of
the
applications
and
services
putting
them
together.
Maybe
you
know
throwing
some
monolith
away
and
adding
new
services
and
then
a
full
rewrite
is
actually
starting
to
rewrite
the
actual
business
logic.
We
find
a
lot
of
times
with
molasses.
B
The
the
code
is
actually
is
working
and
it
de-risks
the
actual
project
by
maintaining
the
actual
original
source
code,
but
just
beginning
to
take
that
set
of
code.
That's
in
the
monolith
that
represents
a
domain
beginning
to
pull
that
out
into
a
service
and
use
that
as
a
first
step
to
modernization.
B
So,
but
there
is
a
kind
of
a
spectrum,
that's
that's
connected
from
refactoring
to
architecture
rewriting
and
some
of
that
sometimes
people
kind
of
move
between
them
synonymously
so,
but
they
basically
are
about
retaining
and
beginning
to
move
that
application
forward
in
terms
of
its
architectural.
C
Yeah
yeah,
so
so
so
one
thing
just
just
to
add
here,
maybe
a
little
bit
of
a
well
some
experience
from
from
the
field
is
when
talking
to
two
executives
and
also
architects,
as
as
you
said
so,
I
said
one
hundred
percent.
What
what
what
can
came
out
of
that
report
that
totally
resounds
with
me.
The
thing
is:
risk
well,
no
custom
or
the
other
way
around.
All
customers
are
naturally
risk
averse.
C
We
don't
want
to
derail
their
business,
but
we
need
to
achieve
those
goals.
So
when
we
talk
about
specifically
monoliths,
I'm
not
talking
about
this
simple
thing,
I
have
a
super
small
spring
boot
application
that
I
need
to
onboard
into
container.
C
That's
not
the
use
case
here,
but
most
of
most
of
the
critical
business
applications
they
have
grown
over
time
and
naturally
they
have
grown,
bigger
and
bigger,
and
so
there
won't
be
there
won't
be
a
or
there
shouldn't
be
at
least
a
big
bang
approach,
so
developing
behind
closed
curtains
for
18
months
and
then
coming
out
with
a
new
version
and
then
finding
out.
Okay,
that
is
didn't
resound
with
my
users
or
it
didn't.
C
We
only
captured
like
80
of
the
functionality,
so
what
you
would
be
doing
is
applying
the
strangler
pattern
and
for
that,
for
that
absolutely
also
need
to
you
need
to
analyze
analyze.
The
monolith
see
where
are
the
in
the
domain-driven
design
speak.
Where
are
the
bounded
contexts?
Where
are
the
transactional
contacts
etc
to
carve
out
to
carve
out
bit
by
bit
service
by
service?
C
And
the
thing
is
the
advantage
coming
back
to
what
I
was
saying
about
risk.
The
advantage
of
that
is,
if
you're
doing,
if
you're
doing
this
in
this
stepwise
approach.
What
will
what
what
will
probably
happen
in
the
course
of
that
project
is
that
you
have
implemented
something
not
quite
right
so
with
what
you
can
do
is
then
you
can
basically
throw
away
what
you
what
you
did
or
amended
or
whatever,
and
for
the
time
beings
switch
back
on
that
service
in
the
monolith,
because
it's
still
there
so
you're,
not
you're,
not
throwing
it
away.
C
You
have
to
find
means,
and
there's
tools
around
that
as
well.
You
have
to
you,
have
to
define,
define
basically
an
an
api
that
will
then
connect
your
new
monolith.
Sorry,
no
definitely
not
your
new
microservice
to
that
old
monolith
and
if
something
fails,
you
can
basically
see
what
went
wrong
and
switch
switch
that
back
so
that
takes
out
a
lot
of
risk
out
of
that
approach
over
an
and
right
a
big
bang
approach.
C
So
I
think
that's
definitely
but
but
as
as,
as
bob
said,
you
need
to
know
where
to
make
those
where,
where
to
apply
the
knife,
yes.
B
Yeah,
the
one
of
the
patterns
of
success
that
we've
seen
is
the
for
those
very
complex.
You
know
tens
of
millions
of
lines
of
code,
monoliths
megaliths,
you
might
call
them
that
that
an
iterative
approach
or
a
selective
approach
where
people
are
iterate,
they
do
one
service
at
a
time,
pull
that
out.
Maybe
they
do
another
service
and
get
some
success.
Maybe
they
leave
some
services
behind
so
part
of
the
up
front
planning
is
to
say
I'm
not
it's,
not
a
big
bang
like
you
said.
B
This
is
something
that
requires
an
iterative,
might
some
ways
you're
leaving
them.
Some
on
the
model
left
behind
you're,
pulling
out
some
services
that
are
critical.
Maybe
they're
gonna
combine
with
some
other
services.
You've
already
already
done,
so
I
think
the
you
know
that's
a
for
our
most
successful
projects.
People
have
taken
an
iterative
approach
or
they've
gone
in
selectively
said.
I
know,
there's
three
services
I
want
to
pull
out.
I
need
to
find
out
where
they
are,
what
the
most
effective
way
to
do.
B
That
is
and
begin
to
strangle
the
rest
of
the
monolith
off.
So
I
think
that's
a
another
key.
A
key
pattern
for
people
who
are
looking
to
communicate.
What
are
my,
what
are
my
plans?
How
am
I
going
to
have
early
successes,
and
you
know,
claim
some
and
de-risk
the
process
too,
like
really
success
too.
So.
C
Absolutely
and
one
one
thing
that
probably
most
of
most
of
you
already
know
from
the
from
the
kubernetes
community
well
to
be
to
be
technically
correct,
we're
talking
about
modernization,
and
that
is
that
is
not
in
its
entirety,
tied
to
containers
and
kubernetes.
However,
that
is
99
of
the
use
cases
these
days,
but
you
can
still
modernize
without
without
containers,
but
let's
just
focus
on
the
99
and
forget
about
one
percent
for
the
moment.
C
C
Why
would
we
do
that?
You
might
ask
the
thing:
is
you
can
then
apply
the
strangler
pattern
and
you
only
have
one
platform
to
manage.
So
it's
still
it
lives
in
kubernetes,
the
vm
is
configured
via
by
a
kubernetes
artifact.
So,
basically,
everything
is
kubernetes
and
you
can
basically
shift
the
functionality
slowly
but
steadily
in
in
a
continuous
iterative
approach
from
that
monolith,
so
that
vm
will
get
smaller
and
smaller.
While
your
microservices,
your
native
kubernetes
artifacts,
will
will
become
more
and
more
and
you
will
gain
more
and
more
flexibility.
C
So
that's
also
one
thing
to
consider:
yeah.
B
C
B
That's
a
that's
a
great
pattern:
the
where
I've
seen
some
customers
stop
is
like
they
get
it
into
kubernetes
and
they
leave
it
there
for
a
while
yay
we're
successful
they've
done
the
migration.
C
B
Six
and
nine
months
later
they
realize
that
they
they're
eating
up
way
too
much
cpu
memory
and
they
don't
have
any
of
that
orchestration
control.
So.
C
We
all
yeah,
we
have
these
discussions
so
so,
and
that
is
that
is
not.
That
is
not
only
tied
to
to
actual
vms
using
hubert,
but
we
see
that
every
day
like
containers
that
are
actually
vms,
if
you're,
really,
if
you're
really
honest
about
it,
it's
it's
just
a
vm
that
is
not
av.
It's
not
called
avm,
but
it's
monolithic.
It
takes
minutes
to
start
up.
It
has
some
very
specific
requirements.
C
It
needs
some
some
modifications
on
the
on
the
kubernetes
nodes
to
be
able
to
run
so
really
nightmares,
and
that
is
not
and
that's
why
it's
super
important
to
plan
this
correctly
and
ask
the
customer
what
is
it
that
you're
trying
to
achieve?
Because
none
of
these
migrations
it
will
take
one
of
like
20
boxes.
C
B
And
that's
what
I'm
always
trying
to
reinforce
that
a
migration
is
fine
as
long
as
it's
in
the
context
of
a
broader
modernization
project,
but
I
think
we've
seen
time
and
time
again,
people
stop
with
the
migration
and
they
come
back
a
year
or
two
later
and
realize
they're
they've
had
a
kind
of
remorse,
migration,
remorse
or
lift
and
shift
remorse
they're
up
there
in
the
cloud
they're
eating
up
a
lot
of
bandwidth,
they're
eating
up
a
lot
of
costs
in
the
cloud
and
they're
not
getting
the
benefits
they
wish.
B
They
had
so
so
yeah,
it's
continuing
on
with
the
process.
Having
that
full
kind
of
continuous
view
of
what
happens
next,
and
I
think
the
good
news
is
that
you
know
from
the
survey
and
from
other
kind
of
indications
in
the
marketplace.
B
B
Much
more
we're
seeing
an
interesting
emergence
of
gen,
one
fast
vendors
and
cloud
vendors
who've
been
in
the
cloud,
maybe
five
to
ten
years,
who
are
originally
a
monolith
now
looking
to
do
a
modernization
so
they're
already
in
the
cloud,
their
cloud
vendor
and
they've
been
running
as
a
model
successfully
for
every
five
to
seven
years
now,
they're
looking
at
trying
to
modernize
and
take
advantage
of
the
rest
of
the
benefits
of
containers
and
kubernetes
and
and
microservices.
So
so
yeah.
B
A
C
B
A
B
Yeah
and
I
think
yeah,
it's
a
it's
something
that
we've
we've
touched
on
in
in
the
survey
itself,
and
you
see
it.
I
mentioned
the
seven
r's,
the
nine
r's,
the
five
r's
around
modernization,
but
and
kind
of
go
back
to
that
view
of
refactoring
can
actually
take
the
existing
code
and
begin
to
refactor
how
it's
being
applied
within
the
architecture.
So
it's
a
it's
a
kind
of
re-architecting,
so
we
refactor
and
we
architecting-
have
a
kind
of
a
similarity
and
a
rewriting
is
actually
beginning
to
rewrite
the
actual
code
itself.
B
So,
with
refactoring
able
to
maintain
the
business
logic,
you
actually
begin
to
carve
out
the
domains
find
that
code
itself.
It
de-risks
the
process.
You
begin
to
move
from
a
a
monolithic
architecture
and
refactoring
it
into
a
microservice
architecture,
but
that
requires
you,
understanding,
domains
being
able
to
strangle
off
the
old
old
model
of
flows
and
beginning
to
move
that
into
this
new
architecture.
B
A
full
re-architecture
will
be
right
tends
to
actually
get
into
a
broader
project.
We
see
people
starting
with
a
refactor,
then
they
kind
of
go
into
a
and
then
rewriting
some
new
code,
but
also
then
we
are
protecting
some
other
things.
So
there's
a,
I
think
it
people
move
back
and
forth
in
terms
of
those
projects,
but
they
they
have
similarities
in
terms
of.
If
you
have
code
that
works,
and
you
want
to
de-risk
it,
you
want
to
refactor
it
first
and
then
begin
work
through
every
writing
and
re-architecture
process.
C
Yeah,
absolutely
so
so
the
the
lines
are
blurry
there.
So
so
it's
well
it
really.
It
really
also
well
typical
consulting
on
so
it
depends.
C
The
thing
is,
basically,
there
is
a
lot
of
a
lot
of
basically,
I
call
that
condensed
knowledge
condensed
know-how,
how
the
company
works,
how
the
business
processes
work
condensed
in
code,
and
you
don't
necessarily
want
to
throw
that
away.
What
has
been
proven
working.
You
just
want
to
modernize
it.
C
You
cannot
migrate,
like
pl
pl1
code
without
without
any
hassle
to
to
java
code,
for
example.
In
those
cases
it's
basically
rewriting
is
more
or
less
the
only
option
you
have.
I
know
I'm
not
technically
correct.
There
are
some
translation
mechanisms
for
for
cobol
and
pl1
to
java,
but
well
with
mixed
results.
So
in
those
cases,
in
those
cases,
if
you
want
to
modernize
that
you
just
have
to
rewrite.
A
B
Yeah,
typically,
I
think
you
know
what
we've
looked
at
it
and
kind
of
what
at
least
when
we
dive
into
it.
A
project
itself
is
usually
one
application,
so
it's
a
monolithic
application.
B
There's
a
you
know:
a
broader
mandate
to
modernize
more
applications.
So
usually
it's
in
the
context
of
a
broader
modernization
initiative,
but
a
project
itself
is
typically
one
application
or
monolithic
application,
and
that
could
be
you
know
small
as
marcus
said,
but
also
you
know
the
ones
that
typically,
where
people
raise
their
hands
for
help
are
the
ones
that
are
you
know,
millions
and
millions
of
lines
of
code,
thousands,
tens
of
thousands
of
java
classes,
for
example,
where
it's
difficult
to
really
get
in
there
and
detangle.
B
This
tangled,
you
know
ball,
string
and
begin
to
pull
out
the
different
dependencies
and
different
services
themselves.
So
you
start
with
one
application.
Typically,
once
that
starts
going,
you
can
build
a
a
flow,
a
factory
model
that
is
much
more
repeatable
and
your
your
team
is
trained.
You
understand
some
of
the
tooling
some
of
the
approach.
B
The
business
side
understands
what
they're
expecting
if
you've
had
success,
and
then
the
engineering
cycles
too
so
part
of
it
is
getting
that
flow
going
from
a
factory
perspective.
Usually
most
organizations
don't
have
just
one
monolith,
that's
sitting
on
top
of
you
know,
maybe
hundreds
or
thousands
we've
seen
they
know,
there's
a
core
set
that
need
to
be
modernized
first,
but
there's
a
broader
set
that
need
to
be
addressed
and
that's
where
prioritization
happens
and
where
having
a
set
of
best
practices
where
you've
had
some
success.
C
B
C
So
that
that
also
we
have
we
have
some
customers,
the
minority,
though
that
would
ask
us
okay,
can
you
help
us
with
this
one
or
two
applications?
However,
then
more
often
than
not,
we
tell
them
okay.
So
if
you're
doing
this
in
a
one-off,
typical
project
approach,
what
will
happen
is
you
will
invest
a
lot
of
time
and
resources
and
then
it
will
happen
successfully
hopefully,
and
then
that
team
will
dissolve
again
and
then
a
couple
of
months
later
you
think,
okay,
now
this
application
and
then
all
that
knowledge
will
be
lost.
C
So
what
we
typically
tell
our
customers.
Why
not
take
a
step
back
and
look
at
the
application
portfolio?
There
might
be
applications
that
are
actually
not
worth
looking
at
because
they
will
be
decommissioned
the
next
year
or
so
anyways,
but
looking
at
the
bigger
portfolio
and
then
also
building
a
strategy
from
that
is
definitely
worthwhile
effort,
because
what
what
we
preach
to
our
customers
is
use,
basically
capture,
all
the
information,
even
the
slightest
bits
of
information,
of
also
there's
nothing
wrong
with
failing
with
things
you
can
learn
from
a
failure.
C
You
can
learn
from
a
technology
used
wrong
so
but
document
that,
because
what
will
happen
if
you
have
a
if
you
have
a
bigger
endeavor
like
like,
I
see
basically
coming
back
to
the
question,
I
see
everything
from
30
to
100
the
biggest
customer
that
we're
still
currently
dealing
with
it's
a
long
running
thingy.
Of
course,
they
have
800
applications
that
they're
looking
at
it's
obviously
a
very
large
organization,
but
it's
somewhere
between
a
few
and
large
numbers.
C
So
there's
no
real
thing,
so
I
would
say
the
average
is
about
100
150,
something
like
that
they
have
more.
But
those
are
the
ones
in
focus
so
going
going
back
to
this
cycle
that
you're
going
through
with
with
these
applications.
So
what
you?
What
you
would
typically
do,
is
harvest
all
that
information
into
some
kind
of
knowledge
base.
What
we'd
call
typically
a
cookbook
cookbook,
because
when
I
encounter
this
library
when
I
encounter
this
technology,
when
I
encounter
this
setting,
I
can,
after
the
third
or
fourth
or
fifth
application.
C
I
can
then
just
pull
out
the
recipe,
because
that
problem
has
already
been
solved
by
someone
else,
of
course,
because
I'm
in
a
I'm
a
developer
in
a
different
different
application
department,
for
example,
but
I
can
pull
out
that
knowledge.
I
can
just
apply
it
instead
of
reinventing
the
wheel
and
that's
what
happens
if
you're
doing
this
one
application,
then
crickets
next
application,
crickets!
C
If
you
don't,
if
you
don't
harvest
that,
and
also
if
you
don't
have
that
team-
that
enabling
team
that
that,
to
a
certain
extent,
controls
that
whole
endeavor
and
also
onboards
the
developer
teams
onto
the
new
technology.
C
So
that
goes
a
little
bit
to
the
to
the
to
the
finding
that
that
the
study
has
defined
a
line
and
trained
the
team.
So
basically,
if
you're
tasking,
if
it's
asking
a
team
that
has
never
seen
containers
with
migrating
a
monolith
into
con
into
a
containerized
world,
you
will
have
problems
so
nothing
that
cannot
be
solved.
But
you
need
to
identify
okay.
So
what's
the
maturity
of
the
team?
What's
what
are
the
processes
around
it?
So
just
a
simple
example
modernizing
something
with
a
customer,
but
the
customer
has
is
really.
C
I
call
that
process
written
because,
even
though
they
have
the
nicest
technology
now
they're
still
due
to
their
process,
requirements
and
regulatory
requirements
and
basically
all
very
heavily
siloed
organization,
they
basically
they're
still
just
releasing
quarterly
because
they
they
can't.
B
Yeah,
I
think
it's
consistently.
The
function
came
out
with
their
modern
with
our
modernization
hub
a
couple
years
ago
focused
on
refactoring,
and
it
became
pretty
clear
that
from
a
project
perspective,
it
was
successful,
but
the
front
end
of
assessment
and
prioritization
and
building
the
pipeline
and
getting
all
that
tooling
up
front
and
all
that
analysis
up
front
was
a
key
requirement
to
create
a
kind
of
continuous
assessment
model,
you're,
always
assessing
you're,
always
trying
to
flow
applications
in
so
you
have
that
set
of
best
practices.
B
I
think
you
see
a
very
consistent
thing
and
then
we
have
an
assessment
version
of
the
product
and
a
modernization
version
which
allows
them
to
create
a
much
more
consistent
kind
of
a
continuum
around
modernization,
you're
assessing
you're,
always
modernizing.
It
is
not
just
a
project
one-off
basis,
so,
and
I
think
that's
the
next
phase
that
we're
kind
of
pushing
towards
is,
you
know,
moving
towards
a
way
you're,
always
measuring
your
technical
debt.
You're
always
trying
to
understand.
B
You
know,
there's
microservices
that
become
macro
services
that
become
you,
know,
monolithic
services
and
we've
begun
to
see
that
happen
too.
Where
you're,
you
have
very
chunky
services
that
aren't
optimally
defined
that
have
been
actually
not
all
the
context
has
been
plugged
into
it,
and
these
are
big
services
and
you
want
to
be
able
to
have
much
more
nimble
service
going
forward.
So
all
those
things
I
think
are
part
of
the
where
the
where
the
market's
headed
where
the
industry's
headed
but
yeah,
we
have
to
get
through
all
these
app
modernization
challenges.
First,
so.
A
C
Yeah
yeah-
I
I
could
be
here
that
just
started
yeah
so
basically-
and
basically
bob
said
that
already
and
that
that's
what
I
see
as
well,
so
nothing
can
be
as
permanent
as
temporary
solutions,
so
basically
that
that
is
a
risk
that
is
a
risk
you're
facing
with
customers.
That
would
just
say,
okay,
yeah.
No,
it
runs
on
kubernetes,
great
next
and
yeah
so
that
that
that
is
a
problem.
It
should
always
be
clear
for
for
modernization
purposes.
C
There
are
obviously
other
use
cases
where,
where
a
cube,
vert
totally
makes
sense
to
to
run
vms
on
kubernetes
in
for
for
the
foreseeable
future.
But
when
it
comes
to
modernization,
the
goal
is
not
to
make
your
monolith
run
on
kubernetes.
The
goal
is
to
modernize,
and
so
this
would
be
an
interim
step.
C
However,
that
step
makes
it
easier,
makes
the
whole
modernization
process
easier,
because
you're
not
facing
okay,
you
know
need
to
have
like
firewalls,
opened
specific
specific
network
routing
all
these
things,
because
you're,
basically
on
the
same
network,
now
you're
on
on
the
same
platform
on
the
same
network.
Otherwise,
you
always
have
the
the
problem
that
you're
that
you're
crossing
boundaries
of
maybe
also
organization-wise
crossing
boundaries
and
you
have
to
file
tickets,
etc,
etc.
So
that
just
helps
the
process
and
yes,
nested
virtualization
is
never
a
good
thing.
C
So
that's
you
have
to
you
have
to
run
it
on
on
bare
metal.
Yes,
it
will
it's
it's
a
trade-off
of
sorts.
So
if
you're,
if
you're,
let's
say
on
on
vmware-
and
you
only
have
vmware
just
just
to
name
one-
then
that
is
probably
not
an
option
for
you,
because
then
setting
up
an
extra
bare
metal
and
there's
no
operations
team.
That
knows
how
to
how
to
maintain
that
bare
metal-
and
that's
probably
not
not
a
good
thing
to
do,
and
that's
basically
because
well
nested
virtualization!
C
Well,
you
can
play
around
with
that,
but
that's
nothing
that
should
go
into
production
because
there's
there
could
be
so
many
problems
between
those
virtualization
layers
that
and
also
well
performance.
You
can
probably
tackle
performance
with
more
power,
but
still
there's
there'll
be
dragons,
so
don't
do
it,
and
that
is
that
is
the
trade-off.
Yesterday,.
A
Okay-
and
this
is
for,
I
believe,
both
of
you-
what
are
examples
of
successful
case
studies
using
the
strangler
pattern
for
non-trivial
containerized
application,
so
something
that's
50
to
100
containers.
B
Yeah,
I'm
sure
marcus
had
have
a
lot
of
case
studies
on
that
we've
got
several
on
our
our
side.
Intestines
and
paulo
trend.
Micro
who've
gone
through
this
and
all
of
them
kind
of
share
that
same
set
of
patterns
of
you
know,
complexity,
but
also
a
lot
of
risk
and
a
lot
of
frustration.
B
Some
failed
efforts
in
advance
of
where
they
came
into
this
and
then
really
then
also
use
that
strangler
pattern
to
begin
to
move
that
into
a
successful
use
case.
So
some
of
those
are
available
on
our
website.
B
There's
a
cool
product
from
aws
called
refactor
spaces
too.
That
does
some
of
the
automatic
strangular
pattern
with
the
networking
components
and
that's
another
area.
You
look
at
for
the
actual
strangler
effort
how
you
do
that
on
top
of
aws
is
called
aws
refactor
spaces
part
of
the
migration
hub
product
too.
So
they
have
some
use
cases
there
around
how
you
can
once
you've
done
the
modernization,
how
you
use
strangular
pattern
to
begin
to
shut
down
one
side
and
begin
to
enable
another
sign.
C
Yeah
and
so
well,
I
have
to
I
have,
to
be
honest,
I'm
not
really
sure
what
customer
names
from
my
recent
experience
I'm
allowed
to
mention
so
I
would
have
to.
I
would
have
to
just
point
you
to
well.
For
example,
a
v
functions
website,
red
hat's
website
and
there
well
the
strangler
pattern.
It's
not
new.
It
has
been
around
since
I
think
2004
or
so
so
that
has
been
applied
in
in
many
cases,
so
world
modernization.
C
Every
time
you
build
something
even
the
greatest
latest
and
greatest
and
most
shiny
technology
that
you
that
you're
building
today
will
be
considered
legacy
in
five
years.
So
the
thing
is:
that's
why
you
have
to
be
continuous
in
in
these
efforts
and
make
sure
whatever
you
do
today
will
be
technical
that
also
in
five
years.
C
So
this
pattern
has
been
around
for
quite
a
while,
and
all
you
can
all
you
can
do,
and
that's
one
of
the
reasons
why
people
do
these
kinds
of
modernizations
is,
if
you
have
smaller
components
to
to
to
to
to
manage,
speak,
microservices
or
right
size,
services
or
whatever
you
want
to
call
them
so
smaller
components
that
are
independently
deployable
easier
to
manage,
with
defined
boundaries
tied
to
a
specific
business
needs.
So
that
would
make
it
easier.
C
It
will
make
it
easier
in
the
future
to
to
tackle
that
technical
debt.
That
will
be
no
doubt
will
be
there
in
in
in
a
couple
of
years,.
A
Okay
awesome,
so
we
have
kind
of
the
opposite
question
being
asked
now:
are
there
any
public
case
studies
or
public
articles
about
modernization
or
failed
modernizations
or
less
than
optimal
ones?
So
anything
that's
seen
as
an
anti-pattern
that
others
can
learn
from
you
guys
know
of
any
public
references
on
that.
C
A
B
I
would
say
that
our
the
survey
provides
that
anonymous.
You
know
conclusion
around
why
they're
failing
you
know,
failure
set
expectations.
You
know
lack
of
business
plan,
lack
of
intelligent
tools,
there's
a
lot
of.
I
think
indications
in
the
survey
itself,
that
one
reason
we
wanted
to
do.
The
survey
is,
you
know
the
new
from
the
anecdotal
side
of
things
to
actually
be
in
the
measure
why
people
are
saying
it
fails
and
why
they
failed
in
the
past
and
how
they
look
to
kind
of
succeed
in
the
future.
So.
A
B
Yeah,
so
part
of
the
selection
criteria
was
they.
They
have
java
and
java
applications
that
they're
looking
to
modernize.
So
that
was
a
part
of
the
process
that
we're
getting
into
we're,
not
just
going
into
environment
where
they're
running
already
in
microservices,
or
you
know
you
know,
etc.
So
we
went
into
organizations
that
had
applications
of
a
certain
size
and
and
certain
kind
of
groups
of
applications
and
began
to
then
look
at
the
demographics
and
the
cohorts
around
the
business
leaders
versus
the
application.
B
B
A
C
That's
that's
the
book
we
all
swear
by
right
yeah.
So
that
is
everyone
who
has
not
read
it.
Just
just
google
team
topologies.
I
have
the
blur
kicking
in
here.
So
now
I
can
see
it.
Matthew,
skelton
manual
pays
team
topologies,
just
google.
That
will
be
one
of
the
first
hits.
That
is
super
helpful
because
I
also
also
said
it's.
C
It's
super
important
to
look
at
the
at
the
processes
and
at
the
team
structures
because
well,
as
as
you
said,
bob
when
you
have
a
monolithic
application,
you
typically
have
a
monolithic
team.
C
So,
and
you
will
you
will
want
to
when,
when
you
focus
on
smaller
services
that
serve
a
specific
that
are
in
a
specific
business
domain
and
and
serve
a
specific
purpose,
you
will
you
want
to
organize
your
team
around
that
and,
on
the
other
hand,
also
what
you
want
to
do
is
you
want
to
you
want
to
enable
your
organization?
C
So
we
don't
say
we
don't
say
like
modernization
means
you
have
to
restructure
the
whole
company?
No,
that's
not
the
case,
but
you
have
to
you
have
to
establish
some
some
good
well.
Hence
the
name
team
topologies.
Well,
who
who
is
reporting
to
whom?
Who
is
doing
what?
Who
is
helping
whom
and
who
is
organized
around
around
value
streams,
meaning
who
is
providing
value,
building
an
application
that
serves
a
purpose
and
who
is
like
in
an
organizational
sorry
a
in
a
vertical
in
a
vertical
approach?
C
Who
is
supporting
multiple
teams,
onboarding
and
building
the
feedback
loop
between
developers,
for
example,
developers
and
the
platform
team
that
is
now
managing
the
kubernetes
platform?
So
what
features
do
the
developers
as
platform
users?
What
do
they
need
to
achieve
those
tying
back
to
the
beginning,
those
target
outcomes?
C
A
All
right
guys
so
last
question
and
we
can
wrap
it
up
we're
at
the
hour
mark.
The
question
is:
is
there
a
recommended
tool
stack
from
assessment
to
planning
to
actual
implementation
like
reading
code,
analysis
and
code
converters
which
v
function
and
red
hat
use
or
recommend?
A
B
Yeah,
well
I
mean
this
is
right
in
the
heart
of
what
be
function
does
in
terms
of
automated
assessment,
technical
debt,
analysis
for
prioritization
and
then
a
modernization
hub
where
we
actually
will
do
the
refactoring
and
dependency
analysis.
And
so
we,
this
is
kind
of
the
heart
of
what
we
do.
We
integrate
with
with
openshift
and
a
bunch
of
other
kind
of
platforms
in
terms
of
target
cloud
native
environments,
and
so
that's
a
so.
C
However,
probably
looking
at
things
from
it
from
a
different
angle,
so
what
what
the
v
function
tool
set
does
is
much
more
sophisticated
and
in
depth
than
than
the
than
the
con
conveyor
tool
set,
because
it
looks
at
things
from
from
from
a
different
angle
so
and
that
there
are
obviously
also
some
overlaps
and
I
would
think
well,
I
typically
work
with
mostly
mostly
with
conveyor,
because
those
are
also
the
the
upstream
versions
of
the
red
hat
products,
but
I
would
expect
beyond
v
function.
C
Well,
I've
had
the
pleasure
bob
to
to
work
with
you
before
and
and
present
that
internally
at
red
hat.
But
the
thing
is
so,
I
know
v
function
and
there's
probably
others
as
well
so
they're
going
back
to
the
question.
There
is
no
recommended
tool,
stack,
there's
nothing
like
do
it
this
way
and
everything
will
be
good.
It
also
depends
on-
let's
say:
let's
say
I
get
from
from
from
v
function
very
sophisticated.
I
get.
I
get
the
whole
dependency
chain
untangled.
I
know
where
the
where
my
transaction
boundaries
are.
C
So
basically
all
the
work
is
carved
out
for
me,
but
I
don't
have
anyone
who
actually
knows
how
to
how
to
move
this
into
into
a
container.
So
you
have
to
look
at
the
the
bigger
picture.
C
A
C
Come
again,
sorry
how
many
customers
are
coming
into
asking
red
hat
to
to
operate
or
sorry.
I
didn't
get
that
fully.
That
question.
A
C
Right,
okay,
so
I
missed
the
middle
part
and
that's
on
their
own
yeah
on
on-prem.
So
we
see
the
shift.
We
see
the
shift
currently
of
of
customers
moving
on
kubernetes
in
the
cloud
for,
for
example,
well
in
our
case,
obviously
managed
openshift
on
azure
on
aws,
for
example.
So
I,
as
a
customer,
don't
have
to
worry
about
managing
my
clusters,
etc.
I'm
just
consuming
I'm
just
consuming
all
the
goodness,
and
I
don't
have
to
have
people
who
are
actually
doing
that.
I
can
basically
free
up
those
people.
C
However,
obviously
there's
a
cost
involved
so
and
other
customers,
mostly
in
the
in
the
highly
regulated
environment
such
as
banking
insurance,
medical
services.
We
see
those
trying
to
well
consolidate
their
data
centers,
but
for
for
regulatory
purposes
they
can't
move
everything
higher
highly
confident
data
to
the
cloud.
So
it's,
however,
from
my
experience,
I'm
not
a
market
researcher,
but
from
my
personal
experience,
what
I
see
customers
are
more
and
more
shifting
what
they
can
to
the
cloud.
C
So
so,
red
hat
red
hat
is
doing
more
and
more
of
these
hybrid
cloud
projects,
also
where
these
regulatory
customer
regulatory
inflicted
customers
they're
keeping
the
core
data
in-house
because
they
have
to,
but
that
doesn't
mean
that
they
don't
have
workloads
that
can
well
work
very
well
on
on
on
a
managed
and
hosted
kubernetes.
So
so
this
hybrid
approach
is
also
we're,
also
seeing
more
and
more
of
that,
because
then
you
can.
C
Basically
you
can
manage
it
as
one
target
appropriately
and
say:
okay,
these
workloads
will
go
up
there
and
these
have
to
stay
in-house
along
with
their
associated
data,
of
course,
and
so.
B
That
yeah
on
the
on
on
the
kubernetes,
what
I
would
say
is
that,
with
the
cloud
provider
services
are
getting
are
very
mature,
the
openshift
services
around
kubernetes.
I
think
the
management
and
operation
and
tooling
around
that
has
gotten
very
mature
and
kind
of
much
more
predictable.
There's
still
a
training
issue,
there's
still
like
a
lack
of
skill
personnel.
B
So
I
mean
it's
hard
to
put
a
number
on
it,
but
I
think
the
for
people
who
are
looking
to
get
confidence
that
want
to
get
comfortable
with
managing
it,
using
a
service
to
start
with
a
managed
service
and
then
working
your
way
into.
Maybe
something
you
would
do
on
your
own
would
be
something
would
be
the
trend
to
go
to,
but
the
managed
services
are
very
predictable
and
I
see
we
see
that
in
most
cases
somewhere
in
an
organization
there's
a
there's,
a
team
that
feels
comfortable
with
it.
B
A
Awesome
well
guys:
let's
go
ahead
and
close
this
out
did
any
of
you
have
any
closing
thoughts
you
want
to
share
with
the
audience
and
maybe
how
they
can
reach
you.
If
they
have
any
questions
or
anything,
they
should
check
out.
B
Yeah,
well,
I
just
want
let's
say
thank
you
all
for
letting
us
share
our
perspectives
on
application,
modernization,
the
challenges,
I'm
bob
at
be
function.
You
know
bob
quillinette,
you
know
on
twitter
also,
so
you
can
track
me
down
there,
but
bob
would
be
funny
of
an
email,
have
any
questions
and
look
forward
to
seeing
all
out
there.
So
thank
you
very
much.
C
Well,
yeah,
you
can
reach
me,
that's
a
little
more
complicated.
I
should
have
thought
about
that,
but
creating
an
alias,
but
it's
m
nagle,
so
marcus
nagel,
so
first
letter
first
name
m
nagel
at
red
hat,
so
you
can
reach
me
also
anytime,
if
there's
questions
or
just
ping,
your
nearest,
your
nearest
red
header,
so
there's
well
thanks
for
for
for
watching
and
listening
and
as
you
can
see,
I
I
I
can
fill
whole
evenings.
I
can
blow
parties
with
just
talking
about
application
modernization.
So
thanks
for
bearing
with
me.