►
From YouTube: Migrating Enterprise Microservices From Cloud Foundry to Kubernetes – T. Erwin & J. Schweikhart
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Migrating Enterprise Microservices From Cloud Foundry to Kubernetes – Tony Erwin & Jonathan Schweikhart, IBM
Historically, the forty microservices making up the IBM Cloud UI have been deployed as apps on Cloud Foundry (CF), an open source PaaS. But, recently, this enterprise microservice system has been migrated to run on Kubernetes to take advantage of improved orchestration, higher availability, and better performance. Tony Erwin & Jonathan Schweikhart will discuss their journey and provide insights into the advantages of Kube over CF. Even more importantly, they will describe approaches to solving new problems that took the place of old ones, such as: 1) adapting PaaS apps to run as containers on Kube, 2) enabling geo load balancing between the different platforms (to vet Kube before entirely replacing CF), 3) integrating tools like Prometheus into existing monitoring systems, and more! Their team's experiences will help you avoid pitfalls as you look to perform your own migrations to Kube!
To learn more click here: https://sched.co/H2GT
A
Hey
good
morning,
Nihao
welcome
to
I.
Guess
it's
the
first
session
after
the
keynote.
So
thanks
for
coming
by
can
people
hear
me:
okay,
with
a
mic,
so
I'm
gonna
talk
today
about
some
experiences.
We've
had
with
an
Enterprise
micro
service
system,
the
IBM
cloud
console
in
particular
experiences.
We've
had
moving
that
from
Cloud
Foundry
to
kubernetes.
My
name
is
Tony
Irwin
I'm,
a
senior
technical
staff
member
at
IBM
I
had
a
colleague
Jonathan
Schweich
r2,
who
co-authored
these
slides,
but
he
was
not
able
to
make
the
trip
son.
A
So
a
quick
agenda
I'm
going
to
give
an
overview
of
the
console.
The
app
that
I
worked
on
talked
a
little
bit
about
what
cloud
foundry
is
what
kubernetes
is
and
why
we
wanted
to
switch
in
the
first
place.
Then
we'll
talk
about
some
specific
experiences
and
things
we
learned
along
the
way
and
then
we'll
conclude.
A
So
the
the
IBM
cloud
console
is
a
is
a
pretty
large
UI
made
up
of
a
number
of
Micra
services
which
we'll
get
into
in
a
second
that's
kind
of
the
front
door
to
the
IBM
cloud.
So
it
allows
you
to
manage
all
of
your
ayahs
and
pass
resources
you
might
create
in
the
cloud
also
allows
you
to
see
your
billing
info
system
status
stops,
managed,
Identity
and
Access
Management.
All
that,
as
as
part
of
the
the
console.
A
That
this
chart
shows
a
basic
overview
of
the
console
architecture
about
five
years
ago
or
so
we
started
this
project
and
we
started
that
out
as
a
as
a
monolithic
app.
So
we
had
a
Java
back-end
with
a
dojo
based
front-end
and
we
found
over
time.
I
could
give
a
whole
talk
about
why
we
left
the
monolith
to
go
to
microservices,
but
you
know
it
wasn't
really
scalable
for
what
we
wanted
to
do.
We
wanted
other
teams
to
be
able
to
contribute
easily
on
their
own
schedules,
etc.
A
So
we've
we
slowly
evolved
that
model
at
the
gap
to
a
micro
service
system
which
now
has
about
50
different
micro
services.
The
the
chart
here.
The
diagram
basically
shows
the
console
client,
which
is
the
browser,
makes
a
connection
into
the
our
proxy,
our
reverse
proxy,
which
does
all
the
routing
to
our
different
micro
services,
so
slash
catalog
would
go
to
our
catalog
micro
service
things
like
that.
All
these
micro
services
talk
to
back-end
API,
is
from
the
IBM
cloud
and
we
also
have
a
set
of
I
mentioned,
other
teams
wanting
to
contribute,
etc.
A
A
So
so
what
is
cloud
foundry?
So
it
provides
a
platform
as
a
service
pass
with
a
really
abstracting
at
the
application
layer
developers
can
focus
on
code
rather
than
underlying
infrastructure.
It
leverages
the
open
service
broker
API.
So
that
is
easy
to
use
services
from
apps.
It
uses
Diego
containers
internally,
you
know
it's
a
pretty
pretty
cool
technology.
I
will
note.
A
I've
got
a
an
asterisk
at
the
bottom
that
I'm
really
talking
about
the
cloud
application
or
the
cloud
foundry
application,
runtime
environment
there
are,
you
know
it's
one
of
the
two
open-source
components
really
that
make
up
what
people
call
cloud.
Foundry
kubernetes
has
a
slightly
different
model
abstracting
at
the
container
level.
Some
people
call
this
I
as
plus
it's
got.
You
know
same
benefits
a
lot
of
the
same
benefits
as
as,
but
the
flexibility
of
is
in
fact
you
can
even
deploy
Cloud
Foundry
on
top
of
kubernetes.
A
A
So
why
did
we
switch
so
there's
nothing
really
wrong
with
Cloud
Foundry,
it's
very
easy
to
get
apps
running,
to
get
started,
to
focus
on
your
toad
and
get
it
deployed
and
running,
and
it's
used
by
at
least
half
of
the
fortune
500
in
some
capacity
or
another.
So
it's
pretty
widely
used
technology,
but
we
felt
like
kubernetes,
offered
a
number
of
advantages
for
our
use
cases
it.
A
You
know
and
I've
got
a
whole
list
here
that
we
could
go
on
for
a
long
time
about,
but
you
know
more
more
granular
control
of
our
large
complex
microservice
system.
As
I
mentioned,
you
know,
50
micro
services
and
Counting.
We
we
had
some
problems
in
our
Cloud
Foundry
deployment,
because
we
were
sharing
it
with
other
people.
So,
by
moving
to
kubernetes,
we
were
able
to
spin
up
dedicated
clusters
and
avoid
some
of
this
friendly
fire.
A
Now
in
fairness,
you
can
also
deploy
cloud
foundry
in
separate
clusters,
so
we
could
have
also
done
it
that
way
with
the
especially
with
the
IBM
implementation
of
cloud
foundry.
By
moving
to
kubernetes,
we
had
a
much
simpler
front
door.
You
know
basically
a
network
path
into
our
cluster.
Now
we
can
really
focus
on
configuring,
our
our
engine,
X
ingress
within
the
cluster,
and
we
don't
have
some
of
the
appliances
and
things
that
were
in
front
of
us
in
cloud
foundry.
A
Private
host
names
is
another
reason
we
wanted
to
move.
So
this
is
a
micro
service
system
and
all
the
host
names
in
Cloud
Foundry
are
public.
We
didn't
really
want
people
from
outside
of
the
console
to
call
these
microservices
without
going
through
the
proxy,
so
kubernetes
allowed
us
to
solve
that.
We
also
saw
a
nice
performance
gain
by
using
the
private
networking
in
kubernetes
so
that
you
can
make
direct
calls
from
micro
service
to
micro
service
without
leaving
the
cluster,
whereas
in
Cloud
Foundry
we
were
doing
a
pretty
large
network
hops.
A
A
So
this
this
next
part
of
the
talk
will
talk
about
some
of
the
specific
issues
that
we
had
moving
from
Cloud
Foundry
on
to
kubernetes,
and
you
know
some
of
the
lessons
learned
along
the
way
this
chart
is
really
just
comparing
the
Cloud
Foundry
flow
with
the
Kubb
flow,
so
in
Cloud
Foundry
you've
got
a
node
application.
You
do
you
have
a
manifest
file
that
says
some
things
about
the
app
name
etc,
and
you
do
from
the
command
line.
A
You
can
do
what's
called
a
CF
push
command
and
then
ultimately,
Cloud
Foundry
puts
that
app
and
runs
it
in
a
Diego
container.
The
Kubb
flow
is
still
very
pretty
similar,
but
but
there
are
some
differences
along
the
way.
If
you
still
have
your
node
application,
but
instead
of
doing
a
CF
push,
you
build
a
docker
image
for
that
node
app
and
then
you
use
held
to
install
it
into
the
cluster
I
mentioned.
Cloud
Foundry
has
a
manifest
file,
so
we
did
have
to
deal
with
migrating
that
manifests
to
helm,
charts.
A
A
A
I
did
to
the
fact
that
all
the
host
names
and
Cloud
Foundry
were
public.
So
you
know
one
of
the
differences
we
had
was
you
know
in
caught,
foundry
the
public
URLs
were
available,
obviously
to
everyone.
Each
Micra
service
could
be
directly
accessed
from
the
internet.
You
know
which
brings
some
additional
security
concerns.
A
You
know
common
code
that
has
to
be
repeated
in
kubernetes.
You
can
choose
the
exposure
to
give
to
your
micro
services,
so
a
service
within
kubernetes.
You
can,
you
know,
have
only
internal
routes,
so
so
the
private
networking
I
mentioned
before
and
then,
if
you
set
up
the
ingress,
you
can
set
up
rules
that
do
allow
folks
from
the
outside
to
get
to
microservices.
A
A
A
Those
don't
exist
in
kubernetes,
but
we
like
for
vcap
services
we
were
able
to
with
our
deployments
basically
set
up
that
same
environment
variable
with
the
information
that
you
would
expect
in
cloud
foundry.
It's
basically
be
cat
services.
Basically,
the
you
know
the
host
names
and
credentials
and
things
you
need
to
get
two
different.
You
know
say
you,
you
say
you
have
a
no
SQL
database,
B
cap
services
and
Cloud
Foundry
would
would
have
all
the
information
you
need
to
connect
that
Cloud
Foundry
or
to
that
no
SQL
database.
A
So
we
basically
had
to
make
that
available
in
the
kubernetes
deployment
of
those
apps
as
well.
The
you
know
we
had
some
issues
in
the
code
with
URL,
formatting
I
would
say
it
probably
wasn't.
You
know
well
coated
to
some
extent
in
some
pieces,
but
when
Cloud
Foundry
you
know
we
had
a
whole
fully
qualified
host
name
for
these
services.
A
You
know
in
this
case
of
ACE
common
production,
us-south
bluemix.net
in
true
Burnett
ease.
You
know
that
same
my
cursor
vez
internally
at
least,
would
just
be
accessed
with
HTTP
common.
There
was
code
in
place
that
were
constructing
URLs,
based
on
on
the
more
fully
qualified
domain
name.
So
so
just
you
know
things
like
that
that
we
had
to
deal
with
in
our
common
code.
But
you
know,
with
with
a
few
tweaks,
we
were
able
to
get
all
that
working
so
that
it
could
the
node
apps
could
run
in
both
environment.
A
I
mentioned
before
one
of
the
nice
things
we
liked
about
kubernetes
was
being
able
to
install
other
services
that
our
apps
may
want
or
need.
Since
this
is
a
UI
system,
we
have
a
need
to
share
session
state
across
our
micro
services,
so
we
use
Redis
for
that
in
our
Cloud
Foundry
world.
On
the
left-hand
side,
here
we
had,
you
know,
had
to
deploy
Rattus
completely
separate
from
from
our
environment.
We
had
some
VMs
that
we
used
to
deploy
all
that,
and
you
know,
then
you
know
you
add.
A
When
we
move
to
kubernetes,
we
didn't
have
such
easy
access
to
that
same
information,
or
at
least
in
a
way.
You
know
we
could
get
to
the
logs
and
such,
but
not
you
know
able
to
easily
mine
that
info
and
look
at
real-time
charts
of
that
info.
So
we
configured
engine
X
to
log
just
syslog,
and
then
we
created
a
micro
service
that
basically
scraped
that
information
and
gave
us
exactly
the
same
info
that
we
had
previously.
So
that's
that's
been
pretty
powerful
for
us.
A
One
other
area
that
maybe
was
a
little
bit
unique
to
our
situation
is
since
we
do
have
a
big
Micra
service
system
that
together
makes
up
our
our
UI.
We
we're
changing
some
of
this,
but
but
right
now
we
still
have
a
little
bit
of
a
monolithic
deployment.
Actually
so
so,
basically,
we
have
two
copies
of
our
micro
services
running
one
in
a
red
namespace
and
the
other
in
a
black
namespace.
A
So
at
any
given
time
the
actual
production
Micra
services
may
be
in
black
or
red,
and
then
the
the
code
waiting
to
be
promoted
is
running
and
the
other
one.
So,
basically,
when
it
comes
time
to
promote,
on
the
right
hand,
side
our
live
URL
and
on
Dec
URLs
are
just
basically
swapped,
so
that
if
red
had
our
head,
what
we
wanted
to
be
in
production,
it's
now
at
the
live,
URL
and
black
would
be.
You
know,
basically
demoted
them.
A
If
you're
familiar
with
kubernetes,
you
know
that
in
cloud
foundry
we
didn't
really
have
this,
but
each
microservices
is
able
to
implement
a
readiness
and
aliveness
check
which
basically
allows
kubernetes.
You
know
all
the
all
the
orchestration
capabilities
of
kubernetes
know
if
your
your
apps
are
ready,
if
they're
they're
down,
if
they
need
to
be
restarted,
etc,
I
mean
Cloud,
Foundry
didn't
really
have
you
know,
there's
a
health
manager
that
will
restart
your
apps
your
instances
of
your
abs
if
they
they
crash.
But
it's
more
like
this.
A
Oh,
we
can't
connect
to
it
or
we
think
it's
dead.
So,
let's
restart
it,
whereas
you
get
a
little
bit
again.
Finer
grained
control
in
kubernetes
I
alluded
to
the
fact
that
we
wanted
to
have
the
code
being
able
to
run
in
cloud
foundry
and
kubernetes
at
the
same
time.
The
reason
for
that
is
because
we
were
developing
at
the
same
time
and
we
also
wanted
to
vet
what
we
were
doing
in
kubernetes.
Alongside
what
we
were
doing
in
cloud
foundry.
A
A
A
So
so
this
geo
load-balancing
when
we
implemented
it,
really
helped
our
uptime
and
our
you
know
we
use
page
or
duty
internally.
You
know
it
really
reduced
the
the
number
of
times.
Page
or
duty
alerts
had
to
be
sent
out
to
something
at
2:00
a.m.
to
come
fix
a
problem
because
we
would
just
fail
over
and
use
another
deployment
the
so
we
was
we
had
all
that
set
up
for
Cloud
Foundry
is
the
point
and
then,
when
we
wanted
to
start
introducing
our
tube
clusters,
we
kept
the
same
same
infrastructure.
A
You
know
with
Akamai
and
dying
up
top,
but
in
our
diner
rule
we
started
introducing
the
purple
boxes
over
there,
which
are
kubernetes,
so
we
actually
had
cloud
foundry
deployments.
The
green
boxes,
green
boxes
up
there
running
side
by
side
with
our
kubernetes
deployments
and
we
had
the
same
geo
load,
balancing
and
failover
ability
in
place.
And,
of
course,
if
we
had,
you
know,
turned
on
kubernetes,
you
know
wasn't
working
correctly.
We
could
fail
back
and
remove
all
those
clusters
and
just
use
our
our
Cloud
Foundry
deployments
and
then
over
time
we
were.
A
We
got
satisfied
with
what
we
were
doing
with
kubernetes,
so
we
eliminated
all
of
our
Cloud
Foundry
deployments
and
just
left
with
purple
boxes
which
are
all
of
our
kubernetes
deployments.
So
so
it's
kind
of
a
practical
consideration
of
if
you're
migrating
from
one
of
these
technologies,
in
this
case
CF
to
kubernetes.
You
know
you
need
to
consider
about
how
you're
going
to
roll
that
out
and
that's
the
way
we
did
it
and
that
kind
of
brings
us
to
the
end.
Just
a
couple
closing
remarks:
pod
foundry
is
a
great
technology.
A
So
this
isn't
a
this
presentation
isn't
meant
to
be
be
negative
towards
cloud
foundry,
but
kubernetes
better
met.
Our
needs
better
meets
our
needs.
However,
nothing
is
free
if
you
move
from
Cloud
Foundry
to
kubernetes,
as
as
described
along
the
way
new
problems
arise
that
you
have
to
solve,
but
in
the
end
we
believe
this
was
well
worth
it
for
us.
We
were
able
to
achieve
greater
performance,
scalability,
reliability,
etcetera.
Then
we
had
before
so
so
we're
really
glad
we
made
the
move
and
so
I
guess
are
there
any
questions
at
this
point.
A
B
A
B
I
guess,
on
the
kubernetes
side,
you
used
mostly
standard
tools
like
you,
control,
helm
and
everything
and
from
a
developer
standpoint
of
view,
when
you
moved
from
your
java
monolith
to
I.
Guess
if
I
understand
correctly,
you
moved
to
note
no,
the
backends
microservices
yep.
So
it's
a
big
change.
It.
A
So
so
I
have
whole
presentations
where
I
go
in
Turkey
from
pondless
to
micro
services
as
well
I
think
when
we
started,
we
were
probably
a
bit
naive
what
it
was
kind
of
take
so
I,
don't
know
that
we
necessarily
used
all
the
best
tools
and
best
practices
along
the
way,
but
but
really
what
we
did
there.
You
know
we
had
a
the
java
monolith.
As
you
mentioned,
we
tried
to
find
slowly
over
time
like
various
pieces
that
could
be
pulled
apart,
so
we
so
we
started
building
these
node
Micra
services.
A
A
You
know
the
difference,
different
tools
you
might
use
with
node
than
with
Java,
and
you
know
we,
the
team,
had
to
gain
gain
those
skills.
At
the
same
time,
we
were
doing
that
and
in
maintaining
the
product.
So
so
it
really
took
us.
You
know,
probably
two
years
to
fully
get
rid
of
the
monolithic
app
and
have
just
node
node
micro
services.
I,
don't
know
if
that
answers
your
question
about
tooling
and
stuff,
but
yeah
now
I
feel
like
we.
You
know
we
use
pretty
good.
A
B
A
We
we
don't
really
dictate
to
our
team.
What
IDs
and
things
to
use
I
mean
I
I
personally
use
sublime
text,
you
know
others,
you
know
that
and
you
wouldn't
really
call
sublime
an
ID
either.
Necessarily
so
I.
Don't
know
that
I
have
one
blanket
recommendation
there,
but,
but
we
do
have
a
the
big
thing
we
have
set
up
is
that
you
can
run.