►
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
Strategies to "Kubernetify" Legacy Applications - Sai Vennam, IBM
Microservice-based architectures have seen large-scale adoption and have become the industry standard for developing cloud-native applications. This growth is supplemented by key technologies like Docker, Kubernetes, Istio and many more. When modernizing legacy apps, migrating everything to a cloud-native architecture in a "Big Bang" approach is not feasible as it can be time consuming and prone to failure. In this talk, I'll outline key strategies to modernize legacy applications without sacrificing agility, quality and high-availability. In addition, I'll walk through a modernization path with a sample app.
https://sched.co/MPXo
A
Hello,
everyone
and
welcome
I
will
keep
my
introduction
to
this
very
exciting
session
short
and
sweet.
This
next
session
is
strategies
to
kubernetes
I
your
legacy
application
and,
judging
by
the
size
of
this
crowd,
I
think
this
is
a
very
relevant
topic
to
lots
of
us
in
this
room.
So
without
further
ado,
I'd
like
to
welcome
side
to
the
stage
he's
a
developer
advocate
at
IBM,
so
welcome
yeah.
B
Wow,
this
is
just
a
little
bit
intimidating,
but
I'm
super
excited
and
actually
honored
to
be
able
to
talk
to
all
of
you
today.
The
kubernetes
community
is
so
talented
and
to
have
I
wanted
to
be
up
here
and
talk
about
this
I'm
really
excited
so
again.
I
am
sy,
sy
venom,
I'm,
a
developer
advocate
and
a
product
manager
on
IPM
cloud,
but
without
further
ado.
Let's
go
ahead
and
get
started,
I
like
to
get
started
with
the
quote
usually-
and
this
is
from
Gardner,
essentially
every
dollar-
that
an
enterprise
invests
into
digital
business
innovation.
B
So
this
is
things
like
adopting
container
of
runtime
technology
kubernetes
the
latest
and
greatest
cognitive
and
AI
capabilities
out
there.
Any
kind
of
dollar
that's
invested
in
those
and
enterprise
would
instead
have
to
spend
three
times
as
much
if
they
were
to
only
strictly
continuously
modernize
their
application.
B
So
let
that
sink
in,
but
there's
a
balance
to
be
made
right.
So
you
can't
just
ditch
everything
that
you
have
all
of
this
legacy:
application
architecture
and
start
from
scratch.
There's
any
of
kubernetes
failure
stories
out
there
that
explain
exactly
why
you
shouldn't
do
something
like
that.
So
so
you
gotta
have
that
balance
between,
modernizing
and
and
taking
your
legacy
architecture,
but
also
innovating
and
taking
advantage
of
all
these
awesome,
AI,
cognitive
capabilities
that
are
out
there
or
maybe
even
just
container
or
kubernetes
technologies.
B
One
other
number
here
so
kind
of
goes
hand-in-hand
with
that
three,
the
three
number
and
that
last
slide
so
taking
advantage
of
container
technology
we've
seen
that
the
costs
are
reduced
as
well
as
app
downtime.
So
better
user
experiences
lower
costs.
Yes,
there's
the
upfront
cost
of
kind
of
teaching
your
company
and
getting
everyone
kind
of
ramped
up
on
these
technologies,
but
at
the
end
of
the
day,
the
the
numbers
speak
for
themselves.
So
why
are
we
here
today?
B
We're
gonna
be
talking
about
modernization,
I
made
hotel
where
kubernetes
I,
so
we're
going
to
be
talking
about
kubernetes
fiying
applications.
If
you
take
these
keywords,
you
know
and
throw
them
in
Google,
maybe
combine
them
with
something
like
legacy.
Applications
you'll
see
hundreds,
maybe
even
thousands
of
articles
saying
yes,
you
should
do
this.
B
So
here's
here's
my
perspective,
the
idea,
the
way
I
see
it.
You
either
evolve
or
you
fall
behind
and
I
don't
have
to
convince
this
crowd
because
I
know
for
a
fact
that
everyone
here
knows
that
kubernetes
is
the
future
right.
It's
it's
the
way
to
move
forward.
It's
it's!
It's
essentially
what
we
want
to
do
when
we're
working
with
our
legacy,
applications
and
we're
thinking
about
modernizing
so
I'd
say.
There's
four
major
reasons
why
you
would
want
to
modernize,
so
let's
go
through
them
really
quickly
here
so
for
one
you
can
escape
vendor
lock-in.
B
So
I
think
this
is
amazing.
Actually
so
kubernetes
I
think
this
is
revolutionary.
The
fact
that
every
major
cloud
provider
has
a
kubernetes
offering
and
and
and
the
fact
that
it's
open
source
and
there's
this
huge
community
of
everyone
from
all
of
these
different
providers
and
users
that
are
here
today
and
not
only
that
we're
celebrating
kubernetes
fifth
birthday
here
and
then
Barcelona
I
can't
think
of
a
better
place
to
do
it.
So
I'm
gonna
ask
everyone
a
huge
favor.
B
B
Thank
you
so
much
everyone
that
was
a
lot
better
than
I
expected,
but,
okay,
let's,
let's
get
back
to
it,
so
we
talked
about
escaping
vendor
lock-in.
Next,
let's
talk
about
the
fact
that
you
know
when
you're,
taking
advantage
of
these
kubernetes
or
kubernetes
on
on
top
of
cloud
providers
and
that
kind
of
thing
you
get
to
reach
multiple
geographies
data
centers
across
the
world.
In
addition,
that
means
you
unlock
essentially
unlimited
resources.
I
can't
imagine
a
case
where
anyone
would
actually
hit
that
limit
of
what
a
cloud
provider
can
provision.
B
Then,
at
that
point
just
go
to
the
next
one.
So
you
know
that's
that's
one
of
those
awesome
kind
of
capabilities
and
that
you
get
with
this
modernization.
And
finally,
you
know:
I
talked
about
vendor
lock-in
and
avoiding
it,
but
sometimes
you
can
take
advantage
of
new
integrations
that
work
best
in
certain
clouds
and
in
addition
say
you
have.
You,
know
financial
data
or
something
that
you
want
to
secure
on
Prem.
B
Well,
sometimes
you
want
to
make
sure
that
your
private
cloud
stays
private.
You
keep
those
integrations
there
and
then
you
create
new
cloud
native
applications
and
new
applications
in
the
clouds
and
in
addition,
you
know
we're
gonna
actually
show
off
in
this
talk
integrations
with
some
with
some
cool
third-party
services
out
there,
so
messaging
services
and
cognitive
stuff.
Maybe
you
can
guess
but
I'll
keep
it
as
a
surprise
for
later
so
the
way
I
see
it.
B
So
that's
a
kubernetes
cake
that
we've
got
right
there
and
we've
got
a
recipe
to
essentially
kubernetes
fie
right
and
I.
Don't
see
this
as
a
three-step
process.
I
three
I
see
this
as
three
ingredients
to
be
able
to
kubernetes
fie
and
the
way
I
say:
there's
gonna
be
lift
and
shift.
So
that's
something
that
I'm
sure
a
lot
of
us
have
heard
in
the
past
before
essentially
taking
your
applications
and
moving
them
into
the
cloud
and
not
even
necessarily
refactoring
much
we're
modernizing
them,
literally
just
moving
them
into
the
cloud.
B
It's
a
number
of
advantages
for
that.
We'll
talk
about
them,
there's
innovation,
so
taking
advantage
of
new
integrations
moving
to
the
cloud
and
taking
advantage
of
integrations
there
and
then
deconstruction
and
refactoring.
This
is
when
you
start
paying
off
that
technical
debt.
This
is
this
is
where
you've
got
to
figure
out.
Where
do
I
start
breaking
things
apart,
take
a
support.
B
All
right,
I'm
sure
everyone
recognizes
this
ugly
parrot
I
think
when
this
app
first
came
out,
I
think
I
was
like
10
or
11
years
old,
but
way
back
in
the
day
this
was
called
jpetstore.
It
was
introduced
to
essentially
showcase
the
awesome
capabilities
of
j2ee
platforms,
but
nowadays
it's
more
used
as
kind
of
an
example
of
modernizing
so
taking
this
ancient
java
application
and
pulling
it
into
kubernetes
or
whatever
modern
technologies
there
might
be.
So
that's
what
my
talk
is
gonna
be
center
around
today.
Excuse
me.
A
B
Gonna
be
coumarin
edifying,
this
java
application.
So
let's
talk
about
the
old
architecture,
real
quick,
and
so
if
you
got
a
user
who
in
turn
hits
a
java
web
app,
that's
maybe
in
a
VM
somewhere
that
in
turn
to
kind
of
pull
information
about
pets
and
store
information,
it's
gonna
access,
a
sequel
database
and
for
the
sake
of
this
example,
let's
imagine
that
that
sequel
database
is
on
like
a
private
cloud.
B
Maybe
it's
on
Prem
say
we
have
like
Enterprise
license
that
keeps
it
a
che
and
backed
up,
and
you
know
we
probably
paid
a
million
dollars
for
it
over
the
years.
But
let's
say
like
that's:
that's
the
kind
of
back-end
for
it.
So
the
first
strategy
that
we're
gonna
talk
about
here
that
first
ingredient
is
lift
and
shift.
So
the
biggest
advantage
I
would
say
with
that
is
the
ability
that
the
fact
that
you
get
speed
when
going
to
market.
B
Essentially
what
that
means
say
that
you
know
this
pet
store
application
owner
say
that
Easter
is
coming
up
and
they
know
that
a
lot
of
little
kids
are
gonna
want
to
buy
bunnies,
just
whatever
just
go
with
it.
So
they
what
they
want
to
do
is
be
able
to
quickly
modernize
that
application
in
time
and
they
notice
that
last
year
the
application
crashed,
because
there
were
so
many
people
trying
to
hit
the
app.
So
they
need
to
quickly
containerize.
B
It
move
it
into
the
cloud
and
get
resources,
but
they
don't
have
unlimited
money
either
right,
so
they
can't
afford
to
scale
out
VMs,
because
that
just
adds
cost
way
too
quickly,
and
so
they
decide
to
go
with
an
approach
to
kind
of
containerize
their
application
kubernetes.
I
it
to
make
better
use
of
the
resources
and
to
do
so,
there's
a
couple
of
strategies:
they'll
gonna,
they're,
gonna
kind
of
implement
so
extracting
config
and
and
persistence
for
stateful
apps
and
that
kind
of
thing.
But
one
thing
I.
B
You
can't
forget
here
just
because
you're
doing
this
lift
and
shift
and
moving
to
the
cloud
doesn't
really
mean
your
cloud
native
you're,
just
creating
technical
debt
for
yourself.
At
this
point
now
you
have
two
environments.
You
have
to
manage
your
on-prem
side,
the
cloud
side
and
the
cloud
side
is
in
really
even
cloud
native
and
yeah
you're
using
kubernetes.
But
you
know
it's
still,
not
the
most
efficient
way
of
scaling
and
if
you're
not
you
know,
breaking
them
apart
into
micro
services.
B
So
let's
go
ahead
and
start
this
demo
and
let
me
just
you
know
what
I
was
on
the
hotspot
before
and
it
dropped
off,
but
so
I
actually
know
I'm
still
on
the
hotspot,
so
we're
gonna
hope
this
works
and
let's,
let's
go
ahead
and
get
started
here.
So
first
things:
first,
what
is
the
the
pet
store
application
so
I
have
the
kind
of
the
old
version
of
it
running
and
so
essentially
you're
gonna
see
it
in
a
second
here
once
it
loads.
You
know
everyone's
favorite
java
application
see
things
like
the
number
of
fish.
B
You
have
dogs
whatever
it
might
be.
You
can
drill
in
deeper
it's
a
card
service
signing
and
signing
out
that
kind
of
thing.
So
this
is
essentially
a
java
application.
So
if
we
want
to
take
a
look
at
the
code,
you
know
we
can
kind
of
drill
in
here
so
I'm
in
the
wrong
directory.
So
we'll
go
here,
real,
quick,
jpetstore,
kubernetes
and,
let's
see,
and
then
one
more
folder
in
okay.
Here
we
go
so
if
you're
familiar
with
Java,
then
you
might
recognize
some
of
this
stuff
here.
I
hope,
that's
big
enough!
B
I
can
probably
make
it
a
little
bit
bigger
for
you.
So
you
can
see
things
like.
You
know
the
source
code,
the
wor
that
gets
generated,
but
what
we
want
to
do
first
is
take
this
application
and
just
straight
up
docker
eyes
it
and
yeah.
We
know
it's
a
monolithic
application,
there's
a
lot
of
services
in
there,
but
you
know
you
can
still
docker
eyes
monolithic
applications.
So
what
we've
got
here
is
a
docker
file.
B
B
This
repository-
and
this
can
happen
very
quickly
because
I
didn't
change
anything
and
that
was
on
purpose
because
I
didn't
want
it
to
do
anything
during
the
actual
demo,
so
very
quickly.
It's
actually
created
that
docker
container.
If
we
wanted,
we
could
actually
start
that
container
image
and
access
it
on
our
local
machine
here
and
and
I'll
kind
of
leave
that
as
an
exercise
for
later.
All
of
this
is
on
github
and
the
next
thing
I'm
going
to
do
is
actually
so.
We
talked
about
the
two
services.
B
There
was
a
pet
store
and
now
we're
gonna
figure
out
the
data
store
outside
of
this,
so
the
my
sequel,
so
cat
DB
docker
file,
so
it's
in
a
different
directory
and
this
one's
even
simpler,
essentially
all
is
doing.
Is
it
starting
with
the
my
sequel
base
image
and
then
it
starts
some
initialization
scripts,
which
essentially,
what
is
gonna
do
is
set
up
replication.
B
So
it's
gonna
replicate
this
database
to
make
sure
that
the
ones
running
in
docker
and
kubernetes
are
gonna,
replicate
against
the
ones
that
we
have
on
Prem,
and
this
is
how
we
add
state
and
and
rather
persistence-
stew.
It
to
a
stateful
application
because,
as
we
should
all
know
by
now,
running
stateful
application
in
kubernetes
means
that
you've
got
to
start
thinking
about
things
like
storage
of
persistent
volumes
and
object
storage
and
that
kind
of
thing
so,
but
by
using
replication.
B
B
Okay!
Put
this
right
here.
Hopefully
the
signals
better.
So
we
got
a.
We
have
a
to
worker
node
cluster
ready
to
go.
So
let's
go
ahead
and
push
this
pet
store
application
into
kubernetes.
To
do
so,
we
need
a
deployment.
Yeah
Mille,
let's
see,
should
I
should
do
less
here,
so
we
can
kind
of
walk
through
it.
So
this
does
a
lot
of
different
things,
but
essentially
the
key
things
to
look
out
for
here.
So
one
is
pulling
that
image
from
my
repository.
B
It's
replicating
it
out
two
times
just
because
you
know
one
is
better
than
two.
If
one
of
them
goes
down,
the
other
one
still
continues
to
work.
We
expose
that
service,
but
we
don't
use,
we
don't
actually
specify
type
like
load,
balancer,
node,
port
or
even
ingress
for
it,
or
rather
we
will
satisfy
an
ingress.
So
so
far,
it's
a
it's
only
like
an
internal
thing.
B
Next,
we
also
deploy
the
database
so
again,
this
at
docker
image
that
we
built
so
it'll
just
gonna,
pull
that
one
key
thing
I
want
to
point
out
here,
so
we
talked
about
extracting
configuration
right,
so
this
is
essentially
taking
key
parts
of
configuration
in
an
application
and
pulling
them
out
and
making
them
config
that
that's
kind
of
driven
by
in
the
kubernetes
way,
driven
by
Gamal
and
and
kubernetes
resources.
Essentially
what
this
allows
us
to
do
later
on.
B
If
we
wanted
to
connect
up
to
a
test
database,
we
don't
have
to
rebuild
the
image
we
just
go
in
here
and
we
change
the
URL,
the
port,
the
host
database,
whatever
it
might
be,
and
then
just
redeploy
the
application
and
it
just
configures
it
and
restarts
those
apps.
Everything
is
good
to
go.
The
last
thing
I
want
to
point
out
here
is
this
ingress.
Essentially,
what
we're
doing
is
we're
exposing
this
application
on
this
subdomain,
that's
provided
to
us
by
by
IKS
our
kubernetes
service.
So
there
we
go.
B
So
that's
the
deployment
yamo
and,
let's
do
a
cube.
Ctl
apply
jpetstore,
and
now
I'm
actually
going
to
talk
about
this
thing
that
I've
just
kind
of
kept
it
as
an
elephant
in
the
room
here.
But
this
is
a
tool,
it's
called
cuy
and
it
essentially
gives
you
a
visual
way
of
doing
kubernetes
and
and
kubernetes
CLI.
B
So,
as
you
can
see
it
just
by
running
that
apply
command,
it
shows
me
live
updates
of
the
pods
getting
started
up
of
the
pods
kind
of
and
the
services
getting
created,
all
the
different
artifacts
and
you
know,
as
opposed
to
the
traditional
cube,
CTL
experience.
I
honestly,
I
think
this
is
pretty
neat.
So
all
this
is
actually
open
source.
It's
a
CLI!
Anyone
can
use
it
I
think
it's
just
IBM,
slash
Kui,
so
yeah
check
it
out.
B
If
you
guys
are
curious,
it'll,
just
it's
essentially
just
a
little
electron
based
app
that
allows
you
to
have
more
kind
of
visuals
when
you're
working
with
kubernetes
another
I
think
neat
thing
it
like
little
literally
helps
you
walk
through
logs,
so
so,
for
example,
if
you
do
age,
you
can
actually
start
clicking
on
command
and
get
information
and
examples.
It's
essentially
just
like
a
prettier
way
of
working
with
kubernetes,
so
yeah
check
it
out.
If
you
guys
are
interested
so
next
things.
B
So
what
we've
done
is
we've
deployed
that
application
I
think
we
saw
that
all
of
them
started,
but
just
in
case
this
is,
do
a
get
pods
one
more
time.
Okay,
cool
ready
to
go.
Let's
do
it
get
ingress
because
we
set
up
an
ingress
to
actually
access
this
application.
So
here
we
go.
Here's
a
host,
throw
it
into
a
browser
moment
of
truth,
yay,
all
right.
B
Let's
we
got
pet
store
running
all
right,
so
essentially,
what
we've
done
is
we've
taken
the
pet
store
application
containerized
it
kubernetes
fight
it
and
pushed
it
into
our
cluster.
At
which
point
you
know
we
can
start
taking
advantage
of
all
the
awesome
cloud
advantages
right,
so
bringing
in
new
VMs
is
response
to
load,
auto
scaling,
scaling
back
down
and
and
what
we're
going
to
get
into
next
cool
integrations
within
it
within
the
cloud.
B
So
that's
the
kind
of
power
of
lift
and
shift
it's
you
don't
really
have
to
refactor
to
change
the
application
much
you
just
start
using
the
cloud
right
away.
Next,
we're
going
to
talk
about
innovating
and
improving
on
your
application.
So
the
the
awesome
thing
about
this
is
you're,
creating
new
end-user
experiences
right.
So,
let's
say,
for
example,
with
this
pet
store
application.
B
These
kids
that
are
excited
about
buying
bunnies,
about
on
Easter
or
for
Easter
they're,
not
gonna
want
to
use
that
gross-looking
application
that
parrot
might
give
a
little
kids
nightmares.
So
I
think
instead,
what
we
want
to
do
is
create
a
new
experience
for
them,
something
where
maybe
kids
can
use
their
phone
to
take
a
picture
of
say
a
pet
or
an
animal
and
then
we'll
identify
it
for
them
and
let
them
know
if
that,
if
that
pet
is
in
our
store
and
it's
available.
B
So
that's
our
goal
here
and
to
do
that
we're
gonna
have
to
build
off
of
our
existing
architecture.
Existing
API
is
that
pet
store
app
that
my
sequel
database
and
sometimes
that's
difficult,
because
that's
what
happens
when
you
have
these
legacy
architecture
you're
restricted
to
kind
of
like
using
them
when
creating
these
new
cloud
native
cloud
native
based
applications.
So
for
this
demo,
I
want
to
take
advantage
of
two
capabilities
right.
B
So
essentially
we
need
to
support
some
way
of
text
messaging
and
reading
those
messages
in
and
routing
them,
in
a
programmatic
way
to
do
that.
We're
gonna
use
Twilio
and
the
other
side
of
things
we
want.
We
need
to
do
visual
recognition,
so
you
send
in
a
picture.
You
need
to
actually
figure
out.
What's
in
that
picture,
to
do
that,
we're
gonna
use
the
Watson
visual
recognition
service,
so
those
are
the
two
things
that
we've
got
going
on
here:
let's
go
ahead
and
get
started.
B
Actually
you
know
what
I've
done
this
both
ways,
but
let's
actually
walk
through
the
architecture
before
I
go
to
the
demo
just
so
we
really
know
what's
going
on,
essentially
what
we're
gonna
do?
The
device
is
going
to
hit
the
Twilio
service.
The
Tullio
service
then
routes
that
image
to
a
micro
service
that
micro
service
then
figures
out
what's
in
that
image
and
then
asks
the
pet
store,
if
that
pet
is
in
the
store
and
then
it
kind
of
routes
all
back
to
the
user.
B
So
let's
set
that
up
two
things:
I'm
gonna
need
I'm
gonna
need
the
actual
visual
recognition
service,
so
Google
this
real
quick.
You
know
it's,
essentially
you
throw
in
images.
You
can
even
classify
and
train
models
if
you
want,
but
like
the
free
version
that
we
got
out
there,
anyone
can
kind
of
just
go
play
with
it.
It's
something
like
you
get
a
lot
of
API
calls
for
free,
essentially,
it'll
tell
you
with
confidence
ratings.
B
What's
in
an
image
that
kind
of
thing
and
it
can
even
go
deeper
and
for
our
case
tell
you
what
type
of
like
cat
it
might
be,
or
dog
or
whatever
it
might
be.
So
we've
got
that
service
created.
Don't
do
anything
bad
with
my
API
key,
so
that's
over
here,
and
we
also
have
a
phone
number
set
up
in
Toledo.
That
essentially
is
gonna.
Allow
us
to
send
and
receive
text
messages
and
MMS,
and
we've
set
up
a
web
hook.
So
essentially,
anytime
Twilio
receives
this
image.
B
It's
going
to
pass
that
in
a
john
to
our
application,
so
all
that
processing
can
get
kicked
off,
so
we've
got
this
created
next.
What
we
need
is
the
actual
messaging
servus.
So
I've
got
that
here
already
see
the
MMS
search.
So
this
since
we're
making
cool
cloud
native
applications
we're
not
using
Java
anymore.
We
want
to
go
with
something
cool
and
so
to
do
that.
B
We're
using
golang-
and
you
know
at
this
point,
I
think
who
might
even
stop
being
cool
I,
think
people
are
using
even
crazier
languages
these
days,
but
for
the
sake
of
this
example,
we
use
go
to
create
a
simple
application
that
lets
you
chat
and
send
images
and
and
work
with
our
pet
store
in
new
and
innovative
ways.
So
we've
got
this
application
created
here.
B
What
you
want
to
do
is
take
advantage
of
kubernetes
secrets,
have
a
little
cheat
sheet
here,
so
I'm,
basically
going
to
create
a
secret
from
that
file.
Essentially
what
this
is
gonna
do
is
push
those
secrets
yeah.
This
is
Internet's
struggling,
but
okay,
it's
essentially
going
to
create
that
secret
and
now
what
we
can
do
is
actually
push
that
go
application.
So
after
we've
built
it
so
on
whatever
we
kind
of
walk
through
that
earlier,
we
will
deploy
a
new
application.
This
is
going
to
be
the
MMS
app.
Essentially,
what
we've
got
here
again.
B
Very
simply.
One
thing
I
do
actually
want
to
point
out
here
that
secret
that
we
just
pushed
this
is
how
it's
being
mounted
into
our
MMS
service.
So
it
knows
how
to
access
that
Watson
service
and
that
Twilio
service,
it's
actually
being
mounted
through,
that
gamma
file
right
there
and
also
we're
exposing
this
application
using
an
ingress,
because
we
want
to
be
able
to
access
it
directly
from
the
public
Internet.
So
let's
go
ahead
and
do
that.
B
And
again
for
those
that
may
have
walked
in
so
this
is
a
cuy
tool
that
we're
using
here.
This
essentially
is
what
it's
making
everything
look
a
little
bit
magical
when
you
deploy
new
applications.
That
kind
of
thing
I
will
say
that
I
did
deploy
this
application
earlier.
That's
why
it's
starting
so
quickly,
so
it
doesn't
even
have
to
like
pull
the
the
the
image
again.
So,
okay,
there
we
go.
We've
deployed
the
application.
B
We've
got
the
secrets
running
now
moment
of
truth,
no
I'm,
not
sure
the
demo
gods
are
on
my
side,
because
my
phone
is
it's
an
American
phone
and
I'm
trying
to
text
message
an
American
number
from
Barcelona.
So
we'll
see
what
happens
so
we're
gonna
do
is
drag
this
image
of
a
cat
and
I've
already
got
it.
Set
up,
I'm
gonna
get
hit,
enter
and
I
know
this
takes
like
a
few
minutes
or
not
a
few
minutes,
but
a
few
few
seconds,
probably
so.
In
the
meantime,
let
me
open
up
this
keynote
here.
B
Just
so,
people
can
see
and
remember
exactly
what
was
happening
and
you
got
to
get
really
excited
if
it
comes
back.
The
text
message
comes
back,
but
but
essentially,
what's
going
on
the
device
sends
that
text
message.
That's
what
I
did
over
there.
You
make
sure
that
it
actually
sent
on
my
phone
and.
B
So
essentially,
what
it's
saying
is
that
our
Cadillac
does
have
our
catalog.
My
Cadillac
does
have
a
cat,
a
Persian
cat
and
we
have
it
set
for
93
50.
So
there
we
go.
We
were
able
to
integrate
that
Twilio
service,
take
advantage
of
visual
recognition,
so
much
happening
on
the
back
end
and
send
a
text
message
from
Barcelona
to
my
US
Twilio
number
and
get
a
response
back
in
about
20
seconds.
B
Maybe
it
felt
like
an
eternity
up
here,
but
maybe
something
around
there
so
I'd
say
I'd,
say
that's
pretty
cool,
so
let's
kind
of
jump
back
into
the
presentation
and
and
and
then
now
now
that
we
have
this
architecture,
I'm
feeling
good
about
what
we've
done.
We've
we've
lifted
and
shifted:
we've
innovated
we've
improved,
but
we
have
a
problem
here
so
right
here.
That's
the
bottleneck
so
essentially
anytime
we're
storing
data
with
the
pet
store,
putting
it
into
a
sequel
database.
It's
getting
replicated
on
on
pram!
That's
something!
That's
that's
not
ideal!
B
In
addition,
we
have
this
expensive
enterprise
sequel
license
on
Prem.
Maybe
we
paid
like
a
million
dollars
for
it
and
we're
not
even
using
it
because
we're
using
that
cloud
service.
So
how
do
we
fix
this
problem?
Well,
we
already
did
the
first
thing:
we've
identified
that
we
need
to
fix
something.
So
that's
part
of
modernization,
it's
going
back
and
refactoring
and
and
figuring
out
where
you
need
to
fix
things.
So
in
this
case
we
figured
out
that
you
know,
let's,
let's
fix
this
portion,
so
the
advantage
of
doing
something
like
this.
B
It
allows
you
to
create
more
performant,
modern
applications.
I
think
the
general
strategy
for
when
you
want
to
do
this
kind
of
refactor
Rattray
factorization
is
first,
you
gotta
identify
what
you
want
to
refactor.
Another
option
I
could
have
done
is
to
break
apart.
The
jpetstore
application
have
the
front-end
live
on
the
cloud
and
then
the
backend
be
its
own
massive
monolith
that
allows
us
to
scale
up
the
front
end
and
the
monolith
separately.
That's
one
strategy
and
that's
something
that
I
should
see
happening
quite
often
is
when
we're
choosing
what
we
want
to
deconstruct.
B
It's
pulling
the
front
end
out
of
the
monolith.
That's
one
strategy:
in
our
case,
we
identified
that
sequel
database
that
we
wanted
to
kind
of
fix
that
situation
where
we're
having
to
do
that
replication.
So
what
we
want
to
do
is
create
glue
code.
Blue
coat
is
essentially
a
modern
way
of
communicating
between
languages.
So
generally
it's
api's
versus,
like
procedural
calls
to
remote
procedures,
whatever
it
might
be.
So
so
we
want
to
create
an
API
REST,
API
fashioned
for
communicating
with
our
database.
B
The
thing
is,
you
know:
refactor
ization
can
be
time-consuming,
expensive,
but
that's
that's
kind
of
a
that's.
How
it
is
I
mean
you,
we
did
the
lift
and
shift
we
incurred
that
technical
debt
now
it's
time
to
pay
back
this
loan.
So
let's
talk
about
how
we're
gonna
do
this
deconstruction
side
of
things
and
for
this
there's
a
open
source
framework
that
I
like
to
use
called
loop
back
and
that's
based
on
nodejs.
So
it's
kind
of
my
background
a
long
time
ago,
I
was
really
involved
in
a
node.js
community
and
that
kind
of
thing.
B
So
essentially,
it's
this
awesome
way
of
essentially
taking
a
database
and
exposing
it
as
api's,
and
that's
gonna
help
us
solve
that
problem
that
we
have
here,
because
what
we're
gonna
do
is
replace
that
my
sequel
database
and
we're
gonna
replace
it
with
a
node.js
api
micro
service
that
allows
us
to
scale
that
API
micro
service,
independent
of
the
rest
of
the
stack
and,
in
addition,
allows
us
to
continue
to
use
that
my
sequel
database
on
Prem
that
Enterprise
license
that
we
got
maybe
there's
financial
data
in
there.
Maybe
there's
like
GDP
our
regulations.
B
We
got
a
hit,
something
like
that.
So
we
want
to
keep
that
my
sequel
database
in
the
private
cloud,
whatever
it
might
be,
this
is
going
to
be
the
architecture
we
go
for
so
I've
already
kind
of
done
that
so
we
have
that
that
cuy,
shell,
let
me
go
back
in
here:
Jesus
we're
gonna
CD
into
the
pet
store,
loopback
application
and
we're
gonna
start
this
app
locally
and
I've.
B
So
again,
what's
my
point
with
this:
why
did
I
do
that,
so
essentially
it's
to
expose
a
programmatic
way
of
talking
to
legacy
architectures!
That's
that's!
What
glue
code
is
that's
what
modernization
kind
of
boils
down
to?
You
need
to
take
existing
kind
of
legacy,
ways
of
talking
to
our
applications
and
modernize
them.
So
now
that
pet
store
application,
I
am
gonna,
have
to
refactor
it.
It
has
a
bunch
of
sequel
calls
in
there
had
to
change
those
to
rest.
B
Api
calls
that's
time
consuming
it's
expensive,
but
the
advantages
in
the
future
when
I
create
a
new
application
that
accesses
that
same
database.
I,
don't
have
to
worry
about
those
sequel
procedure
calls
anymore,
I
can
just
use
api's,
and
that
means
that
new
team
of
new
hires
that
I
got
is
gonna,
have
an
easier
time,
developing
new
cloud
native
mobile
apps
or
whatever
it
might
be
working
against
that
database.
Then,
if
I
were
to
never
have
modernized
in
the
first
place
cool
that
was
a
mouthful
okay.
B
So
essentially,
what
we're
doing
is
taking
the
loopback
app
instead
of
running
it
locally.
We're
gonna
push
it
into
the
the
kubernetes
cluster.
For
the
sake
of
this
demo,
what
I
did
was
essentially
I
exposed
the
the
actual
api's
as
as
not
as
an
ingress
or
a
node
port,
rather
so
that
I'll
be
able
to
actually
access
it
and
show
it
to
you.
There
we
go
finally
came
back.
Maybe
the
hotspot
is
not
so
good.
There
we
go.
Okay,
let's
do
a
cube,
see
tail,
gets
serviced
and
we'll
take
this
external
IP.
B
Sorry
I,
think
I
might've
said:
node,
port
I
meant
load,
balancer
take
the
port,
and
now
we
should
get
back
our
loopback
application
running
in
the
cloud
there
we
go
and
if
we
go
to
the
Explorer
we
can
start
using
these
api's
and
and
then
one
more
cool
thing
about
loopback
will
click
real,
quick?
It's
the
fact
that
since
we
have
this
open
API
specification,
this
is
essentially
documented
API.
So
people
can
new
people
that
want
to
access
this
application
and
use
data
can
start
doing
it
without
having
to
talk
to
you.
B
They
can
just
go
in
here
and
figure
out
exactly
what
they
need
to
call.
What
parameters
there
are
that
kind
of
thing.
It's
pretty
neat
and
I
think
it's
one
of
those
things
that
I've
seen
it's
actually
quite
helpful
when
doing
modernization
so
again,
real
quick.
Looking
at
that
new
new
architecture.
This
is
kind
of
our
final
final
kind
of
approach
for
for
this
application.
B
We
did
that
sequel,
database
replication
thing,
but
another
option
generally
that
I've
seen
is
breaking
apart.
The
monolith
so
pulling
up
hard
the
front-end
and
then
pulling
apart
various
services.
So
that's
gonna,
be
it
for
me.
I'm
again,
I
have
some
kubernetes
videos
actually
that
if
you
guys
are
interested
check
out
YouTube
that
go
over
the
concepts,
basic
concepts
deployments,
that
kind
of
thing
and
again
yeah.
Thank
you
so
much
for
having
me
everyone.