►
Description
Today on the show we are very lucky to be joined by Chris Umbel and Shaun Anderson from Pivotal to talk about app transformation and modernization! Our guests help companies to update their systems and move into more up-to-date setups through the Swift methodology and our conversation focusses on this journey from legacy code to a more manageable solution. We lay the groundwork for the conversation, defining a few of the key terms and concerns that arise for typical clients and then Shaun and Chris share a bit about their approach to moving things forward. From there, we move into the Swift methodology and how it plays out on a project before considering the benefits of further modernization that can occur after the initial project. Chris and Shaun share their thoughts on measuring success, advantages of their system and how to avoid roll back towards legacy code. For all this and more, join us on The Podlets Podcast, today!
For the show notes and transcript: https://thepodlets.io/episodes/019-application-transformation
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepo...
info@thepodlets.io
Guests
https://twitter.com/chrisumbel
https://twitter.com/swiftbird68
Hosts
https://twitter.com/carlisia
https://twitter.com/opowero
https://twitter.com/joshrosso
https://twitter.com/mauilion
A
Welcome
to
the
popplets
podcast
hi,
everybody
welcome
back
to
the
pilots.
Today
we
have
an
exciting
show:
it's
myself
on
kaliesha
campus.
We
have
our
usual
gasps,
sorry
holds
Duffy
Cooley,
I
left
power
and
Josh
Russell.
We
also
have
two
special
guests:
Chris
humble
did
I
say
that
right,
Chris
I
should
have
checked
this
close.
B
B
A
A
A
So
we're
going
to
definitely
dig
into
that.
How
are
they
not
like
how
it
does
it
not
make
sense
to
use
them
interchangeably
because
I
just
buy
the
meaning
I
would
think
so,
but
I'm,
also
not
in
that
world
day
today
in
Sean
and
Chris
are
by
the
way.
Please
give
us
a
brief
introduction,
the
two
of
you:
why
don't
you
go
first,
Chris
sure.
B
C
A
D
B
I
think
you
might
even
get
different
definitions
even
from
within
our
own
practice,
but
I'll
I'll
at
least
lay
it
out
as
as
I
see
it
and
I
think
it's
probably
consistent
with
how
how
Shawn's
going
to
see
it
as
well.
But
it's
it's
it's
what
we
tell
customers
anyway
and
at
the
end
of
the
day
there
are
your
apt
transformation,
is
sort
of
the
the
larger
made
a
bucket.
B
So
that's
going
to
include,
say
just
the
rear
hosting
of
applications
taking
applications
from
point
A
to
some
new
point
B,
without
necessarily
improving
the
state
of
the
application
itself.
So
we'd
say
that
that's
not
necessarily
an
exercise
and
paying
down
technical
debt.
It's
just
making
some
change
to
an
snorts
environment
and
then
on
the
modernization
side.
B
That's
when
things
start
to
get
potentially
a
little
more
architectural
and
and
that's
when
the
focus
becomes
paying
down
technical
debt
and
and
really
improving
the
application
itself,
usually
from
an
architectural
point
of
view,
and
things
start
to
look,
maybe
a
little
bit
more
like
like
rewrites
at
that
point.
So.
B
C
I
would
say,
transformation
is,
is
not
just
the
reap
lat
forming
Rijo,
stting
and
modernization,
but
also
the
the
practice
to
figure
out
which
should
happen
as
well.
So
there's
a
little
bit
more
meta
in
there,
but
but
typically
have
transformation
to
me
is
the
bucket
of
things
that
you
need
to
do
to
move
your
product
online.
C
A
Cool
so
I
have
two
questions
before
we
start
really
digging
to
the
show
is
still
to
like
lay
the
ground
for
everyone,
so
my
next
question
will
be:
are
we
talking
about
modernizing
and
transforming
apps,
so
they
go
to
the
clouds,
or
is
there
a
certain
cutoff
that
we
start
thinking?
Oh,
we
need
to,
or
things
get
done
differently
for
them
to
be
cloud
native.
Is
there
a
differentiation
or
is
it's
just
one
is
the
same
as
the
other
like
the
process
will
be
the
same
either
way.
B
There's
there's
definitely
a
distinction,
and
if
you,
the
the
other
platforming
bucket
kind
of
that
were
hosting
a
bucket
of
things,
is
where
you
know
your
target
state,
at
least
for
us
coming
out
of
pivotal.
We
had
a
definitely
a
product
focus
where
you
know
we're
probably
only
going
to
be
doing
work
if
it
intersects
with
our
our
product
right.
A
C
Know,
I
yeah,
I
have
the
same
view
and
I
think
part
of
what
makes
our
our
process
unique.
That
way
is
we're
not
necessarily
trying
to
target
a
platform
for
deployment
when
we're
when
we're
going
through
the
modernization
part
anyway,
you
know
we're
really
looking
at
how.
How
can
we
design
this
application
to
be
the
best
application
it
can
be,
and
it
just
so
happens
that
that
tends
to
be
more
12
factor
compliant.
That
is
very
cloud
compatible,
but
it's
not
necessarily
the
way
that
we
start
trying
to
aim
for
a
particular
platform.
A
A
What
do
you
define
as
legacy,
because
that's
what
we're
talking
about
right,
we're
talking,
definitely
talking
about
a
move
up,
move
forwards,
we're
not
talking
about
regret
regression
and
we're
not
talking
about
scale
scaling
down
we're
talking
about
moving
up
the
step,
moving
up
to
modern
technology
stack,
so
that
means
that
implies
we're
talking
about
something,
that's
legacy.
What
is
the
legacy
is
a
contextual.
A
B
Can
certainly
tell
you
what
what
how
you
can't
necessarily
define
legacy.
You
know
one
of
the
ways
is
by
the
year
that
it
was
written.
You
can
certainly
say
that
there
are
are
certainly
shops
who
are
writing
legacy
code
today,
they're
still
writing
legacy
code
as
soon
as
they're
done
with
a
project
it's
instantly
legacy.
C
C
So,
even
though
it
may
be
the
latest
technology,
it
just
wasn't
built
for
the
load,
for
example,
and
sometimes
legacy
can
be
the
pain
is
we
have
applications
on
a
mainframe
and
we
can't
find
Kobol
developers
and
we're
leasing,
a
giant
mainframe,
and
it's
costing
a
lot
of
money
right
and
and
so
there's
different
flavors
of
pain,
and
it
also
could
be
something
as
simple.
As
you
know,
a
data
center
move,
something
like
that.
C
B
But
that
isn't
indeed
what
we
do
and
and
and
try
to
alleviate
that
in
some
way,
but
that
that
pain
is
sort
of
what
dictates
the
solution
that
you
come
up
with,
because
there
are
certain
kinds
of
pain
that
aren't
going
to
be
solved
with,
say,
a
modernization
approach
or
a
platforming
approach.
Even
you
have
to
listen
and
make
sure
that
you're
you're
applying
the
right
medicine
to
the
right
pain.
E
Seems
like
an
interesting
thing,
bringing
what
you
said
Chris
and
then
what
you
said
earlier:
Sean
Sean,
you
had
mentioned
that
the
the
target
platform
doesn't
necessarily
matter
at
least
up
front
and
then
Chris.
You
did
implied,
like
you
know,
bringing
the
right
thing
in
to
solve
the
pain
or
to
help
remedy
the
pain
to
some
degree
and
I.
Think
what's
what's
interesting,
maybe
about
the
perspectives
for
those
on
this
call,
and
you
too
is
a
lot
of
times.
C
There's
it's
it's
hard
to
find
one
team
or
one
one
person
who
can
point
out
the
pain
on
both
sides,
and-
and
so
it
just
depends
on
often
how
the
customer
approaches
us.
You
know
if
they're
saying
something
like
we
have.
You
know
we're
a
credit
card
company
and
we're
getting
our
butts
kicked
by
this
other.
You
know
company
because
they
can
do
biometrics
and
we
can't
yet
because
of
the
limitations
of
our
application.
Then
we
would
approach
it
from
you
know
they
have
first
perspective.
C
But
if
it's
another
pain
point
where
you
know
our
our
operations
day
to
operations
is
really
suffering.
We
can.
We
can't
scale
we're
you
know
we.
We
have
issues
that
the
platform
is
really
good
at
solving.
Then
we
may
start
there,
but
it,
but
it
always
tends
to
kind
of
merge
together
in
the
end,
and
it's.
B
B
They
they
solve
the
infrastructure
problems
ahead
of
us
and
then
we
sort
of
close
things
out
on
the
application
side.
But
you
know
if,
if
you
know
we,
if
our
account
teams
and
our
organization
is
really
listening
to
each
individual
customer,
you
know
you'll
find
that
there
that
the
pain
is
is
is
drastically
different
right.
There
are
are
some
cases
where
the
driver
is
cost
and
that's
an
easy
one
to
understand.
B
There
are
also
drivers
that
are
what
usually
like
a
date
such
as
this
data
center
goes
dark
on
this
date,
and
I
have
to
do
something
about
it.
If
I'm
not
out
of
that
data
center,
then
my
apps
no
longer
run,
and
the
solution
to
that
is
very
different
than
the
solution
you
would
have
to
you
know.
Look
my
my
application
is
is
difficult
for
me
to
maintain.
It
takes
me
forever
to
ship
features.
Help
me
with
that.
B
D
Wonder
I
wonder
this
is
a
pretty.
It
is
kind
of
an
interesting
space
to
operate
in
if
the
application,
transformation
and
stuff
and
I've
seen
entities
within
some
of
the
larger
companies
that
that
represent
sort
of
this
field
as
well
and
sometimes
that's
called
Production
Engineering
or
there
are
a
few
other
exam.
D
This
one
I'm
aware
of
I'm
curious
how
you
all
how
you
see
that
happening
within
large
companies
like
you,
do
you
find
if
there
is
like
a
particular
size
or
a
particular
size
entity
that
is
actually
striving
to
do
this
work
with
the
tools
that
they
have
internally
or
do
you
find
is
that
typically,
typically,
most
companies
are
just
kind
of
needs,
needs
something
like
an
application.
Transformation
seem
to
come
in
and
help
them
figure.
This
part
of
it
out.
C
B
There
might
be
a
little
bit
of
bias
to
that
response
in
that,
like
typically
in
in
order
to
even
get
in
the
door
with
us,
you're,
probably
a
fortune,
100
or
or
at
least
a
500
or
government,
or
something
to
that
effect.
So
you
know
we're
going
to
be
seeing
people
that
one
have
a
mainframe
to
begin
with
and
and
to
would
have
say
you
know,
capacity
to
fund,
say
a
dedicated
transformation
team
or
or
to
build
a
unit
around
that.
B
You
could
say
that
the
smaller
an
organization
gets
maybe
the
easier
it
is
to
just
have
the
entire
organization
just
write
software,
the
modern
way
to
begin
with,
but
at
least
at
the
the
large
side
we
do
tend
to
see.
People
tried
to
build
a
bill,
use
different
names
for
it,
but
try
to
have
a
dedicated
center
of
excellence
or
practice
around
modernization.
B
D
D
And
like
for
me,
I
I
do
argue
that
you
do
need
it
going
forward
because
of
the
cognitive
overhead
between
understanding
how
your
application
is
going
to
serve
it's
going
to
thrive
on
today's
complex
infrastructure
models
and
understanding
how
to
write
code
that
works
and
I
think
the
one
person
that
has
all
of
that
in
their
head
all
the
time.
It's
like
a
little
too
much.
It's
a
little
too
far
to
go
sometimes
sure.
B
That
that's
probably
Truman
and
when
you
consider
the
the
size
of
the
portfolios
and
the
size
of
the
backlog
for
modernization,
that
people
have
I
mean
there's
people
are
going
to
be
busy
on
that
for
a
very
long
time
anyway.
So
you
know
it's
either,
even
if
it
is
finite,
it
still
has
a
very
long
life
span
at
a
minimum
and.
C
And
at
a
certain
point
it
becomes
like
you
know:
painting
the
Golden
Gate
Bridge
as
soon
as
you
finish.
You
have
to
start
again
because
if
technology
changes
or
business
needs
and
that
sort
of
thing,
so
it's
probably
a
very
dynamic
kind
of
organization.
But
you
know
there's
there's
a
lot
of
overlap.
So
the
you
know
the
pioneering
teams
set
a
lot
of
the
guidelines
for
how
the
following
teams
can
be
doing
their
modernization
work
and
it
just
keeps
rolling
down
the
track
that
way.
So
it
may
be
that
people
are
busy.
C
You
know
modernizing
applications
off
of
WebLogic
or
WebSphere,
and
it
takes
a
you
know,
two
years
or
more,
to
get
that
completed
for
this
enterprise.
But
it
was,
you
know,
20
50,
different
projects
and
to
them
it
was
brand-new
each
time
which
is
kind
of
it's
kind
of
cool,
actually
to
come
into
that.
A
D
What
we've
talked
about
so
far
is
if
that
resists,
some
of
the
deeper
architectural
issues
and
stuff
you've
already
mentioned
twelfth
after
and
like
being
able
to
kind
of
move
or
thinking
about
sort
of
the
way
that
you
frame
the
application
as
far
as
like
inputs
and
those
things
that
it
takes
to,
did
you
figure
in
or
to
think
about
the
life
cycle?
In
those
things?
D
Are
there
some
other
common
patterns
that
you
see
across
the
two
practices
of
Java
and.net
that
you
think
are
just
you
know
concrete
examples
of
stuff
that
people
should
you
know
that
people
could
take
away,
maybe
from
from
this
episode
that
they
could
look
at
their
application
to
try
to
get
ahead
of
the
game
a
little
bit.
I
would.
C
Say
a
big
part
of
the
commonality
that
Chris
and
I
both
work
on
a
lot
is
we,
we
have
a
methodology
called
the
Swift
methodology
that
we
use
to
to
help
discover
how
the
applications
really
want
to
behave.
You
know
define
a
notional
architecture
that
is
again
agnostic
of
the
the
implementation
details,
so
so
will
often
come
in
with
a
you
know,
the
same
process
and
I
don't
need
to
be
a
dotnet
expert
and
add
on
that
Schaaf
to
figure
out
how
how
the
system
really
wants
to
be
designed.
C
How
you
want
to
you
know,
break
things
into
micro
services,
and
then
the
implementation
becomes
where
those
details
are-
and
you
know,
Chris
and
I
both
kind
of
collaborate
on
a
lot
of
that
work,
and
it
makes
you
feel
a
little
bit
better
about
the
the
output.
When
you
know
that
you
know
it's,
the
technology
isn't
as
important.
You
guys
you
get
actually
pick
which
technology
fits
the
solution
best
as
opposed
to
you
know,
starting
with
the
technology
and
letting
a
solution
form
around
it.
That
makes
sense.
B
That
and-
and
that's
that's
a
bit
of
a
that's
generally
a
bit
of
a
process
that
customers
have
to
go
through.
It's
difficult
for
them
to
do
that,
because
the
more
the
more
technical
their
stakeholders
tend
to
be
often
the
more
attached
they
are
to
to
the
individual
technology
choices
and
breaking
that
is,
is
a
principal
role
for
us.
B
F
Is
there
any
help
or
any
investment
or
any
sort
of
coordination
with
those
vendors
or
the
purveyors
of
the
technologies
that
perhaps
legacy
applications
are,
or
indeed
the
platforms
they're
running
on?
Is
there
any
help
on
that
side
from
from
those
vendors
to
to
help
with
application
transformation
or
making
those
applications
better?
Or
do
organizations
have
to
rely
on
a
completely
independent
sort
of
team
like
like
you
guys
to
come
in
and
help
them
with
that?
You
know.
Do
you
understand
my
point?
Is
there
any
sort
of
internal,
like
you
mentioned,
WebLogic
west
fear.
F
C
Think
I
think
some
of
it
depends
on
what
the
goal
of
the
modern
zatia
niz.
If
it's,
if
it's
something
like,
we
no
longer
want
to
pay
Oracle
licensing
fees,
then
of
course,
obviously
they
or
you
know,
WebLogic
teams
aren't
gonna,
be
happy
to
help,
but
but
that's
not
always
the
case.
Sometimes
it's
a
case
where
you
know
we
may
have
a
lot
of
WebLogic.
We
it's
working
fine,
but
we
just
don't
like
where
it's
deployed
and
we'd
like
to
containerize.
C
It
move
it
to
kubernetes
or
something
like
that
in
that
case,
they're
they're
more
willing
to
help.
But
at
least
in
my
experience,
I've
found
that
the
technology
vendors,
you
know
I,
rightfully
kind
of
focused
just
on
upgrading
things
from
their
perspective
and
and
they
want
to
own
the
world
right.
You
know
WebLogic
will
say
hey.
We
can
do
everything.
We
have
clustering.
C
B
B
So
you
know
quite
often
were
sort
of
adversary
a
bit
of
an
adversarial
relationship
with
them
on
occasion,
but
I
could
certainly
say
that
within
the
net
space,
we've
worked
a
relatively
collaboratively
with
Microsoft
on
things
like
steel-toe,
which
is
a
I,
wouldn't
say
it's
a
spring
boot
analog,
but
at
least
a
micro
service
library
that
helps
people
achieve
12
factor
cloud
nativeness
and
that's
that's
something
where
you
know
I
guess
Microsoft
represent,
represents
both
the
legacy
side,
but
also
the
future
side
and
we're
sort
of
part
of
a
solution.
Together.
There.
C
And,
and
actually
that's
a
good
point,
because
the
other
the
other
way
that
we're
we're
seeing
vendors
be
involved,
is
you
know
in
creating
like
operators
on
on
the
kubernetes
side
or
Cloud
Foundry
tiles?
You
know
something
that
makes
it
easy
for
their
system
to
still
be
used
in
the
in
the
new
world
and
that's
that's
definitely
helpful
as
well.
E
So
recently,
myself
and
some
people
on
my
team
went
through
a
training
from
both
Sean
and
Chris.
Interestingly
enough
in
Colorado
about
this
thing,
called
the
Swift
methodology
and
I
know
it's
kind
of
a
really
important
methodology
to
how
you
approach
some
of
the
application
transformation
like
engagements.
Could
you
to
kind
of
give
us
a
high-level
overview
of
what
that
methodology
is.
C
B
So
Swift
is
a
series
of
exercises
that
we
use
to
go
from
a
business
problem
into
what
we
call
a
notional
architecture
for
an
application
and
the
one
thing
that
you'll
hear
Sean
say
all
the
time
that
I
think
is
is
pretty
apt,
which
is
we're
trying
to
understand
how
the
application
wants
to
behave.
So
this
is
a
a
very
analog
process,
especially
at
the
beginning.
It's
one
where
we
get
people
who
can
speak
about
the
business
problem
behind
an
application
and
the
business
processes
behind
an
application.
B
We
get
them
into
a
room,
a
relatively
large
room,
typically
with
a
bunch
of
wall
space,
and
we
go
through
a
series
of
exercises
with
them.
What
we
kind
of
tease
the
business
process
apart,
and
we
start
with
a
relatively
lightweight
version
of
Alberto
brand
Elena's
events,
touring
method,
where
we
map
out
with
the
subject
matter,
experts,
you
know
what
all
of
the
business
events
that
occur
in
a
system
are,
and
that
is
a
non-technical
exercise.
B
It
completely
known
technical
exercise
as
a
matter
of
fact,
all
of
this
uses
sticky
notes
and
kind
of
arts
and
crafts.
But
after
we've
gone
through
that
process,
we
transition
into
Boris
diagram,
which
is
a
and
exercise
if
Shaun's
design,
that
we
take
the
domains
that
we've
or
at
least
like
service
candidates,
that
we've
extrapolated
from
that
event
storming
and
start
to
draw
out
a
notional
architecture.
B
So
like
an
80%
idea
of
what
we
think
the
architecture
is
going
to
look
like
and
we're
going
to
do
this
four
slices
of
thin
slices
of
that
business
problem,
and
at
that
point
it
starts
to
becoming
something
that
a
software
developer
might
be
interesting
in
interested
in
and
we
have
a
exercise
called
snappy.
That
generally
occurs
concurrently,
which
translates
that
that
sort
of
message
flow,
Boris,
diagram,
kind
of
thing
into
something-
that's
at
least
a
little
bit
closer
to
what
a
developer
could
act
upon.
But
again.
B
These
are
sticky,
note
and
analogue
exercises
that
generally
go
on
for
about
a
week
or
so
things
that
we
do
interactively
with
customers
to
try
to
get.
You
know
in
a
purely
non-technical
way,
at
least
at
first,
so
that
we
can
understand
that
problem
and
tell
you
what
an
architecture
is
that
you
can
then
act
on,
and
we
try
to
position
this.
As
you
know,
customer
you
already
have
all
of
the
answers
here.
What
we're
going
to
do
as
facilitators
of
these
is
try
to
pull
those
out
of
your
head.
B
C
Was
I
couldn't
have
said
it
better
myself,
I
would
say
one
of
the
interesting
about
this
process
is
the
reason
why
it
was
developed.
The
way
it
was
is
because
in
the
world
of
technology,
and
especially
engineers,
I've
definitely
seen
that
you
have
to
two
modes
of
thought.
When
you
come
from
the
business
world
to
the
you
know,
to
the
Nicolle
world
and
often
engineers
will
approach
a
problem
in
a
very
different
way
and
a
very
focused
kind
of
blinder
duay.
C
The
work
is
separated
from
the
business
team
enough
that
it's
like
playing
the
telephone
game
right
where
the
business
folks
say
well,
I
told
them
to
do
this,
and
the
technical
teams,
like
oh
awesome.
Well,
then,
we're
gonna
use
all
this
amazing
technology
and
build
something
that
really
doesn't
support
you,
and
so
this
this
process
really
brings
everybody
together
to
discover
how
the
system
really
wants
to
behave
but
also
kind
of
as
a
side
effect.
You
get
everybody
agreeing
that,
yes,
that
is
the
way
it's
supposed
to
be,
and
it's
it's
exciting
to
see.
C
Teams
come
together
that
actually
never
even
work
together
and,
and
you
see
the
light
bulbs
go
on
and
say:
oh
that's
why
you
do
that
and
the
end
result
is
in
a
in
a
week.
We
can
go
from.
Nobody
really
knows
each
other
or
quite
understands
the
system
as
a
whole.
We
have
a
backlog
of
work
that
we
can
prioritize
based
on
the
learnings,
that
we
have
and
feel
pretty
comfortable
that
the
end
result
is
going
to
be.
You
know
pretty
close
to
how
we
want
to
get
there
and
then
the
biggest
challenge
is
defining.
C
E
C
A
That
sounds
really
neat
and,
as
always,
we
are
going
to
have
links
on
the
show
notes
for
all
of
this.
I
checked
out
the
website
for
the
event
storming
book,
and
there
is
a
resources
page
there
and
has
a
list
of
a
bunch
of
presentations
sounds
very
interesting.
I
wanted
to
ask
Chris
and
Sean.
Have
you
ever
seen
or
heard
of
a
case
where
a
company
went
through
the
transformation
or
modernization
process,
and
then
they
wrote
back
to
their
legacy
system?
For
any
reason,.
C
That's
that's
actually
a
really
good
question
and
it
implies
that
often
the
way
people
think
about
modernization
would
be
more
of
a
you
know:
a
Big
Bang
approach
right
where
it's
that's
at
a
certain
point
in
time
we
switch
to
the
new
system
and
if
it
doesn't
work,
then
we
roll
back,
but
part
of
what
we
try
to
do
is
have
incremental
releases
where
we're
actually
putting
small
slices
into
production
where
you're
not
rolling
back
a
whole.
You
know
from
modern
back
to
legacy.
It's
more
of.
You
have
a
week's
worth
of
work.
C
B
What's
what's
interesting
about
a
lot
of
large
organizations?
Is
that
they've
been
so
used
to
doing
big
bang
releases
in
general
and-
and
this
goes
from
software
to
even
process
changes
in
their
organizations
they
become
so
used
to
that
that
it
often
doesn't
even
cross
their
mind
that
it's
possible
to
do
something
incrementally.
So
we
we
really
do
oftentimes
have
to
get
spend
time,
but
you
know
getting
buy-in
from
them
on
that
kind
of
approach,
and
you
know
you'd
be
surprised
that
that
even
in
industry
is
that
you'd
think
would
be
fantastic
with
managing
risk.
B
But
you
know
you
know,
as
Sean
mentioned,
the
specifics
of
Swift
are
to
find
a
way
so
that
you
can
understand
where
and
and
get
a
roadmap
for
how
to
carve
out
incremental
slices
so
that
you
can
seat
a
strangle,
a
large
monolithic
system
slowly
over
time-
and
you
know
that's
that's
something
that
that's
pretty
powerful
and
once
someone
gets
bought
in
on
that
they
absolutely
see
the
value,
because
they're
minimizing
risk
right,
they're
they're,
making
small
changes
that
are
easy,
they're
easy
to
to
roll
back
one.
At
a
time.
B
You
know
you
might
see
people
who
would
stop
somewhere
along
the
way,
and
we
wouldn't
necessarily
say
that
that's
a
problem
right
like
not
just
like
not
every
app
needs
to
be
modernized.
Maybe
there's
portions
of
systems
that
could
stay
where
they
are
and
is
that
a
bad
thing?
I
I
I,
wouldn't
necessarily
say
that
it
is
maybe
maybe
that's
the
way
that
the
best
way
for
that
organization.
D
It's
the
you've
bumped
into
this
idea
now
a
couple
of
different
times
and
I
think
both
Kristin
and
Sean
have
brought
this
up,
but
it's
it's
kind
of
like
a
little
preload
to
show
that
you're
planning
on
doing
the
quote.
One
of
the
upper
book
quotes
from
that
show
is
the
greatest
enemy
of
knowledge
is
not
ignorance.
D
It
is
the
illusion
of
knowledge
with
equipment,
Stephen
Hawking,
and
it
speaks
exactly
to
that
right,
like
when
you
come
to
when
you
come
to
a
problem
with
a
solution
in
your
mind
that
it's
frequently
difficult
understand
the
problem
on
its
merit
right,
it's
right.
It's
really.
It's
really
interesting.
Seeing
that
kind
of
crop
up
again
in
this
show
and.
B
D
What
question?
Actually
there
was
something
recently
that
happened
in
the
kubernetes
community,
which
I
thought
it
was
pretty
interesting
that
I'd
like
to
get
your
thoughts
on
it,
which
is
that
sto,
which
is
a
project
that
operates
as
a
service
mission.
I'm
sure
you
all
are
familiar
with
it.
Have
recent
has
recently
decided
to
kind
of
modernize
itself
in.
D
They're
they
were,
it
was
originally
developed
as
a
set
of
Micra
services,
and
they
had,
you
know,
had
kind
of
no
end
of
difficulty
in
getting
in
optimizing
the
the
different
interactions
between
those
services
and
the
and
the
nodes,
and
then
recently
they
decided.
You
know
this
might
be
a
good
example
of
of
when
two
monoliths
versus
when
two
microservice
and
I'm
curious.
What
your
thoughts
are
on
that
or
if
you
have
familiy.
B
B
Actually
quoted
I'm
not
going
to
necessarily
speak
too
much
to
this
time
will
tell
as
to
if
the
monolith
thing
that
they're
doing
at
the
moment
is,
is
appropriate
or
not,
but
quite
often
a
starting
point
for
us
isn't
necessarily
a
monolith.
What
it
is
is
a
proposed
architecture
coming
from
a
customer
that
they're
proud
of
that.
This
is
this.
Is
my
micro
service
design
and
you
know,
you'll
see
a
simple
system
with
you
know.
B
Maybe
hundreds
of
nano
services
and
the
surprise
that
they
have
is
that
that
recommendation
from
us
coming
out
of
our
swift
sessions
is
that
the
actually
or
you're
overthinking
this?
This
is
we're
going
to
take
that
idea
that
you
have
anyway
and
and
maybe
shrink
that
down
and
to
say
tens
of
services
or
just
a
handful
of
services.
The
and
I
think
one
of
the
missed
the
mistakes
that
people
make
within
enterprises
or
on
micro
services
at
the
moment
is
to
say:
well,
that's
not
a
micro
service,
it's
too
big!
C
C
It
doesn't
mean
the
implementation
can't
even
be
as
a
single
monolith,
but
componentized
inside
it
right
and,
and
that's
part
of
what
we
try
really
hard
to
do
is
avoid
the
the
religion
of
you
know,
mano
list
versus
micro
services
or
even
having
to
spend
a
lot
of
time
trying
to
define
what
a
micro
service
is
to
you.
It's
really
more
of
while
a
system
kind
of
wants
to
behave
this
way.
So
now,
surprise
you
just
did
domain
driven
design
and
mapped
out
some
good
12
factor
compliant
micro
services.
F
Is
there
more
traction
in
organizations
implementing
this
methodology
on
a
kind
of
a
net
new
business
rather
than
current
running
businesses
or
applications?
You
know
this:
is
there?
Is
there
like
situations
more?
So
you
know
that
you
have
seen
where
a
new
project
or
a
new
to
the
functionality
within
the
business
starts
to
drive
and
implement
this
methodology,
and
then
it
sort
of
creeps
through
the
other
lines
of
business
within
the
organization,
because
you
know
that
first
one
was
successful.
B
Yeah
I'd
say
that,
based
on
kind
of
the
nature
of
who
our
customers
are
as
in
a
transformation
practice
based
on
who
those
customers
are
and
what
their
problems
are.
You
know
we're
generally
used
to
having
a
starting
point
of
you
know
a
process
or
software
that
exists
already,
but
there's
nothing
at
all
to
mandate
that
it
has
to
be
that
way.
As
a
matter
of
fact,
we've
with
folks
from
our
labs
organization,
we've
used
these
these
methods
in
what
you
could
probably
call
greener
fields.
B
You
know
there's
at
the
end
of
the
day,
you
know
when
you
have
a
process
or
even
a
candidate
process,
something
that
doesn't
exist
yet
as
long
as
you
can
get
those
ideas
onto
sticky
notes
and
onto
a
wall.
This
is
a
very
valid
way
of
getting.
You
know,
turning
ideas
into
an
architecture
and
architecture
into
software
and.
C
F
And
I'm
kind
of
this
might
be
a
bit
bit
of
a
broad
question,
but
what
sort
of
design
defines
success
of
projects
like
this
I
mean
we
mentioned
earlier
about
cost,
and
maybe
some
of
the
drivers
are
to
to
move
off
certain
mainframes
and
things
like
that,
but
if
you're
undergoing
an
application
transformation,
it
seems
to
me
like
it's
an
ongoing
thing:
how
do
enterprises
try
to
to
to
evaluate
that
return
on
investment?
You
know,
how
does
it
relate
to
you
know,
sort
of
success
criteria,
I
mean
faster
release
times,
etc,
potentially
might
be
one.
F
C
Apart
I
think
part
of
what
what
we
try
to
do
up
front
is
is
identify
what
the
objectives
are.
For
you
know
a
particular
engagement
and
often
those
objectives
start
out
with
with
one
thing
right.
You
know
it's
it's
it's
too
costly
to
keep
paying
IBM
or
Oracle
for
WebLogic
or
WebSphere,
but
as
we
go
through
and
talk
through
what
types
of
things
that
we
can
solve,
those
objectives
get
added
to
right.
C
So
it
may
be
the
first
thing
our
primary
objective
is:
we
need
to
start
moving
workloads,
workloads
off
of
the
mainframe
or
workloads
off
of
WebLogic
or
WebSphere,
or
you
know
something
like
that,
but
there's
other
objectives
that
are
part
of
this
too,
which
you
know
can
include
things,
as
you
know,
as
interesting,
is
developer
happiness
right.
They
have
a
large
team
of
150
developers
that
are
really
just
getting
sick
of
doing
the
same
old
thing
and
having
new
technology.
C
That's
actually
a
success
criteria,
maybe
down
the
road
a
little
bit,
but
it's
it's
more
of
a
nice
to
have,
but
kind
of
in
you
know
a
long-winded
answer
of
saying
when
we
start
these
and
when
we
Incept
these
projects,
we
usually
start
out
with.
Let's,
let's
talk
through
what
our
objectives
are
and
how
we
your
success,
those
key
results
for
those
objectives
and
as
we're
iterating
through
we
keep
measuring
ourselves
against
those
and
sometimes
the
objectives
change
over
time,
which
is
fine
because
you
learned
more
as
you're
going
through
it.
F
B
You
know
their
customers
okrs
oftentimes.
They
can
be
a
little
bit
easier
to
understand,
sometimes
they're,
not,
but
typically
they
involve
time
or
money
where
I'm
trying
to
take
release
times
from
X
to
Y
or
decrease
my
spend
on
X
to
Y,
but
the
way
that
we
sort
of
I
think
measure
ourselves
as
a
team
is
is
around.
You
know
how
clean
do
we
leave
the
the
campsite
when
we're
done.
B
We
want
the
customers
to
be
able
to
to
run
with
this
and
to
continue
to
do
this
work
and
to
be
experts
as
much
as
we'd
love
to
take
money
from
someone
forever.
We
have
a
lot
of
people
to
help
right,
so
our
our
goal
is
to
help
a
build
that
practice
and
center
of
excellence
and
expertise
within
an
organization
so
that
you
know
as
their
goals
or
ideas
change
things.
They
have
a
team
to
help
them
with
that.
A
A
B
Let's
start
to
talk
about
solutions
to
that,
and
you
know:
we've
seen
customers
of
all
shapes
and
sizes
and
no
matter
how
large
or
are
cumbersome
that
might
be
we've
seen
a
lot
of
big
organizations
make
great
progress
and,
and
if
your
organization's
in
pain
I'm,
you
can
use
them
as
an
example,
you
can
you
can?
There
is
light
at
the
end
of
the
tunnel
and.
C
C
We
didn't
talk
a
lot
about
that,
but
it's
it's
a
little
bit
less
meta
anyway.
It's
it's
more
technical
and
more
recipe
driven.
You
know
as
you
as
you
discover
what
the
workload
looks
like
it's
more
about.
You
know,
is
it
something
we
can
easily
do
a
CF
push
or
just
create
a
container
and-
and
you
know,
move
it
up
to
the
cloud
with
minimal
changes
and
there's
not
it
conceptually,
not
a
lot
of
complexity.
Implementation,
wise,
there's,
still
a
lot
of
challenges
there
too,
but
they're
not
as
fun
to
talk
about
for
me
anyway.
D
Yeah
in
a
previous
episode,
we
talked
about
persistence
and
state
those
sorts
of
things
and
how
they
relate
to
your
applications
and
how,
when
you're
thinking
about
B,
platforming
in
and
even
you
know,
which
is
where
you're
planning
on
putting
those
applications.
That's
where
it's
at
for
us.
That
question
comes
up
quite
a
lot
like
that's
kind
of
a
most
step:
zero
like
trying
to
figure
out
the
state
model
and
those
ways
of
thinking.
A
Episode
was
named
States
in
stateless
apps,
I
think
so
we
are
at
the
end.
Unfortunately,
it
was
so
great
having
you
both
here:
Thank
You,
Duffy,
Shan,
Chris
and
I'm,
going
by
the
order
I'm,
seeing
before
my
video,
Josh
and
olive
until
next
time
make
sure
please
to
let
us
know
your
feedback
subscribe,
give
us
a
thumbs
up.