►
Description
Whether you refactor, rehost, or replatform - the move to cloud is a necessary operation across enterprises all over the world. And while essential for modernisation, cloud migration efforts can be complex, time consuming, and even come at the cost of business innovation! This begs the question - is it time to rethink the approach and shift from a model of dedicated migration programs to one that treats the move to cloud as a business as usual activity? And is that even possible?
In this episode we’re joined by Red Hat Associate Principal Solution Architects Benjamin Farr (bfarr@redhat.com) and Bryon Baker (brbaker@redhat.com) to look at some of the exciting new ways to engage an application modernisation strategy. We’ll discuss open source projects such as Skupper and look at how they are changing the face of cloud modernisation leading many to ask the question “Are we nearing the end of ‘The Age of Cloud Migration?’” Join us and ask your questions and share your thoughts with our experts live!
0:00 Stream Beginning
02:00 Guest intros
03:57 What is hybrid cloud and multicloud?
14:30 Get to cloud faster!
29:43 Refactor the monolith
46:00 LIVE DEMO! Progressive migration in action.
1:07:50 Final wrap up
A
A
Thank
you,
hello,
hello,
hello
and
welcome
to
the
APAC
hybrid
Cloud
copy
hour.
We
are
back
from
a
small
break
where
we've
been
away
for
a
little
while
since
February,
but
we're
back
with
a
live
broadcast
coming
to
you
from
Sydney,
with
the
usual
cast
of
characters:
I'm
August,
simonelli,
I'm,
a
technical
marketing
manager
here
at
red
hat
and
as
a
reminder,
this
is
the
Kopi
hour,
not
the
coffee
hour.
Anything
like
that.
That's
a
traditional
beverage
found
in
in
Southeast
Asia
in
Singapore.
A
Now,
look
at
this
I
have
actually
here
a
coffee
cup.
It's
not
actual
copy
in
the
cup,
but
it's
an
actual
traditional
coffee
cup
from
Singapore
I'm,
very
proud
of
that
and
I've
been
prepping,
my
my
Nescafe
in
there
now,
of
course,
that's
not
why
we're
here,
you're
not
here
to
watch
me
drink
coffee
as
fun
as
that
may
be,
but
we
have
our
usual
co-host.
We
have
Dev
shanbag
Jeff.
Why
don't
you
introduce
yourself.
B
Hi
everyone
I'm
Dave
chamber,
and
let
me
toast
my
virtual
coffee
with
you.
There
we
are
pin
with
red
hat
for
around
seven
years,
work
with
the
services
team
here
in
Melbourne,
Australia
I'm
glad
to
be
part
of
this
kopia
project
with
August
and
really
excited
to
hear
and
listen
from
our
presenters,
Brian
and
Ben.
A
C
Oh
hi
yeah,
so
Brian
Baker,
I'm,
Augustine,
I'm,
associate
principal
architect
in
Melbourne,
Australia,
I,
specialize
in
the
financial
services
sector
and
helping
red
hat
and
our
customers
in
that
that
vertical
be
successful
with
Red
Hats
technology,
so
yeah
over
30
years,
I
guess
in
in
it
across
a
bunch
of
sectors.
Commercial,
public
sector
and
financial
services
and
yeah
really
happy
to
be
here
today
and
share
what
we're
doing
with
application,
modernization
and
and
Cloud
migration.
Excellent.
A
D
Oh
hi
there
so
I'm
a
been
with
red
hat
for
about
eight
years,
but
I
sort
of
come
from
25
years
of
application
and
development
and
architecture
experience.
You
know
for
I've,
recently
sort
of
got
a
job,
so
I'm
now
sort
of
looking
at
Telco
accounts
in
Australia
and
New
Zealand,
but
before
I've
sort
of
covered,
a
fair
range
of
Industries
and
I've
got
interest
in
that
modernization
event
driven
architecture
and
in
the
open,
hybrid
cloud.
A
Excellent,
yes,
yeah
I've
been
working
with
Brian
and
Ben
and,
of
course,
Dev
for
quite
some
time.
So
it's
really
exciting
to
have
them
on
today
and
to
to
get
into
this
kind
of
provocative
talk
topic
the
next
evolution
of
cloud
migration.
So
I
love
the
title.
We
worked
hard
on
making
it.
You
know
I,
hopefully
you're
all
sitting
out
there
going
what's
happening
there,
but
what
we
wanted
to
lead
in
with
a
bit.
Is
that
what
what
is?
What
is
cloud
migration?
A
Where
are
we
going
with
that
and
I
was
reading
a
stat
I
think
it
was
from
the
voice
of
the
Enterprise
survey,
saying
that
70
of
organizations
are
now
multi-cloud
and
hybrid
Cloud.
So
before
we
dive
in
I
want
to
level
set
a
little
a
little
bit
about
what
how
we
got
there
and
what
these
things
are.
So
multi-cloud
is
using
two
Cloud
providers
and
then
hybrid
cloud
is
mixing
and
matching
those
Cloud
providers
is
mixing.
On-Premises
is
mixing
bare
metal
physical
I'm
on
track
with
that
right.
Is
there?
C
Well,
I
I
think
it's
it's
a
little
bit
more
nuanced
than
that,
so
so,
I'm
in
hybrid
Cloud,
multi-cloud
you've
got
these
the
stretching
yeah
you're
existing
on
premises,
infrastructure
out
to
the
public
cloud
or
it
can.
You
know
because
there's
a
bit
of
you
know:
people
use
the
words
differently
right
now.
Multi-Cloud
I
tend
to
use
about
where,
if
I've
got
multiple
public
clouds
that
I'm,
using
and
I'm
deploying
across
there
and
hybrid
tends
to
include
that
plus
going
from
on-premises
to
the
public
Cloud.
A
So
you
use
an
intro
I
think
an
important
word
that
I
wanted
to
kind
of
go
into.
You
said
stretching
and
I'm
not
talking
about
this
morning's
exercise,
which
you
know
is
always
good,
but
how
do
we
get?
How
do
we?
How
did
we
actually
start
to
migrate
and
I
know
at
Red
Hat?
We,
you
know
we're
all
about
Cloud,
migration
and
I
in
the
past.
You
know
we
we
actually
were
about
virtualization
migration,
I
know
Dev
and
I
used
to
meet
up.
C
B
B
B
There
was
a
point
where
everyone
was
looking
at
hybrid
clouds
and
that's
when
you
know
you
and
I
kind
of
started
working
together
and
recently
I
read
a
stat
where
in
2022
the
openstack,
the
number
of
cores
that
open
cycle
servicing
came
to
22
million
course.
So
you
know
that's
been
quite
enjoying
and
with
that
it
has
evolved
as
well.
You
know
these
days
we're
looking
more
towards
microservices
and
going
towards
event
driven
architecture.
B
A
A
A
So
then,
I
think
that
evolves-
and
this
is
where
we
want
to
get
to
into
things
like
Submariner
and
I.
Don't
know
if
you
guys
have
more
to
say
on
Submariner,
but
this
is
a
tool
that
allows
you
to
do
cross
cluster
network
communication,
it's
cni
for
openshift,
and
actually
we
don't
now
necessarily
need
to
move
workloads,
but
we're
starting
to
look
at
ways
to
connect.
Workloads.
Am
I,
am
I
on
track
with
that.
C
Yeah
I
think
you're
close
I
mean
the
the
end
goal
right
of
tools
like
Submariner
is
to
interconnect
my
workloads
and
be
able
to
and
have
multiple
placement
choices.
My
workloads
across
multiple
clusters,
that's,
ultimately
the
problem,
that's
solving
right
and
the
way
it's
doing.
That
is
it's
joining
your
kubernetes
clusters
at
the
hip
and
setting
up
a
VPN
between
two
clusters.
There
so
and
then
there's
a
because,
as
you
know,
kubernetes
uses
a
service
level
of
abstraction
for
for
for
communication
between
the
pods,
so
it
uses
services.
C
A
So
this
is
cool
right,
so
we're
tracking
the
evolution
and-
and
it
all
kind
of
gets
wrapped
up
in
this
famous
thing
and
I'm
I'm
gonna
look
at
my
notes,
but
it's
a
hosting
platforming
repurchasing
refactoring
retire
and
retain
right.
These
six
strategies
for
migrating
applications
to
the
cloud
that
AWS
set
up-
and
this
is
kind
of
well
known
and
we've
kind
of
moved
along
and
I
got
to
this
point
and
I
was
looking
at
Submariner
I
thought.
So
this
is
cool
right.
So
we've
arrived
Cloud
migration.
A
Does
these
things
we
can
stretch
some
clusters,
we
can
move
some
workloads.
We
can
do
a
lot
of
things,
but
that
then
kind
of
says.
We
need
to
start
asking
some
more
serious
questions
about
where
we're
going
here
and
that's
where
we're
trying
to
get
to
today
on
the
show
and
it
it
comes
up
that
I'm
curious
right
is
we?
Is
there
a
next
evolution?
Is
this
really
the
next
Evolution?
What
do
you
mean
by
that
Brian
like
we?
We
look
at
this
title,
but
what?
What
do
we
mean?
Hybrid
Cloud
solves
this
right.
C
You
know
that
kind
of
gives
you
all
Landing
space
and
red
Hat's,
open,
hybrid
Cloud
right,
which
is
the
whole
idea
of
the
open,
hybrid
cloud,
is
to
put
openshift
everywhere,
and
so
it's
what's.
The
benefit
of
that
is
it's
the
same
kubernetes
flavor
everywhere,
which
means
that,
from
the
application
team
perspective
and
from
the
the
SRE
and
salt
reliability
Engineers
who
have
to
support
these
things,
it's
consistent
every
which
means
that
they
can
land
the
same
thing
everywhere
with
no
code
changes
right,
but
that's
a
very
structural
solution
right.
So
what
we?
C
What
we
need
to,
what
it
doesn't
give
us
is
a
way
to
execute
right.
So
this
and
and
kind
of
rewinding
back
a
little
bit.
It's
it's
also
about
the
cloud
migration
programs,
where
I'm,
starting
with
an
application
running
on
a
virtual
machine
and
I
break
up
that
monolith
and
I
go
and
put
it
on
the
cloud
and
that
piece
of
work
right
requires
usually
a
whole
team
to
down
tools
from
developing
any
business
features
right
and
then
Focus
that
re-engineering
effort
on
getting
the
application
cloud
ready
and
I
guess.
C
This
is
where
the
next
Evolution
comes
in,
because
you
know,
while
we
may
have
these
consistent
kubernetes
platforms
everywhere,
right,
that's
a
very
structural
solution.
It
gives
me
a
constant
Landing
Strip
to
go
everywhere,
but
it
doesn't
give
me
a
way
to
execute,
and
these
big
migration
programs
tend
to
stall
right.
I've
seen
this
on
every
single
customer
that
I've
worked
with
and
and
in
my
previous
life
before
I
joined,
Red,
Hat,
four
and
a
half
years
ago,
is
that
these
big
re-engineering
activities
right
really
start?
C
They
come
at
the
expense
of
delivering
business
features
because
the
100
of
the
workforce
is
getting
everything
ready
right.
So
the
next
evolution
in
my
phrase,
in
my
wording,
there
is
the
idea-
is:
how
can
I
instead
of
use
a
cloud
migration
program?
How
can
I
do
more
out
of
getting
my
stuff,
my
graded,
the
cloud
out
of
BAU
business
as
usual,
or
or
or
or
project
investment?
C
Right
and
and
that's
the
idea-
and
this
is
where
I
see,
that
the
pendulum
shifting
a
little
bit
where
we
can
start
to
actually
not
have
to
do
massive
migration
programs
and
do
more
I.
Think
about
the
cloud
migration
as
a
multi-year
part
like
part
of
the
application
life
cycle,
and
how
can
I
do
a
true
get
that
application
out
to
the
cloud
through
Project
funding
or
business
as
usual
effort
right.
A
So
you're
telling
me
that
I
can
be
doing
my
usual
day-to-day
work
and
suddenly
I'm
in
the
cloud
I
mean
it's
part
of
the
actual
process,
so
that
okay
and
and
then
the
other
use
that
other
word
I
always
hear
this.
The
monolith
thing
right
that
we're
going
to
strangle
them
on
and
look.
We
got
to
break
up
the
monolith,
but
how
do
you
know
when
that
should
be
broken
up
like?
How
do
you
break
it
up.
D
D
A
A
C
Sure,
well,
so
what
we're
going
to
do
is
I'll
start
with
a
little
bit
of
slide,
where
just
to
kind
of
introduce
where
we're
going
to
go
with
this.
But
essentially
the
story
that
we're
going
to
show
you
today
is
we're
going
to
start
with
the
Java
monolith
and
then
Ben's
going
to
show
you
how
to
break
that
up
and
the
tooling
that
we
can
use
that.
C
Okay,
so
you
know,
as
August
said,
right
yeah,
whether
you're
yeah,
whether
you're
doing
any
flavor
of
the
six
hours
when
you
when
you're
re-platforming
re
re,
re-hosting
or
refactoring
right
you're,
always
going
to
be
moving
something
around
right
and
I've
talked
about.
You
know:
Red
Hats,
open,
hybrid
Cloud
and
how
it
kind
of
creates
this.
This
constant
Landing
Strip
this
this
same
thing
to
land
everywhere,
right
and
and
the
benefit
that
that
brings
in
is,
you
know
if
you've
got
a
Federated,
kubernetes
approach
to
Cloud
migration.
C
You
know,
you'll
start
with
your
application
and
then
you
know
you'll
refactor
or
maybe
you're,
building
something
net
new,
and
maybe
you
want
to
then
take
that
out
to
eks
or
gke
or
AKA
a
AKs.
And
so
you
know
that's
a
re-platform
activity
right,
and
you
know
as
part
of
that,
when
you're
ultimately
going
to
hopefully
decommission
that
one
off
there,
but
the
re-platform
is
there.
Are
differences?
You've
got
to
integrate
that
application
into
the
service
service
management
fabric,
the
security
fabric,
crcd
pipelines
are
going
to
be
subtly
different.
C
The
way
your
SRE
team
are
going
to
support
that
in
the
heat
at
the
moment
at
two
o'clock
in
the
morning
when
something
goes
wrong,
it's
going
to
be
different
depending
on
where
it
lands
now
yeah
the
hybrid
Cloud
approach.
The
open,
Harbor
Cloud
that
red
hat
promotes
is
about
having
a
constant
fabric,
an
open
shift
fabric
everywhere
right
and
it's
about
as
you're.
You
know,
building
that
new
or
refactoring
you'll
want
to
take
that
out
to
the
cloud.
It's
not
a
it's,
not
a
replay
platform.
It's
a
redeploy
activity.
It's
a
you're!
C
Turning
a
a
re-platform
conversation
into
a
placement
conversation
right
because
you've
decoupled
the
application,
the
platform
from
the
SRE
team.
It's
that
same
experience,
so
that
they're
maintaining
this
application
there
and
that's
fundamentally
how
it
all
works
right.
But,
as
I
said,
that's
it
that
open
Hardware
Cloud
doesn't
answer
to
very,
very
important
questions,
and
one
is
if
I
have
a
traditional
application.
C
C
So
you
know
that
these
Dynamic
questions
as
opposed
to
this
structural
solution,
that
kubernetes
everywhere
provides
right
and
that's
where
you
know
it's
really
really
excited
to
actually
be
introducing
a
new
product
that
we've
got
red
hat
service,
interconnect
which
is
powered
by
an
upstream
project
called
Scupper,
and
it
really
deals
with
the
fact.
I
mean
it's
a
little
bit
of
a
Swiss
army
knife,
but
in
the
context
of
this
discussion
today,
it
really
deals
with
the
question
about
when
I'm
moving
parts
around
the
place.
C
You
know
how
can
I
do
this
in
the
most
efficient
way
possible
right,
and
so
then
it
so
it
adds
this
other
dimension,
this
this
third
leg,
to
the
to
the
to
the
to
the
to
the.
How
do
I
get
the
cloud
pillar
if
you
like,
and
it's
this
next
Generation
Cloud
integration?
It
it
shifts
networking
left
and
makes
application
component
placement
choices.
An
application
team
consideration
and
what's
cool
about
it
is,
as
I
can
place
my
application
components
anywhere.
C
Is
it
kind
of
rides,
on
top
of
all
of
your
endorsed
network
security
and
security
flows,
and
can't
subvert
any
of
that
right?
So
it's
automatically
endorsed
from
a
network
and
security
perspective
and
when
you're
doing
that,
you're
doing
it
without
any
application,
changes
required
and
you're
going
to
see
that
in
the
demonstration
very
shortly
that
we're
going
to
run
you
through
so,
which
means
that
I
can
start
to
unpick
tightly
coupled
systems
and
start
to
place.
These
bits
that
I
want
and
I
can
Federate
my
application
architectures
across
clouds.
C
A
And
so,
when
you
take
when
you're
saying
shift
left,
you're
actually
saying
take
these
constructs,
these
Network
constructs
these
things
that
when
I
was
assisted
meant,
it
was
like
the
network
team
did
that
and
put
them
into
the
code,
put
them
into
the
developer
space
but
keep
controls
over
them
so
that
we
can.
We
can
still
not
go
nuts
and
have
exposures
and
stuff
like
that.
That's
what
you're
talking
about
yeah.
C
I'm
basically
saying
that
when
I
shift
it
left,
it
becomes
a
developer
or
an
application.
Team
discussion
and
conversation
right
I
mean.
Obviously
you
can't
change
the
laws
of
physics
and
your
network
latency
is
going
to
always
have
to
part
of
the
good
systems.
Engineering
design
principles
have
to
be
applied,
but
where
I
place
the
components
right
is
an
application
team
discussion
here
and
I.
C
A
C
You
so
you
know
just
quickly
before
we
start
running
over
into
the
demonstration
here
right,
so
you
know
the
idea
is
we
can
now
Federate
our
system
architectures
and
the
data
access
everywhere
we
want
I
can
deal
with
the
data
gravity
challenge.
I
can
deal
with.
My
data
is
going
to
be
here
and
I
can
start
to
move
the
components
around
over
anywhere
I
want
on
whether
that's
on
a
brown
filter,
a
traditional
system
of
like
a
virtual
machine
or
whether
it's
on
a
kubernetes
ecosystem.
C
It
doesn't
really
matter-
and
you
know,
we're
moving
away
from
these
coarse
grained
networking
solutions
that
are
always.
You
know,
dns-centric
right
to
creating
this
link
fabric
right.
That
uses
service
names
to
be
able
to
resolve
the
location
of
where
anything
is
which
is
building
on
how
kubernetes
works
right,
and
it
does
this
using
an
overlay
Network
that
I'll
get
to
at
the
minute.
So
it's
all
running
on
top
of
layer
7
to
be
able
to
do
that.
C
You
know
as
well,
so
you
know
now:
I
can
pivot
to
this
locationless
architecture.
As
I
said,
where
I
can
move
the
parts
around
and
I've
got
the
the
what
we're
calling
the
scalper
or
the
service
interconnected
routers
that
are
everywhere
that
create
a
multi-path
network
between
these
routers
that
will
let
any
endpoint
be
able
to
get
to
other
any
other
endpoint
and
with
a
guaranteed
delivery,
is
over
a
mesh
Network.
That's
there!
So
I
can
now
interconnect.
A
C
It's
it's
working
at
the
application
layer,
but
we
can
actually
integrate
everything.
Heterogeneous
platform
forms
no
matter
what
they
may
be.
You
know
it's
not
tied
to
any.
You
know
open
shift
or
or
it
can
work
with
eks
AKs.
You
know
Rel
Santos,
any
flavor
of
Debian.
You
name
it
right
and
we
can
integrate
our
applications
across
here.
So
as
we're
breaking
these
things
up,
modernizing
them,
we
can
move
these
parts
around
and
the
application
is
unaware.
A
C
Excellent
yep
you're
going
to
see
that
very
shortly.
We're
going
to
demonstrate
that
exact
thing
so
I'll
give
you
a
little
bit
of
an
example,
and
let
me
just
turn
on
my
little
laser
pointer
here.
So
I
can
kind
of
direct
where
your
eyes
are
looking,
but
you
know
so
over
here
we've
got
now
and
we've
got
a
New
York
site
and
over
here
we've
got
LA
and
we've
got
an
accounting
system
running
over
in
LA,
and
this
accounting
application
needs
a
payment
service
right
now.
C
Normally
in
a
kubernetes,
we
would
just
use
the
service
name
and
be
able
to
resolve
that
right.
But
the
trouble
is
the
payment
service
lives
over
in
LA
right,
and
so
what
we
do
is
by
deploying
service
interconnect
here
and
we
put
a
router
at
each
of
the
sites
right.
We
actually
publish
the
payment
service
to
the
mesh
Network
and
then
it
will
appear
over
here
as
a
local
proxy.
So
the
accounting
app
thinks
it's
talking
locally
to
a
payment
service.
C
But
what
actually
happened
is
that
payment
service
lives
over
in
New
York
right
so
now,
and
then
maybe
even
that
Accounting
Service
started
over
in
New
York,
we
just
moved
it
to
La
later
right
and
then
we
can
actually
take
everything.
It
depends
on
with
it
right,
and
so
then,
we've
got
this
this
network
here,
which
is
running
with
an
mtls
connection
between
them.
C
Another
example
is
where
we
can
actually
take
a
in
this
case.
Here.
We've
got
a
database
right,
that's
running,
say
on
VMware,
and
then
we
could
use
a
what
we're
calling
a
service
independent,
Gateway
right,
and
we
can
then
publish
that
database
as
a
local
service
on
kubernetes.
So
when
that
accounting
application
wants
to
talk
to
that
database,
it's
actually
going
to
talk
for
our
local
service
name.
C
Now
this
service,
interconnected
network,
is
going
to
pick
that
up
and
it's
going
to
then
effectively
deliver
that
request
over
to
the
to
the
TCP
database
on
the
other
side,
what
I
could
also
do
is
flip
this
around
right
and
that
is
I
could
put
the
database
from
kubernetes
in
my
application
on
VMware,
say
and
I
can
publish
something
that
would
normally
need
TCP
to
get
to
on
kubernetes
right
and
make
that
available
to
an
application.
That's
not
on
kubernetes.
Now,
what's
interesting
is
the
normal
way
you
do.
C
A
C
Everything
thinks
it's
talking
localhost
and
that's
going
to
be
really
important,
Ben's
going
to
talk
through
this,
as
he
breaks
up
the
monolith
right
as
you
break
up
those
components.
Those
components
are
used
to
talking
as
though
they're
all
local
to
each
other
right-
and
this
is
what's
happening-
is
the
service
interconnect
is
letting
everything
think
it's
talking
locally
right,
even
though
it's
not
right
and
that
that's
kind
of
key
to
the
whole
thing
right
and
it
also
the
way
it
does.
This
is
when
you
set
up
the
the
routers
between
them.
C
So
it's
it's
a
zero
trust,
Network
right
between
them,
so
that's
there
and
what's
also
interesting
about
it-
is
that
it's
multi-path
right
in
this
case
here
I've
got
three
routers
with
each
router
connected
to
the
other
two,
which
means
that
if
the
connection
between
Frankfurt
Germany
and
Geneva
was
was
down,
then,
if,
if
the
site
over
here
in
Geneva
still
needs
to
get
to
to
Frankfurt,
it
will
actually
go
via
Zurich
to
get
over
here.
So
it's
a
multi-path
mission
network
that
also
gets
created
there.
C
Now
has
it
all
doing
this
Rob?
Well,
if
you
think
about
kubernetes
kubernetes
really
is
all
things
talk
about
layer,
seven
unless
you're
using
a
metal,
Ingress
controller
or
a
metal
router
on
kubernetes,
then
you
know
everything's
talking
last
seven,
but
what's
interesting
is
we've
got
layer,
three
or
TCP
or
layer,
7
connectivity
being
delivered
by
by
service
interconnect
right
and
what
it
does.
Is
it's
an
overlay
Network
right.
So
it's
using
this
slide's,
not
quite
right
right,
because
it
should
actually
be
it's
using
wire.
C
Three
connectivity
in
layer,
seven
is
what's
happening
here,
but
the
idea
is
I
can
now
have
HTTP
rest
or
grpc
service
to
service
communication
or
I
can
have
TCP
right
in
there
and
it's
all
being
transported
over
layer
7..
So
it's
using
your
normal
kubernetes
Ingress
egress
right,
no
special
load
balance,
Ingress
controllers
required
for
this
to
work.
C
Sorry
now
that
we've
got
you
know
what
is
service
interconnect
right.
We
can
now
start
to
say
well
if
I've
got
this
thing,
which
has
a
locationless
application,
we
can
now
start
to
answer
these
questions
about
how
can
I
strangle
that
model
within
the
most
efficient
way
possible
and
what?
How
can
I
move
workloads
from
cluster
a
to
Cluster
B
in
the
most
efficient
way
possible,
and
let
me
run
these
through
an
animated
example
before
I
then
hand
over
to
Ben
for
the
demonstration.
C
It's
going
to
just
talk
locally
and
then
the
router
is
going
to
intercept
that
and
deliver
it
over
here
or
if
service
a
needs
to
talk
to
service
b
or
maybe
something
in
the
traditional
app
wants
to
call
what's
been
refactored
into
server,
say:
well,
it's
going
to
hit
the
Gateway
and
it's
going
to
effectively
be
serviced
out
on
the
cost
or
out
cluster.
One
now
say:
I
want
to
take
that
out
to
the
public
Cloud
right.
Well,
I've
already
done
my
refactoring
and
part
of
it's
running
on
kubernetes.
C
Well,
now,
I
can
just
complete
that
move
that
Network
and
stretch
that
out
to
Cluster
2,
which
is
in
the
cloud
down
here
right
and
then
I
can
actually
move
service
a
and
service
B
out
there.
Perhaps,
and
then
that
leaves
a
proxy
sitting
over
here
on
cluster
one.
That
service
c
will
still
think
it's
talking
locally,
but
server
say
we'll
be
able
to
then
effectively
be
resolved
via
the
network
and
their
services
needs
to
talk
to
the
database.
C
It'll
come
all
the
way
over
here
right
or
if
the
traditional
application
wants
to
talk
to
service
a
it'll
hit
the
Gateway
and
be
delivered
over
here.
So
it
means
I
can
actually
start
to
move
these
parts
out
and
around,
but
no
application
code
changes
is
being
done
when
you
do
this
right,
I
can
put
I
can
make
the
the
service
interconnect
network
is
handling
all
of
that
all
right,
and
so
you
know
this
is
really
interesting.
C
If
you're
an
openshift
customer
as
you're
moving
off
openshift
three
to
open
shoe,
four
I
can
start
to
re-host.
My
applications
over
there
or
I
could
use
this
to
migrate,
progressively
migrate
out
to
Cloud
right
and
I
can
do
this
with
no
application
changes.
I
could
start
to
think
about
how
I
fund
my
migration
programs
different
and
remove
the
need
for
dedicated
migration
funding
right
and
then
end
up
with
you
know
small
units
of
migration
cost
and
which
it
therefore
increases
less
cost
and
less
risk
right
in
there.
So
you
know
so
with
that.
C
A
A
D
Absolutely
and
I
totally
agree
with
that
comment.
It
does
take
a
lot
of
expertise
in
in
terms
of
sort
of
even
sort
of
grasping.
You
know
what
the
model
it
does
and
you
know
in
in
order
to
how
to
break
it
up.
This
is
abstract
art.
This
is.
It
is
I,
found
this
diagram
and
I
thought
of
a
monolith
when
I
saw
it,
but
you
know
when
I
always
remember
a
comment
you
know
early
on
in
my
career.
D
Give
you
an
example:
you
know
I
was
tasked
with
sort
of
a
monolith
effectively
a
monolith,
but
it
was
sort
of
in
a
hundred
integration
bundles,
but
there
are
400
links
in
between
them.
So
that's
an
average
of
you
know
four
dependencies
of
each
module
and
they
were
all
tied
to
each
other
like
like
a
sort
of
bowl
of
spaghetti,
so
yeah
you
lifted
one
up,
and
you
know
all
these
bits
of
spaghetti
came
with
it
and
you
can't
it's
very
difficult
to
break.
D
D
D
D
So
I've
got
a
little
bit
more
technical
and
for
the
job
of
people
on
the
call
you'll
be
able
to
sort
of
identify
with
this,
but
the
non-job
people
will
try
and
explain
a
bit
a
little
easier,
so
this
application,
I
mean
circuit,
would
have
been
written.
You
know
the
anywhere
between
2005
to
2012.
So
that's
sort
of
this
typical
design
where
we've
got
in
the
ear
file,
a
module,
it's
using
HTML,
JSF,
JSP,
CSS
JavaScript
is
a
front-end
technology
and
you've
got
sort
of
your
model
view
controller
design.
D
So
the
model
was
sort
of
the
data
that
you
displayed.
There
was
a
view
which
was
sort
of
the
HTML
components
which
I
described
in
a
controller,
and
in
this
case
it
was
sort
of
a
servlet
crisis.
So
but
then,
then
it
sort
of
comes
the
part
that
you
know.
You've
also
got
the
back
end
talking
to
the
database.
D
So
the
current
build
here
is
sort
of
just
one
single
web
module
with
a
ear
sort
of
module
route
or
Enterprise
Java
file,
Enterprise
archive
resource,
the
official
name.
So
I'll
just
show
you
a
bit
of
the
code,
because
you
might
be
interested
that
so
here
I've
got
my
original
web,
and
this
is
my
controller
class.
If
you
like.
D
And
I've
got
so
it's
a
model
sort
of
controller
of
injecting,
and
this
is
where
my
service
is
just
literally
injected
into
the
code,
and
it
can
be
difficult
to
wear
apart
and,
if
I
jump
into
that
member
registration.
Now,
this
class
here
is
a
stateless
sort
of
Enterprise
Java
Bean,
but
it's
also
injected
into
sort
of
the
database
and
very
much
tied
into
to
the
data
model,
so
there's
also
sort
of
other
aspects
to
it
and
in
the
real
life
there's.
D
You
know
some
internal
reluctance
to
remove
this
app
to
the
cloud,
because
people
know
it
it's
like
a
pet.
They
know
what
it
does.
They
know
what
it
do
is
if
it
falls
over
or
if
an
error
they
they
know
sort
of
how
to
fix
things
in
the
database.
Maybe
it's
a
workaround,
but
this
is
sort
of
an
important
customer
facing
app
that
needs.
D
A
And
it
makes
sense,
I
mean
I,
think
we
can
all
identify
with
this
I
remember
in
2012
that
a
previous
employer,
we
were
moving
apps
like
this
into
a
very
new
Amazon,
and
it
was
exactly
that.
How
can
we
pick
this
folder
up
and
move
it
and
make
it
be
there,
but
don't
mess
with
the
insides?
Don't
mess
with
you
know,
because
the
developers
need
it
this
way
and
we
were
Ops,
and
so
we
would
pick
it
up
and
move
it.
So
this
is
fascinating.
I'm
blow
it
apart.
D
So
fortunately
there
is
a
couple
of
tools
and
a
couple
of
you
know
code
analysis,
sort
of
aspects
that
can
sort
of
give
you
a
step
up
and
the
one
of
the
first
ones
that
I've
used
is
simply
using
the
plugins
to
the
IDE
integrated
development
environment
that
I'm
using
you
can
analyze
Java
code.
It's
particularly
up
the
great
versions
you
can
use
that
Maven
dependency
analysis.
Then
then
you
can
get
produce
a
nice
graph
of
how
sort
of
all
the
components
stick
together.
D
So
this
is
sort
of
a
screenshot.
If
you
like,
of
sort
of
the
typical
targets
that
you
could
select
to
to
run
against,
it
could
be,
you
know,
let's
examine
the
code
for
containerization
issues,
there
might
be
a
hard-coded
IP
address.
There
might
be
something
to
do
with
sort
of
a
Windows,
File
path,
name
or
something
like
that,
and
you
know
other
aspects,
so
I
can
select
multiple
of
these
targets
and
get
really
an
output
of
you
know
what
what
I
might
need
to
look
at.
D
D
These
are
the
six
core
tools:
I
guess
that
are
there
at
the
moment,
we've
got
something
called
Pathfinder
and
that's
sort
of
a
q
a
to
how
can
I
it's
more
like
a
subjective
sort
of
view
of
set
sort
of
q
a,
and
it
will
give
me
how
suitable
is
this
application
to
be
containerized
the
wind
up.
So
that's
sort
of
the
Upstream
of
what
I
was
talking
about
there
and
we've
got
other.
D
D
A
D
It
is
usually
time
well
spent,
and
in
this
case
my
first
step
in
taking
breaking
this
mileage
was
to
first
step
to
decouple
or
break
it
down
without
actually
changing
my
cicd
pipeline
without
and
just
putting
some
structure
around
it.
So
you
can
see
here,
I've
got
now
a
web
module
and
an
ejb
module,
and
this
is
still
ultimately
bringing
in
a
monolithic
single
deployment.
D
And
you
know
in
true
microservices,
you
might
sort
of
split
it
by
domains,
but
in
this
instance
there
the
banks
were
changing
the
UI
five
times
greater
than
it
is
the
back
end
and
it
sort
of
makes
sense
as
as
a
first
step
and
to
get
something
into
the
cloud
you
know
more
quickly,
and
so
then
the
next.
The
next
step
was
to
do
away
with
sort
of
that
injection
that
I
sort
of
looked
at
and
enable
this
to
be
done
by
a
remote
lookup
and
ensure
our
sort
of
model
classes.
D
Were
you
know
it
was?
There
was
some
sharing
there
so
taking
that
egb
and
making
sort
of
an
age
of
a
client
model,
and
then
now
with
too
much
effort
without
too
much
effort,
we've
found
a
low
risk
way
to
break
it
up
and
do
it
in
a
way.
We
can
still
work
with
the
current
setup
and
then
the
EAP
version
I'm
running
here
I
can
actually
sort
of
deploy
all
of
these
three
different
ways
of
building.
It's
still
I've
got
my
original
original
module.
D
Yeah
I've
got
the
the
refactored
one,
which
is
that
one
there
and
I've
got
a
front-end
and
back
end
which
actually
are
talking
to
each
other
over
localhost.
So
let
me
just
try
and
find
the
code,
which
does
that
so
you
can
see
here.
I've
got
my
original,
my
modular,
you
can
see
I
sort
of
broke
it
up
into
different
modules
and
with
my
refactored
I've
now
got
a.
D
Some
additional
code
and
Surround
this
member
controller
having
injection
it's
actually
using
this
lookup
facility
class
here,
which
is
sort
of
talking
to
localhost
8080
and
that's
on
my
EP,
so
it
can
sort
of
run
in
the
same
version.
But
you
know
in
the
next
step,
you'll
see
that
you
know
I
haven't
had.
D
You
won't
have
to
really
change
that
URL
in
order
to
sort
of
move
it
into
the
cloud,
and
at
that
point
I
think
you
know
this
is
where
we
started
with.
It's
got
a
monolithic
web
application
talking
to
a
database.
It's
a
it's
a
postgres
database
in
the
back
end
and
Brian's
going
to
show
you,
you
know
how
we
can
simply
take
the
front
end
and
back
end,
and
now
we've
got
it
sort
of
running
on
a
containerized
platform
and
with
JBoss
you
can.
A
Right
so
you've
been
this
artist
and
there's
certainly
no
one
size
fits
all
for
this,
but
it's
just
cool
right
I
like
how
you
showed
that
and
it's
still
looking
at
localhost-
and
you
know
normally
be
like
right
now.
I
gotta
change
all
that,
but
but
we
don't
right
this
with
with
Scupper
and
and
service
interconnect.
We
can
do
more.
C
Absolutely
yeah
and
look
Ben's
done
yeah.
If
you
could
share
my
screen
now,
please
August,
but
yeah
Ben's
actually
done
all
of
the
hard
work
and
the
rest
of
it.
The
cloud
migration-
and
this
is
everyone-
thinks
Cloud.
Migration
is
the
hard
bit
the
hard
bit
is
what
Ben
just
did
and
it's
still
running
on
premises,
I'm
going
to
show
you
how
to
take
that
all
out
to
the
cloud
now
and
we're
going
to
do
that
and
I'm
going
to
try
and
do
that
in
the
next.
C
You
know
15-20
minutes
and
you're,
going
to
see
how
quickly
I've
moved
that
out
to
Cloud
right
because
of
the
capabilities
that
service
interconnect
gives
you
right.
So,
as
we
just
saw
right,
Ben
started
with
the
monolith
right
and
he
broke
that
up
into
the
front
end
and
the
back
end
and
they've
been
containerized
in
there
right.
A
B
C
What
actually
happens
there
is,
you
know
when
your
containerize,
that
is,
we've
got
his
ear
file
that
he
generated
here,
which
he
has
there.
It
is
there
We've
copied
the
ear
file
and
we've
just
basically
as
the
integrator,
which,
because
remember
I'm,
wearing
the
head
of
the
integrator,
now
I've
taken
his
ear,
I've
written
the
docker
file
for
the
front
end
and
I've
got
a
separate
Docker
file
for
the
back
end,
and
now
these
things
are
both
running
as
a
container
on
the
same
virtual
machine.
C
All
right,
and
in
this
case
here
I'll
just
quickly
show
you
the
application
running
right.
So
it's
running
this
is
the
database
there
and
I've
got
the
back
end
and
I've
got
the
front
end
running.
There's
two
containers
on
my
virtual
machine
right
and
we
can
now
use
the
application
right
and
I'll
just
quickly
myself
in
there
and
we'll
go,
let's
go
and
we'll
view
the
queue
and
that's
all
running.
C
I'm
going
to
have
the
back
end
running
on
an
on-premises,
openshift
cluster
and
I'm,
going
to
have
the
front
end
running
on
a
public
Cloud
hosted
openshift
cluster
doesn't
have
to
be
openshift,
it
could
be
eks.
Gke
AKs
doesn't
really
matter
right,
whatever
flavor
it
may
be,
but
that's
what
we're
going
to
end
up
right,
but
the
first
step
I'm
going
to
show
you
is
I'm,
going
to
move
I'm
going
to
redeploy
that
front
end
onto
openshift
on
premises
right
and
we're
going
to
do
that
with
no
application.
Changes
from
this
point
forward.
C
Okay,
but
what's
interesting
about
this,
is
when
the
front
end's
now
going
to
talk
to
the
back
end,
but
traditionally
you'd
be
doing
that
when
you're
Crossing
systems
here
you're
going
to
do
that
with
TC
with
DNS
right.
But
we're
not
going
to
use
we're
going
to
talk
like
it's
localhost.
The
front
end
thinks
it's
talking
to
the
back
end
via
localhost.
So
oh
my
God,
no
DNS.
How
are
we
going
to
do
that?
C
So
the
front
end
still
thinks
it's
talking
Local
Host
here,
but
it's
actually
going
to
get
redirected
over
here
and
then
talking
down
to
the
database
there
right
and
then,
when
we've
finished,
that
we
can
now
decommission
the
front
end
right
so
now
you're
getting
the
idea
about
how
you
know:
Ben's
done
that
small
change
refactor
that
as
part
of
Bru
or
project
investment.
But
now
we
can
continue
to
move
that
thing
out
to
the
public
Cloud,
so
without
further
Ado.
Let's
get
going
so
we've
got
there.
C
Just
make
sure
that
that's
all
deployed
it
is
it's
all
running
good.
Okay!
Now
the
first
thing,
if
you
remember
I,
said
well,
we've
got
to
deploy
this
router
right,
so
we're
going
to
now
deploy
a
this
service
interconnect
router
to
to
the
cluster.
So
we're
going
to
do
that.
We're
going
to
have
the
site
name
is
going
to
be
on-prem
I'm,
going
to
enable
a
console
that
you'll
see
shortly
okay
in
there
and
so
we're
doing
that
with
the
scuppernic
command.
Okay
and
we
can
ignore
These
Warnings.
C
This
is
just
about
a
new
the
next
generation
of
kubernetes,
there's
some
extra
security
stuff
that
we
that
you
need
to
pay
attention
to.
But
it's
someone
says
right.
So
I've
now
deployed
that
out
to
to
the
Costa.
So
let's
just
quickly
make
sure
that's
powered
up
yep,
everything's
running
good,
all
right!
C
So
now
we
can
actually
see
if
I
come
over
to
here
onto
my
openshift
cluster
I've,
now
got
my
front
end
that
I
deployed
before
okay
and
I've
now
deployed
my
service
interconnect,
router
Router
out
to
there
I'm
not
going
to
open
up
the
console
and
I
can
see.
My
network,
and
at
the
moment
it
only
knows
about
itself
and
that's
because
we
haven't
created
the
Gateway
yet
so
let's
go
and
do
that
all
right.
C
So
what
we
wanted
to
do
right
is,
if
you
remember,
is
we
wanted
to
right,
create
the
we're
going
to
create
the
Gateway
on
premises,
so
we
can
get
to
the
back
end.
Okay,
so
let's
go
and
do
that
so
what
I'm
now
doing
is
I'm
exposing
what's
running
on
localhost
right
because
remember,
the
database
is
running
on
openhost
port
8080
is
the
back
end
and
I'm
going
to
kubernetes
uses
service
names
for
things
to
be
able
to
intercommunicate
across
pods
right,
so
we're
going
to
expose
that
as
the
service
backend
right.
C
So
now,
let's
actually
have
a
look
at.
What's
going
on
here,
have
created
the
Gateway
right
and
now
what
you'll
see
is
running
the
pods
running
on
the
cluster
is
front
end:
okay
and
I've
got
a
corresponding
service
front
end
running
on
the
cluster,
but
what's
interesting
here
is
that
there
is
a
back-end
service,
but
look
there
is
no
back-end
pod
running
on
there.
That's
just
how
it's
creating
this
service
proxy
for
you
to
sit
over
there.
That
means
that
the
front
end
can
now
talk
to
a
local
back-end
service.
Okay.
C
C
C
Right
here
we
can
see
that
I
have
a
local
site
on
premises
and
it's
now
got
a
service.
That's
made
available
as
backend
alrighty.
Okay.
So
now,
if
I
go
over
to
here,
we
can
see
on
the
console.
Is
I've
now
got
my
Gateway
available.
Okay
and
I'll
come
back
to
the
components
in
the
in
a
second,
but
let's
go
and
try
and
check
that
everything's
working.
C
C
Okay-
and
you
know
we
can
see
that
everything's
working
there
right.
So
that's
that's,
what's
happened
now.
The
only
thing
now
left
to
do
right
is
well.
We've
moved
the
front
end
out
to
the
on-premises
openshift.
So
what
I
can
really
do
now
is
I
can
kill
my
front
end,
but
before
I
do
that
I
want
to
show
you
how
the
Magic's
happening
right
so
for
a
show.
You.
C
So
kubernetes
talk,
the
front
end
is
talking
to
the
back
end
on
kubernetes
Via,
the
back
end
service
and
the
way
the
magic
that's
happening
here
is
that
the
way
a
service
works
is
the
selector
tells
it
what
pod
to
redirect
that
service
call
to
well
in
this
case
here,
the
selector
is
actually
the
router
and
that's
what's
happening.
So
the
router
is
able
to
intercept
the
call
to
the
back
end
right
and
then
it
picks
it
up
and
then
says:
where
does
that
live
on
my
service?
C
Interconnect
Network
I
find
that
by
the
Gateway
and
it
delivers
it
over
there.
Okay,
so
that's
the
magic
that's
happening
there,
so
the
next
thing
to
do,
of
course,
is
well.
I
can
now
kill
my
front
end.
So
if
I
look
at
my
current
odds
that
are
running
but
we've
got
the
database,
the
back
end
the
front
end,
my
Gateway
that
I
created
before
well
now
we
can
actually
kill
the
front
end
because
we
don't
need
it
anymore.
Right.
C
A
C
Is
we're
effectively
at
this
state
right?
So
we've
moved
the
front
end
out
to
here
and
we've
decommissioned
everything.
Okay,
so
this
is
where
we
are
now
right.
The,
Next
Step
will
be
to
take
that
front
end
out
to
the
public
cloud
and
I'm
going
to
do
that
again
with
no
application
code,
changes
right
and
we're
going
to
do
that
because
we're
going
to
add
a
router
out
here
and
it's
going
to
create
the
back
end
and
make
it
visible
over
there.
C
So
with
that,
the
first
thing
I'm
going
to
do
is
I'm
going
to
deploy
the
front
end
to
Sydney
now
I
didn't
I
should
have
mentioned
this
before
is
this
here
is
my
on-premises
cluster,
and
this
is
my
Sydney
cluster.
Okay,
now
I'm
gonna
terminate
it
can
be
a
little
bit
problematic
for
me
hitting
the
hot
spot
there.
But
let's
move
that
over
here.
So
first
of
all,
we'll
deploy
the
front
end
by
the
way.
C
If
this
font
size
is
too
small,
just
put
it
in
the
chat
and
we'll
get
that
increase
off,
deploy
the
front
end
and
now
the
next
thing
to
do,
but
of
course,
is
not
going
to
be
able
to
talk
to
anything
so
I'm,
not
even
going
to
test
that
there
is,
but
we
know
it's
deployed
the
Sydney.
But
what
I
need
to
now
do
is
create.
Is
deploy
service,
interconnect
out
to
Sydney
so
I'm,
adding
that
other
router?
Okay.
C
But
of
course,
if
I
look
at
these
services
in
the
connect
console,
it's
not
been
added
yet
so,
even
though
you
can't
see
it
right,
it's
even
though
I've
deployed
it
to
Sydney,
because
this
console
is
being
right,
served
out
of
on-premises.
You
can't
see
it
on
there.
That's
because
I
have
to
create
the
mesh
Network
right,
and
this
is
really
key
here.
What
we're
going
to
do
is
we're
going
to
set
up
an
mtls
connection
right
from
Sydney
to
on-premises
and
the
way
we
do
that
is
we
do
it
from
high
trust.
C
The
corrections
connection
has
to
be
from
high
trust
to
low
trust.
This
is
how
I
said
remember.
It
rides
on
top
of
endorsed
Network
flows.
So
what
I'm
going
to
do
is
I'm
going
to
create
a
token
in
Sydney
import
it
into
Melbourne
into
the
on-premises
right
and
have
that
then
reach
out
and
establish
that
connection.
So
let's
go
and
do
that.
B
C
C
C
C
C
Okay,
and
now
you
can
see,
is
I've
got
on
premises.
Router
and
I've
got
a
Sydney
router.
The
back
end
service
is
available
on
premises
and
it's
also
automatically
available
over
in
Sydney.
So
now,
if
I
go
get
my
pods
and
service
in
Sydney
you'll
see
I've
got
the
Pod
running
in
front
end.
If
the
back
ends
and
it's
down
here,
but
the
back
end
service
is
now
immediately
visible.
C
C
My
components,
I've
got
running,
I've
got
whatever's
behind
the
gateway
and
my
front
end,
and
the
component
represents
a
collection
of
PODS
that
have
the
same
name.
Right
are
part
of
the
same
deployment,
irrespective
of
where
they
are,
and
the
processes
right
that
are
running
out
here.
Well,
there's
a
link
from
front
end
to
the
to
the
Gateway
here
from
from
on-premises
to
there
there's
been
no
traffic
yet
so
you'll
see
that
there's
nothing
going
there,
so
let's
actually
go
and
run
that
right.
C
I,
Now,
launch
the
front
end
from
Sydney
and
I
can
view
the
Cure
and
high
press
star
I've
now
moved
that
front
end
out
to
Sydney
it's
integrating
all
the
way
to
the
back
end,
that's
on
premises,
I
didn't
touch
a
single
line
of
code
right
and
I.
Did
it
in
how
much
time,
probably
about
five
minutes
or
like
I've
had
been
talking?
I
could
have
done
it
in
35
seconds
right.
C
It
is
everything,
thinks
it's
talking,
localhost
right
and
all
I'm
doing
is
I'm
just
creating
this
using
the
mesh
to
actually
just
publish
the
proxies
there
right.
So
now,
I've
actually
got
that
thing
running
in
Sydney.
I
can
now
come
back
to
on
premises
and
now
I
can
actually
delete
my
on-premises
front
end.
C
D
C
C
C
The
next
step
is
we're
going
to
move
from
here
right
and
I'm
now
going
to
take
the
back
end
and
I'm
going
to
move
that
to
on-premises
and
decommission
the
back
end
on
there
and
then
we're
going
to
end
up
with
this
situation
where
the
front
end
is
going
to
be
running
in
the
public
Cloud.
The
back
end
will
be
running
on
premises
and
then
the
database
will
still
be
running
on
the
traditional
infrastructure.
D
C
C
If
I
look
at
on
premises,
you
see
I'm
running
at
the
back
end
service,
that's
been
exposed.
The
first
thing
we're
going
to
do
now
is
we're
going
to
expose
the
database
all
right
and
now
that's
going
to
make
that
available
to
kubernetes
right
we're
using
the
service
name,
DB,
okay
and
if
I
now
look
at
the
services
that
are
running
I've.
Never
the
DB
service
available
to
openshift.
C
C
C
Gateway
oops,
it's
two
things:
now
it's
got
the
back
end
and
it's
got
the
database,
but
I
don't
need
that
database
anymore.
That
back
end
because
I've
got
the
data
back-ends
to
pour
there.
So
what
I'm
going
to
do
is
I'm
now
going
to
unexpose
that
back
end
okay,
so
we
do
that
in
there
that's
good
and
then
what
I
can
now
do
actually
I
just
want
to
check.
Sometimes
when
you
start
the
back
end,
it
there's
trouble
connecting
to
OC
blogs.
I
just
want
to
check
the
started
up.
C
C
C
That's
running
on
openshift
and
publish
that
to
the
service
interconnect
Network,
so
I'm
going
to
expose
that
deployment
backend
and
you
communicate
it
by
port
8080.,
and
once
that's
done,
if
I
look
in
Sydney
you'll
see
the
back
end
is
now
available.
That
means
the
front
end
in
Sydney
will
be
able
to
talk
to
the
local
back
end
and
then
the
back,
which
will
hit
the
back
end
that's
running
in
in
Melbourne,
okay,
and
then
we
go
so
if
we
can
now
actually
quickly
run
down
here.
C
C
All
right
in
there
right
and
so
now,
what's
actually
happening
here
is
so
oh
okay.
That
was
a
bit
interesting.
Let
me
just
try
the
other
notes.
I
can
drag
it
over
is
a
brand
new
version
of
the
console
right.
So
it's
kind
of
deciding
what's
happening
here
and
you'll
see
some
flows
that
take
a
little
bit.
A
C
So
we've
got
Sydney
right
the
front
end
just
talking
to
the
back
end,
that's
running
on
premises
there,
which
is
talking
to
the
database
over
here.
This
front
end
here,
which
we're
still
running
on
premises.
The
the
cache
route
will
refresh
in
probably
about
five
more
minutes
and
then
that
one
will
disappear.
So
that's
lingering
around,
even
though
that
doesn't
exist
anymore.
C
C
C
And
my
front
end
is
running
in
Sydney
and
so
now
I've
decommissioned
everything
moved
everything
there
and
what
we're
actually
now
got
sitting
there
is.
We
are
now
here
it's
when
we
started
with
this
model
of
the
Ben
broke
up,
showed
you
how
your
breakup
of
a
Java
monolith
into
different
ear
files,
the
integrator,
could
then
take
those
ear
files,
it'll
put
them
into
Docker
containers
that
can
then
be
deployed
and
run
on
a
virtual
machine.
The
integrator
then
was
able
to
take
those
and
then
progressively
migrate
them
out.
C
C
What's
really
an
important
takeaway
here
right
is
that
when
we
did
this
is
the
unit
of
change
was
Tiny
once
as
that
implementing
that
business
feature
with
now,
containerized
that
and
I
can
take
that
stuff.
All
out.
I
don't
need
a
big
migration
program.
This
is
the
next
generation
of
cloud.
Migration
is
what
I'm
talking
about
right,
this
Progressive
migration
right,
so
we
strangled
it.
As
I
said
into
the
virtual
machine.
We
packaged
it
into
containers.
C
We
prepared
the
application
for
cloud
using
openshift,
so
openshift
is
that
stepping
stone
to
published
cloud,
and
then
we
demonstrated
that
location.
This
application
and
progressively
migrated
all
of
those
out
to
the
public,
Cloud.
Okay
and
that's
I
said
it
can
be
done
of
a
normal
application,
life
cycle
planning
and
that's
kind
of
the
end
of
the
story.
Right
all
of
the
hard
work
was
done
by
Ben
yeah.
A
Which
makes
you
the
smartest
guy
in
the
room,
so
so,
and
so
it
was
funny
because,
as
we
were
prepping
the
show
we
talked
about
naming
and
it
was
the
evolution
of
cloud
migration
or
is
it
the
next
and
I
get
the
next
now?
This
is
not
the
end.
This
is
we're
into
a
new
phase
right.
We,
this
is,
you
know
and,
and
Brian
has
shared
this
internally
of
course,
a
lot,
and
you
know,
wherever
you
can
find
him,
he'll
talk
about
it,
but
wow.
When
you
see
it
like
that,
I
mean
yeah.
B
B
Vm
absolutely
I
was
just
thinking
of
the
same
thing.
August.
Initially
we
were
kind
of
debating.
You
know
the
title
of
this
whole
presentation
and
I
was
I.
Was
you
know
we
had
our
reservations.
I
was
thinking
is
Brian
and
Ben
Guru
bringing
a
new
R.
You
know.
Is
there
another
seventh
or
eighth
time,
because
you
know
like
bringing
it
from
monolithic
to
microservices
it's
hard
right.
The
whole
migration
piece
is
hard.
B
It
involves
a
lot
of
effort,
a
lot
of
time
and
cost,
and
you
know
think
of
it
from
an
application
owner
point
of
view
right.
They
really
want
service
continuity.
They
want.
You
know
the
best
out
of
you
know.
Whatever
resources
they've
got
and
you
know
the
way
Ben
and
Brian
showed
us
really
seamlessly.
You
know,
move
from.
You
know
model
to
microservices
how
it
can
be
extended.
B
It
is
location,
agnostic,
right,
it's
it's
I,
think
in
its
true
sense,
when
you
know
Brian
initially
mentioned
simplified,
hybrid
Cloud,
new
architecture,
it
really
brings
it
back
and
to
be
able
to
visualize
all
these
flows.
It
really
becomes
simple.
You
know
because,
from
a
developer
point
of
view,
it
is
zero
code
change.
You
know
if
I
think
about
it
from
an
integrator
point
of
view.
B
It's
really
you
know
simplified
and
agnostic
and
I
have
you
know
I
have
one
question
for
you
know
you
both
and
really
thank
you
for
your
whole
demo,
I
I
really
loved
it.
I
enjoyed
it
I'm
excited
to
learn.
You
know,
I'm
sure
you
know
you
are
championing
it
with
all
our
customers.
I'm
excited
to
learn.
You
know
what
you
see.
You
know
that
customers
are
asking
in
terms
of
you
know,
use
cases,
and
you
know
what
has
been
that
that
question
from
the
customers.
C
C
So
there's
this
this
idea
that,
if
you're
on
premises
we've
got
you
can
create
from
an
application
point
of
view,
the
the
A's,
even
though
you're
running
on
multiple
clusters,
a
single
cluster
experience
right,
which
is
really
it,
takes
a
lot
of
using
a
global
load
balancer
to
to
deal
with
it
and
then
having
to
do
with
sticky,
sticky
sessions,
and
things
like
that
becomes
really
really
hard
right.
So
you
can
actually
create
this
single
cluster
experience
for
your
application,
which
simplifies
your
application
architecture.
C
The
other
thing
you
can
use
it
for
is
cloud
bursting
right.
It
actually
works
really
well
for
cloud
bursting,
because
the
router
is
a
cost-based
router.
So
if
you're,
if
you're,
actually
call
calling
something,
that's
on
premises
and
it's
becoming
non-responsive,
it's
overloaded
or
whatever
it
can
legitimately
just
burst
out
the
cloud
it
needs
to
be
so
you
can
actually
do
real
life
Cloud
bursting,
but
it's
not
actually
or
academic
Disaster
Recovery
right.
B
C
Application
team's
in
charge
of
it
right,
not
a
platform
T,
and
so
you
know,
there's
only
like
three
moving
Parts
with
service
interconnect.
The
other
thing
is:
if
you've
got
some
like
third-party
products
like
redis,
rabbit,
mq,
Kafka,
that
all
none
of
them
work
in
a
multi-cluster
scenario
right.
What
you
can
do
is
you
can
actually
make
those
things.
C
Work
think
that
they're
working
on
a
single
cluster
using
service
interconnect
because
and
normally
the
way
you
have
to
do-
that
is
opening
up
no
ports
right,
you'd
need
a
global,
wide
area,
Network
and
and
either
using
Submariner
or
istio
multicaster
right,
which
are
all
very,
very
complex.
Solutions.
This
way
can
actually
have
a
globally
distributed.
Redis
coach,
for
example,
right
and
all
running
on
kubernetes,
and
it
doesn't
know
because
redis
thinks
it's
working
or
one
cluster
it
it's
been
tricked
by
service
interconnect.
D
Mean
sorry
Ben
go
on
yeah,
oh
yeah
I
just
love
it
because
it's
fast
and
easy
to
set
up.
You
can
see
how,
but
you
know,
within
a
few
seconds,
Brian
had
connected
those
sites.
He
have
connected
the
services
even
for
developer
use
cases.
It's
fantastic
like
just
to
be
able
to
say,
I
need
to
connect
to
the
the
database
to
test
my
little
Solution
on
my
laptop
I
I
could
do
that
at
Discover,
so
there
there
is
lots
of
benefits
to.
A
C
It's
really
a
Swiss
army
knife.
It's
amazing
every
time,
there's
new
use
cases
that
pop
up
for
it
all
the
time
right
all
I'll
say
is
it
comes
with
one
key
requirement.
Is
it
needs
a
stable
connection
between
the
routers?
It
can't
be
one
that's
floppy
right,
because
the
routers
need
to
establish
where
you
can
you
know
so
you
want
to
if
you're,
using
your
nudge,
it
needs
to
be
a
connected,
Edge
right
things
like
that.
A
Wow,
a
very,
very
impressed
by
this
and
I'm
really
excited.
We
had
been
planning
and
talking
about
the
show
for
ages
and-
and
you
know
to
have
the
demo
and
and
I'll
say
it
now-
the
demo
worked,
there
was
no
any
issues
there.
You
know
everyone
always
says
before
demo
pray
to
the
demo,
Gods
I
purposely
did
not
say
it.
Everyone
was
just
like
yep,
it'll
be
fine
and,
and
it
worked
really
well
so
I
mean
look.
A
A
There,
we'll
put
it
we'll,
put
it
in
the
show
description,
your
home
phone
number
the
whole
bit
and
then,
of
course
we
talked
about
this
before,
but
you
know
it's
being
talked
about
more
at
Red,
Hat
Summit
and
if
you
happen
to
be
in
Boston
in
May
head
on
over
to
and
and
you
know,
sign
up
or
if
you're
interested,
please
reach
out
to
anyone
on
the
show.
We
can
help
connect
you
with
resources
over
there
to
learn
more
about
this
and
and
talk
more
about
it.
A
C
A
Brilliant
all
right,
well,
another
awesome
show
again
you
can
follow
us
along
at
the
live
streaming
calendar.
We
have
another
show
coming
up
soon,
I
think
in
about
two
weeks
we're
going
to
talk
a
bit
about
security,
so
that
should
get
very,
very
interesting
and
fun,
but
for
now
that's
about
it
from
all
of
us,
so
guys
Brian,
Ben,
any
last
words
or
you
know
anything
else.
You
want
to
add.