►
From YouTube: The Good, the Bad & the Ugly of Migrating Hundreds of Legacy Applications to Kubernetes
Description
The Good, the Bad and the Ugly of Migrating Hundreds of Legacy Applications to Kubernetes [B] - Josef Adersberger, QAware
Running applications on Kubernetes can provide a lot of benefits: more dev speed, lower ops costs, and a higher elasticity & resiliency in production. Kubernetes is the place to be for cloud native apps. But what to do if you’ve no shiny new cloud native apps but a whole bunch of JEE legacy systems? No chance to leverage the advantages of Kubernetes? Yes you can!
We’re facing the challenge of migrating hundreds of JEE legacy applications of a major German insurance company onto a Kubernetes cluster within one year. We're now close to the finish line and it worked pretty well so far.
The talk will be about the lessons we've learned - the best practices and pitfalls we've discovered along our way. We'll provide our answers to life, the universe and a cloud native journey like:
- What technical constraints of Kubernetes can be obstacles for applications and how to tackle these?
- How to architect a landscape of hundreds of containerized applications with their surrounding infrastructure like DBs MQs and IAM and heavy requirements on security?
- How to industrialize and govern the migration process?
- How to leverage the possibilities of a cloud native platform like Kubernetes without challenging the tight timeline?
About Josef Adersberger
Josef Adersberger is #cloudnativenerd, CNCF member, and co-founder & CTO of QAware, an independent cloud native software manufacturer that has been repeatedly awarded Best IT Workplace in Germany. He studied computer science in Rosenheim and Munich and holds a doctoral degree in software engineering. He is a lecturer for cloud computing at several German universities.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hi
guys
welcome
to
my
talk.
It's
really
amazing
to
see
so
many
people
here,
so
you
guys
are
ready
to
get
into
the
dirty
details
of
migrating
legacy.
Applications
onto
shiny
new
cover
nets,
yeah,
okay,
cool
I'm,
Joseph,
I'm,
CTO
and
co-founder
of
Q,
where
it's
we're
custom
software
development
company
from
Germany,
Munich,
Germany,
focusing
on
developing
cloud
native
applications
and
migrating
legacy.
Applications
onto
a
cloud
native
stack
and
today
I
want
to
talk
you
through
what
we
have
learned
by
migrating.
Hundreds
of
j2ee
legacy
systems
onto
kubernetes
I'm.
A
It
all
started
with
a
big
bang
when
curate
a
cribben,
Eddie's
and
docker
was
released,
open
source
to
mankind
and
literally,
everybody
suddenly
wasn't
available
or
was
possible
for
them
to
develop
cloud
native
applications.
Those
applications
have
common
properties
like
being
hyper,
scalable
being
really
resilient
to
failures.
A
They
maybe
sometimes
have
or
provide
effects
savings
due
to
a
higher
resource
utilization
and
more
and
more
option,
and
you
can
develop
at
a
higher
level
of
speed
a
shorter
release
cycles.
So
these
are
huge
advantages
of
such
cloud
native
applications
and
the
question
is
what
about
legacy
applications?
Can
they
benefit
from
cloud
native
technology
and
get
into
these
advantages?
A
To
answer
these
questions?
I
wouldn't
want
to
take
you
with
me
to
the
journey
we
had
by
answering
this
question
for
our
customer.
It
all
began
with
a
brave
decision
of
a
major
german
insurance
company
cio.
He
decided
to
move
literally
every
web
application
onto
a
cloud
native
stack
pou
and
to
make
it
a
little
bit
more
challenging.
He
also
cancelled
the
contract
for
the
existing
data
center.
It
was
an
on-premises
data
center
yeah.
A
The
chief
architect
took
over
eager
to
explore
and
learn
how
to
migrate
legacy
applications
which
are
not
micro,
service
e,
which
are
not
containerized
and
so
on
on
to
a
cloud
native
platform,
but
that
needs
time.
So
the
CIO
was
very
generous
and
scheduled
one
year
to
finish.
The
migration
tell
you
afterwards
how
many
applications
and
what
are
they
property
their
properties?
So,
but
the
CIO
also
raised
some
priorities
for
the
migration
project.
A
A
A
So
that's
how
we
started
eight
months
ago
sent
today.
I
can
talk
a
little
bit
about
this.
What
we
have
learned
the
last
eight
months
and
what
will
probably
happen
the
next
four
months
as
doubts,
are
the
death
of
each
ambitious
project.
We
also
decided
to
be
as
brave
as
the
decision
itself,
but
we
also
had
some
impediments
to
overcome,
but
we
learned
a
lot
and
so
in
the
following.
Slides
I
want
to
present
you
what
we've
learned
about
the
good,
the
bad
and
the
ugly
of
migrating
legacy
applications
onto
kubernetes.
A
A
A
We
thought
about
how
to
package
and
distribute
these
micro
services
into
containers
and
how
to
dynamically
execute
them
on
the
cloud
the
cloud
native
principles
here,
but
then
it
was
a
little
bit
clear
that
we're
not
facing
a
greenfield
approach.
There
are
a
lot
of
existing
legacy
applications
and
we
knew
nothing
quite
nothing
here
about
those
applications
we
had
to
migrate.
So
our
first
task
was
to
gain
visibility.
A
Here
we
started
by
sending
out
questionnaires
to
all
relevant
applications
to
gain
first
feedback
on
our
fundamental
questions
like
what's
the
technologies
that
they
use,
and
so
it
was
important
what
images
we
should
provide.
What
are
the
required
resources
and
required
amount
of
resources
and
tons
of
this
question?
How
many
application
will
be
hard
to
schedule
on
on
kubernetes
notes?
Also
very
interesting
part
was
those
applications
writing
to
storage,
writing
to
local
storage
or
writing
to
remote
storage.
A
The
amount
of
data
written
there
to
decide
what
storage
solutions
we
should
provide
some
special
requirements
like
native
lips
or
special
hardware
like
printers
or
so
on,
which
is
not
virtualized,
typically
in
a
kubernetes
environment,
and
what
inbound
and
outbound
protocols
are
used.
What's
a
protocol
stack
are
the
TCP
level
or
are
those
HTTP
protocols?
Are
they
secured
by
TLS?
Do
they
use
multicast,
which
is
a
little
bit
of
problem?
A
If
you
use
plain
vanilla
kubernetes
or
do
they
use
dynamic
ports
to
communicate,
which
is
also
a
little
bit
of
problem,
then
we
also
ask
concerning
the
ability
to
execute
for
the
applications.
Are
there
any
tests?
Are
there
any
responsible
persons,
maybe
all
those
applications
running
out
of
life
during
this
year?
This
was
a
very
important
question,
because
only
with
this
questions,
a
question
20%
of
the
applications
were
away
from
our
migration
duty
and
last
but
not
least,
was
an
important
question.
A
What
client
authentication
mechanisms
are
used
and
should
be
poured
it
on
to
our
cloud
solution,
but
this
was
only
the
first
step.
Afterwards,
we
have
written
a
small
code,
a
small
program
called
cloud
eliezer
and
extracted
a
lot
of
data
sources
which
helped
us
to
to
doing
better
decisions
there.
Those
data
sources
were
the
questionnaires,
were
Chara
tasks
of
the
migration
project
were
ie
am
tool,
enterprise,
application
management
tool
were
certain
excel
sheets
and
a
very
important
source
for
our
decision
was
aesthetic
analysis.
A
We
perform
static
analysis
on
all
application
binaries
with
the
IBM
migration
tool.
You
can
see
there
which
libraries
are
used
in
which
je
api's
are
used.
We
used
our
own
cue
validator
to
check
some
dependencies
and
we
used
sonic
qube
to
have
some
quality
metrics
and
all
this
is
integrated
into
something
we
called
migration
database
and
we
performed
analytics
on
this
database.
We
were
using
tableau
to
explore
the
data
there
and
to
answer
architectural
questions,
and
we
also
have
built
a
dashboard
providing
the
projects
and
the
management.
Some
basic
migration
information.
A
That's
the
visibility
part.
Next
good
thing
was
our
approach
to
do
emergent,
design
of
the
target
software
landscape,
because
a
big
design
up
front
and
analyzing
each
nitty-gritty
detail
would
have
been
very
hard
and
time-consuming.
So
we
have
to
start
with
a
little
there's
little
knowledge
and
improve
any
proof.
So
we
did
emergent
design
approach
here.
A
One
part
are
the
more
or
less
old
applications
of
H
between
10
and
15
years,
all
of
those
applications
by
the
way,
j2ee
applications
and
the
more
modern
ones,
and
we
decided
to
migrate
the
older
ones
by
an
approach,
re,
architecting
them
and
making
them
runnable
on
kubernetes
on
Amazon,
Web,
Services
and
the
more
modern
application
we
decided
to
lift
and
shift
them
with
their
virtual
machine
from
the
existing
data
center
into
Amazon
Web
service
into
ec2
there.
Why
only
those
old
applications
at
the
first
step
to
kubernetes
yeah?
A
A
Yeah
after
analyzing
the
migration
database,
we
had
a
pretty
clear
view
of
the
source
architecture
we
had
to
migrate,
we're
coming
from
200
monolithic
applications.
Looking
a
little
bit
like
this,
they
had
a
broad
range
of
back-end
systems
and
infrastructure
systems.
Integrated
they're
using
hosts
using
batch
processing
file,
shares
l,
dubs,
Message
Queuing.
All
that
the
stack
is
based
on
java
6
on
a
j2ee
1.4
application
server
they've
built
an
almighty
legacy
framework
on
top
of
that
hosting
the
application
and
a
basic
httpd
web
layer.
A
The
inbound
traffic
is
TLS
encrypted,
and
this
outbound
traffic
to
the
backend
was
mostly
non
TLS
non-encrypted
in
those
cases,
so
we
came
together
with
a
cloud
operations
team.
We
came
together
with
information
security
officers
and
designed
a
target
architecture
for
all
those
monolithic
applications
and
the
target
architecture
is
about
to
run
on
Amazon
Web
Services
on
a
Huber
Nettie's
cluster.
Actually,
we
were
using
open
ships,
but
only
the
containers,
the
service
parts.
So
it's
pretty
plain
kubernetes
there.
A
It's
based
on
talker
and
JVM:
eight
je7,
a
lightweight
application
server
where
to
port
this
my
almighty
framework,
we
put
it
the
legacy
out
and
now
it's
almighty
framework,
next
generation
and
yeah,
and
then
there
is
an
important
architecture
decision
up
here
to
split
the
applications
into
two
parts:
an
outer
layer
part
in
a
in
a
layer
part.
The
outer
layer.
Part
of
the
application
is
the
part
which
provides
user
interfaces.
A
External
api's
and
for
security
reason
also
has
to
authenticate
and
authorize
the
users
and
the
inner
layer
application,
and
thus
all
those
business
logic
and
backend
integration
things,
and
there
is
a
something
like
a
firewall
in
between
it's
an
API
gateway
and
this
API
gateway
checks.
So
three
requests
from
the
outer
layer
into
the
inner
layer.
If
there
is
a
valid
token,
why?
Well
it
token?
Each
and
every
communication
here
throughout
this
deck
should
be
TLS,
1.2
two-way
encrypted
and
having
an
open,
ID,
Connect
identity,
token
as
payload.
A
A
Should
respect
the
12
factor
apps
principles
there,
and
this
can
be
of
the
first
step
if
some
of
those
applications
are
thriving
towards
cloud
nativeness.
This
is
also
the
good
first
step
so,
but
with
our
migration,
we
targeted
cloud
friendliness
so,
but
if
we
put
the
monoliths
into
a
container
what's
running
in
this
outer
layer
in
our
target
architecture-
and
our
answer-
and
this
answer
has
proven
to
be
right
or
1
on
potential
right
answer-
is
to
place
an
edge
service
on
the
outer
layer.
A
So
we
built
an
service,
and
this
is
the
application
part
residing
in
the
outer
layer
and
the
monolith
is
in
the
inner
layer
and
there
is
the
API
gateway
in
between,
and
the
edge
service
is
responsible
and
to
accept
incoming
requests
which,
which
have
diverse
user
context
care
context.
There
are
some
non
user
context,
cookies
set
header
set
client
certificates.
All
that
and
the
edge
service
then,
is
responsible
to
change
those
diverse
user
contexts
into
an
open-eyed,
be
identity,
token,
and
it
uses
a
token
provider.
A
Central
service
here,
which
is
integrated
with
all
I,
am
systems
and
the
customer
there
more
than
10
and
yeah.
You
can
exchange
the
episodes,
can
exchange
those
diverse
user
context
to
an
identity
token
and
he
cashes
them,
and
if
there
is
a
request
with
no
user
context
set,
he
is
also
responsible
for
redirecting
the
user
to
the
single
sign-on
system
to
sign-on.
So
with
the
edge
service
in
place,
all
authentication
authorization
tasks
are
shifted
into
the
outer
layer
and
the
rest.
A
The
user
interface
is
still
in
the
inner
layer,
yeah,
of
course,
in
our
architecture,
but
provided
by
the
edge
services.
The
outer
layer
only
a
short
glimpse
into
the
internal
structure
of
our
edge
services
based
on
spring
boot
and
Netflix
tool
and
yeah,
basically
is
integrated
with
the
token
provider
here.
A
Next
thing
is
how
to
enhance
our
applications
to
respect
the
12
factor,
apps
principles
or
some
of
them,
and
further
architectural
requirements
on
security
like
TLS
1.2
in
corruption.
All
the
way
here
we
learn
to
love
container
patterns.
The
basic
ones
are
well
described
in
the
paper
below
by
Brendan
Burns
and
David
Oppenheimer,
and
we
used
the
site
cut
pattern
which
enhances
container
application
container
behavior
by
a
site
car
containing
the
same
part.
A
It
was
important
to
save
time
and,
last
but
not
least,
the
adapter
pattern
to
provide
a
homogeneous
interface
of
an
application
to
the
outer
world.
We
used
it
to
yeah
to
adapt
and
the
configuration
mechanism
of
this
almighty
legacy
framework
to
kubernetes
config
maps
and
secrets.
So
Q
Burnett
is
config
maps
and
secrets
were
written
to
files
and
changed
in
the
format
and
inject
it
to
the
other
container.
A
The
last
good
thing
I
want
to
mention
is
about
kubernetes
constraints,
because
initially
we
thought
we'll
run
into
a
lot
of
kubernetes
restrictions
on
our
infrastructure,
because
those
legacy
systems
behave
strange,
like
our
target
infrastructure
didn't
support
multicasts.
There
were
no
overlay
networks
supporting
this
on
play
in
place.
Also,
we
had
no
readwrite
any
persistent
volume
volume
claims
available.
A
So
we're
a
little
bit
scared
this
restrictions
and
we
did
for
quite
a
lot
of
those
applications,
but
but
cutting
this
application
requirements
and
RER
collecting
these
applications
not
being
dependent
on
multicast
and
not
being
dependent
on
read/write.
Any
persistent
volume
claims
led
to
a
better
architecture
of
those
applications,
so
we
were
ok
with
this
end
was
and
didn't
produce
that
much
much
effort
to
refactor
the
apps
accordingly.
A
So
this
were
the
good
parts.
Now,
let's
get
into
the
bad
side
of
cloud
migration,
life
and
yeah.
One
bad
side
is
state
state
within
the
clouds
yeah.
Sometimes
micro
services
suggesting
there
is
no
state
in
applications,
but
there
is
state
in
applications
and
in
legacy
applications.
There
is
state
in
a
lot
of
different
representations.
A
The
first
representation
is
state
within
databases.
Here
we
made
our
life
a
little
bit
easier
by
letting
those
databases
int
in
the
on-premises
data
center.
We
didn't
migrate
databases
to
Amazon
Web
Services.
They
were
still
in
their
own
premises
or
their
right
now,
still
in
the
on-premise
data
center
and
we're
using
them
from
our
monoliths
in
the
MSM
cloud
directly.
A
Potential
disadvantage
here
could
be
that
there
is
more
latency,
but
this
wasn't
a
problem
for
us
as
the
cloud
interconnect
in
between
Amazon
Web
Services
and
the
on-premises
data
center
was
quite
good
yeah.
There
was
merely
no
latency
impact
there,
but
we're
two
advantages:
the
application
versions
on
Prem
and
in
the
new
cloud
native
platform
that
can
run
in
parallel,
which
is
where
what
is
very,
very
good.
When
you
launch
those
applications,
you
can
have
smooth
throwback
to
the
old
version
and
yeah.
A
A
A
Openshift
somehow
provides
session
stickiness,
but
in
my
opinion,
in
our
opinion,
in
McLeod,
where
everything
fails,
all
the
time
is
rescheduled
everytime
session
persistence
is
not
the
way
to
go
session.
Stickiness.
Sorry,
it's
not
the
way
to
go
next
step.
Was
we
considered
about
session
persistence
so
writing
session
data
of
the
application
in
the
existing
application
database?
But
the
performance
impact
here
was
high
because
there
were
many
rights
and
many
reads
and
the
application
slowed
down
immensely.
A
So
I
got
for
session
synchronization,
not
using
the
application
server
mechanism
here,
because
this
application
server
we
used
wasn't
able
to
look
up
the
peers
within
kubernetes.
So
next
try
was
to
use
hazel
cast
as
in-memory
data
grid
to
synchronize
session
state,
but
hazel
cast
costs
a
lot
of
money.
If
you
want
to
use
TLS
and
session
synchronization
with
TLS
and
paying
a
six-digit
amount
of
euros
was
not
the
way
to
go
in
our
opinion.
A
A
Apache
ignite
provides
peer
lookup
within
cuber
Nettie's,
now
automatically
peer
lookups
a
little
bit
cumbersome,
but
it
works
fine
and
yeah
this
just
for
you
to
mention,
because
this
this
was
three
or
four
engineering
days
to
fix
this
bug.
Ignite
has
an
just-in-time,
compiler
bug
on
the
IBM
JDK
or
JVM,
so
some
classes
have
two
being
excluded
there.
We
had
to
use
IBM
jedikiah
yeah.
This
is
about
session
persistence.
A
So
next
thing
is
about
diagnose
ability,
I,
don't
this
guy
is
not
relevant
here,
but
I
only
want
to
place
the
super
here
of
my
my
childhood
in
some
of
my
slides
okay.
So
next,
what's
about
diagnose
ability?
The
Ignasi
bility
is
the
ability
to
observe
applications
and
to
diagnose
them
in
if
they're
running
in
an
abnormal
state,
and
it's
all
about
integrating
traces,
metrics
and
events
yeah,
and
our
first
solution
was
to
go
for
Prometheus,
metrics,
fluent
II
and
the
efk
stack
behind
for
events
and
logs
and
open
tracing
implementations.
A
It's
feasible,
but
we
were
not
sure
if
we
had
enough
time
and
also
one
instance
of
from
easiest
Zipkin
and
fluent
fluent
ears.
If
caustic
per-application
was
too
much
efforts
for
the
applications,
so
we
decided
to
do
an
easy
move
and
now
the
whole
cluster
is
instrumented
by
dynaTrace
as
application
performance
monitoring
solution,
but
it's
a
placeholder
for
any
commercial
performance
management
tool
which
is
pre
integrated
with
kubernetes
and
in
suffers
the
needs
here.
So
we're
not
using
those
fancy
cloud
native
projects
here,
but
it's
instrumentalist
dynaTrace.
A
Once
again,
my
friend
we
came
far,
we
have
at
service
in
place,
TLS,
1.2,
2
way
and
those
identity
tokens
all
the
way.
Also
security
filters
enhanced
here
at
the
edge
service
level.
At
the
application
level,
we
enhanced
it
the
application
by
performing
client
certificate,
ACLs
and
token
checks
and
with
egress
rules
towards
a
back-end
to
protect
potential
malicious
containers
for
accessing
all
those
backends.
A
But
there
is
one
thing
remaining
with
a
huge
problem
with
certificate
management
right
now.
Three
full-time
employees
are
doing
nothing
more
than
scanning
where
certificates
are
not
valid
anymore
or
where
is
a
new
need
for
C
certificates,
issuing
those
certificates
and
delivering
those
certificates
to
be
provisioned
into
the
containers
and
that's
the
current
state.
A
This
line
of
code
is
representative
for
the
ugly
parts
and
the
hostess
pocus
the
host
integration.
We
saw
very
ugly
since
they're
how
hosts
are
integrated
and
so
on.
It's
mostly
about
cloud
enabling
cloud
aliens,
they're
wet
toxic
technology.
This
is
technology
which
is
not
supported
and
maintained
anymore,
and
especially,
it
was
our
almighty
legacy
framework.
A
The
other
parts
were
decorate:
the
applications
with
ambassadors,
sidekick
source
ID
cards
and
adapters,
and
in
one
or
two
cases
we
decided
to
not
migrate
certain
api's
of
the
legacy
framework
and
having
applications
to
do
to
migrate
to
another
API
yeah,
that's
the
ugly
side.
So
where
are
we
now
right
now
about
100
systems?
A
This
is
possible
because,
after
doing
some
upfront
work,
we're
now
launching
tens
of
applications
each
week
and
the
other
200
systems
will
be
migrated
also
by
end
of
first
quarter,
2018
with
this
virtual
lift
and
shift
approach
and
will
migrate
them
to
kubernetes
by
mid
of
2019
or
so
so,
but
will
meet
the
requirement
of
our
CIO
that
it's
done
within
a
year
so
that
what
we've
learned
from
our
migration?
It's
not
a
stupid,
just
put
monoliths
into
containers
approach.