►
From YouTube: Leave Your Legacy: Real Strategies for Modernizing
Description
Most large enterprises have a lot of legacy developed over the years, but they need to embrace microservices quickly to beat the competition. The right approach for these large enterprise is not a big-bang strategy but rather an incremental strategy. In this Kong Summit 2019 session, Infosys AVP and Head of Architecture, Rajib Deb will explain how leveraging an API gateway and “servicifying” the legacy can help expedite the process for organizations adopting microservices architectural patterns.
A
Good
afternoon
everyone,
so
this
is
a
quote
not
from
any
great
man.
This
is
something
from
my
own
experience
and
the
architects
who
share
the
same
mind
share.
Write
like
modernization
is
not
then
stated
as
beginning
of
the
next
stage,
and
this
particular
quote
right.
It
is
based
on
the
experiences
that
I
have
got
since
I
joined
the
industry
almost
24
years
back
right,
it
started
with
mainframes,
then
did
oracle.
A
Now
why
one
put
this
quote
is
because
whatever
I
say
today
right,
that
is
not
the
end
of
it
right,
so
something
new
will
come
in.
So
that's
as
an
architect
I
believe
that
the
architecture
that
we
developed
right
we
should,
we
should
think
of
that
architecture,
not
as
a
nonliving
object.
It's
a
living
object
and
it
should
evolve
right.
It
should
evolve
based
on
the
new
innovations
that
that
comes
in
to
the
technology
world
right.
A
Unfortunately,
we
have
been
building
applications
in
a
very
rigid
monolith
way
that
application
architecture
needs
to
change
to
more
of
like
a
product
architecture.
I
will
give
you
a
recent
example,
so
it
was
building
this
data
ingestion
and
analytics
framework
for
a
bank,
and
the
initial
requirement
was
to
gather
data
from
AWS
s3
put
it
into
a
parka
file
on
s3.
But
what
happens
if,
tomorrow
there
is
a
better
storage
engine?
There
is
a
better
storage
output.
How
do
I
do
that
right?
So
what
we
did
is
we
created
a
framework.
A
A
A
Applications
faster
to
the
consumers
of
the
data
are
the
business
right,
so
business
agility
is,
is
the
one
of
the
most
important
factors
of
the
modernization
I
see
lot
of
the
organizations
are
kicking
of
modernization
or
data
modernization
engagements
to
meet
the
data
security
requirements
as
I
speak
for
many
of
our
customers.
We
have
kicked
off
a
data
disposal
program
like
because
there
is
a
data
compliance
rule
that
has
come
up,
which
is
called
CCP
a
California
consumer
Privacy
Act
right,
which
is
similar
to
the
European
GDP
requirements.
But
that's
just
one
example.
A
In
many
places
we
are
replacing
proprietary
products
with
custom-built,
open
source
based
application
and
I'm
sure,
like
maybe
seven
eight
years
back,
nobody
would
have
taken,
or
nobody
would
have
been
so
bold
to
take
such
steps.
But
now
we
are
able
to
do
this
because,
when
I
look
at
the
open
source
world,
there
are
a
lot
of
components.
A
Very
mature
components
like
spark
like
Kafka
I,
was
looking
for
a
parser
that
a
person,
because
one
of
the
data
ingestion
I,
was
able
to
find
a
lot
of
this
mature,
open
source
products
that
I
can
put
together
and
create
something
that
is
almost
similar
to
a
proprietary
product.
A
lot
of
organizations
are
moving
out
of
this
proprietary
products
and
building
their
own
custom
develop
products
which
is
their
system
of
differentiation
right.
So
the
next
I'll
come.
A
A
People
are
still
little
scared
to
test
the
system
of
Records
right,
so
they're,
the
pace
of
change
is
slow,
but
there
are
patterns
there
as
well,
because
I
still
need
that
system
of
record,
which
is
in
the
mainframe
db2,
which
is
not
very
easily
accessible
outside
mainframe
I
still
need
that.
So
the
pack
one
pattern
I
have
seen
as
offloading
the
data
for
the
new
wall
to
access.
A
So
your
system
of
record
still
remains
in
the
legacy,
but
now
have
a
system
of
reference
which
the
new
world
or
the
new
architecture
will
use.
The
digital
applications
will
use
and
there
are
multiple
ways
you
can
get
it,
so
we
have
done
it
using
Kafka
using
MQ
using
various
change
data
capture
products
and
all
right
and
it's
a
very
successful
pattern.
A
My
session
was
named
as
living
legacy.
That
was
actually
not
right
right.
How
many
of
you
believe
that
mainframe
will
not
exist
in
another
five
years
or
legacy
will
not
exist
in
the
five
years?
No
takers
good
I
expected
that
I
started
hearing
mainframe
get
rid
of
mainframe
when
I
join
the
industry
right.
A
Maybe
my
my
parents
also
here
heard
the
same
when
they
were
just
towards
the
end
of
their
service
right,
but
till
still
mainframes
are
there
so
legacy
or
mainframes
are
not
my
belief,
I'm
not
going
to
go
away,
at
least
in
my
lifetime
right
I,
don't
know
what
will
happen
in
my
when
my
daughter
will
grow
up
right,
but
in
in
my
lifetime
I'm
not
seeing
legacy
and
mainframe
is,
is
going
away.
They
are
going
to
stay.
A
A
It
should
be
gradual,
gradual
movement
or
gradual
transformation
to
the
new
world
of
micro-services
architecture
and
I'm,
going
to
talk
a
lot
about
that
when
I
talk
about
the
integration
pattern
in
the
slides
that
will
come
up
after
after
this
slide
right,
so
the
other
thing
that
I
actually
wanted
to
highlight
in
this
slide
any
modernization.
If
you
retrospect
write
whatever
you
are
working
on,
what
is
driving
the
organize
the
modernization?
A
What
I
see
is
data
data
is
driving
the
organ
the
modernization,
but
when
you
start
modernizing
the
data
like
when
you
try
to
get
the
data
quickly,
get
the
data
ingest
it
quickly
consumed
in
a
better
way.
You
also
touch
the
application
and
finally,
you
also
touch
the
platform
on
which
the
the
applications
are
deployed
right,
so
that
that's
one
thing
I
wanted
to
highlight
here
now:
there
should
be
combination
of
strategies,
combinations.
There
are
non-invasive
strategy,
there
are
invasive
strategy
and
this
slide
is
self-contained
in
a
way
like
it.
A
The
different
techniques
of
modernization
vary
hosting
I
think
we
are
very
familiar
with
this
one
very,
very
host
mainframe
to
a
x86
architecture,
refactoring,
where
we
refactor
try
to
refactor
the
existing
code.
Try
to
optimize
it
integration
that
what
I'm
going
to
talk
more
about
today.
This
is
a
very
popular
technique,
and-
and
this
is
the
technique
which
helps
legacy
and
the
contemporary
to
coexist
and
in
transform
right
and
some
of
the
invasive
techniques.
A
So
integration,
that
is
the
technique
that
is
very
much
in,
is
in
use.
Now
it
is
very
popular
and
how
you
do
it
is
if
a
function
or
business
processes
in
running
in
legacy,
you
wrap
that
applicator
wrap
that
module
service.
If
I
ate
right,
you
you
and
then,
and
then
renew
it
and
any
underlying
business
flow
workflow
that
is
there,
you
abstracted
the
business
rules,
you
extract
it
and
bring
it
outside
of
the
system.
If
I
show
you
the
next
picture,
it
will
be
more
clear
right,
so
we
start
with
a
monolith.
A
It
may
be
a
by
the
way.
Mainframe
is
not
the
only
legacy
monolith.
There
are
Oracle
applications,
there
are
Java
applications
which
are
monolith
which
are
legacy
right.
Those
also
needs
modernization,
but
approach
for
this
integration
technique
is
similar
right
where
you
service,
if
I
the
monolith.
That
is
the
first
step
right
now
in
for
the
mainframe
we
use
products
like
z/os
connect,
type
of
or
Kix
CICS
gateway
to
to
api
phi.
In
one
of
the
management's,
there
is
an
interesting
approach
we
have
taken.
A
We
are
writing
db2
procedures
and,
whatever
logic
is
there
in
this
CICS
COBOL
that
logic
we
are
pushing
into
the
db2
procedure
and
that
is
exposed
as
an
API
for
the
API
gateway
to
consume
right.
So
once
you
service,
if
I
the
monolith,
the
next
thing
is
to
create
a
strangler
facade.
You
might
be
hearing
a
lot
of
terms
for
this
right,
but
ultimately
it
is
a
strangler
like
people
will
be
telling
that
it's
a
particle
layer.
A
Some
people
says
it's
a
speed
layer
and
then
there
is
some
people
will
say:
that's
as
an
anti
corruption
layer
right
this
our
marketing
type
of
tunnel,
but
technically
it
is
a
layer
that
helps
you,
strangle
the
monolith
and
decompose
into
services.
Gradually
there
is
one
more
myth
in
this
technique
that
I
need
to
completely
move
out
of
monolith.
That
is
absolutely
not
required.
A
You
need
to
do
a
cost-benefit
analysis.
Sometimes
I
will
stop
at
the
third
step
like
where
transform
and
coexist,
because
breaking
the
monolith
further
into
micro
services
does
not
give
me
any
substantial
business
benefit
right.
So
I
don't
need
to
completely
move
out
of
legacy
right.
That's
where
I
can
decide
to
either
coexist,
transform
or
completely
move
out
as
well
right.
A
We
are
following
this
approach
for
many
of
our
engagements.
One
of
the
one
of
the
engagement
is
is
with
an
utility
company
right
where
they
have
a
monolith,
Oracle
and
dotnet
based
utility
platform.
It
uses
Oracle
aq,
so
they
recently
acquired
another
company
and
when
those
customers
will
also
come
to
that
platform,
what
they
have
seen
is
that
the
platform
with
its
current
set
of
consumers
only
is
not
able
to
scale
not
able
to
meet
the
requirements
of
of
the
load
and
the
scale
right.
A
So
if
three
or
four
million
customers
on
board,
then
it
is
going
to
go
down.
So
we
started
modernizing
that
following
the
same
approach
right
where
we
are
using
spring
boot,
apache
camel
for
orchestration
and
Kafka
for
choreography,
we
are
taking
one
service
at
a
time.
Moving
to
the
micro
services
based
architecture,
there
is
an
API
gateway.
When
the
request
comes
for
a
particular
API,
the
API
gateway.
It
then
routes
it
based
on
like
where
the
service
is
lying
right
now.
Is
it
still
in
legacy
or
in
the
services
right?
A
Both
should
update
that
data,
so
I
said
no,
and-
and
this
is
and
why,
when
you
move
a
service
to
a
to
the
new
world,
the
stewardship
of
that
particular
domain
that
it
manages
needs
to
decide
with
only
one
owner,
multiple
owners,
if
you,
if
you
try
to
have
multiple
owners,
update
and
write
the
data.
If
you
have
lot
of
problems-
and
this
is
I'm
telling
you
from
experience-
we
have
done
this
in
one
place
and
then
we
kept
on
creating
data,
synchronization
role
and
it's
a
vicious
circle.
A
So
when
you
move
out
that
domain,
along
with
the
service,
the
stewardship
of
that
domain
should
lie
with
a
single
owner.
And
finally,
we
did
that
the
data
can
be
read
right.
You
can
still
move
the
data
like
using
CDC
and
all
to
the
world
world
for
the
downstream
to
take
care,
but
only
for
read
not
to
update
the
data.
A
There
does
not
exist
a
magic
wand
which
will
tell
you,
okay,
these
are
the
services
that
you
go
in
and
build
it
right.
We
are
trying
some
approaches,
which
is
a
bottom-up
approach.
By
looking
at
the
code.
Looking
at
the
database
looking
at
the
transactions
using
some
AI
ml,
mechanics
can
I
identify
the
services
so
far.
We
have
not
been
successful
yet,
but
I
hope,
maybe
you're
one
year
down
the
line,
we'll
see
some
successes
success,
but
as
of
now
how
this
approach
happens,
it
is
a
top-down
approach.
A
You
take
the
business
standards.
There
are
some
business
specification,
for
example,
for
financial
services
beyond
is
a
standard
like
if
you
want
to
create
a
payment
service,
the
beyond
tells
you
how
to
create
like
there
are
some
specifications
at
the
mandate.
So
you
take
that
specification.
You
take
the
reference
business
architecture
and
there
were
brainstorming
sessions
or
event
storming
with
your
business
to
come
up
with
the
list
of
services
or
the
catalog
of
services
that
you
need
to
build
right.
A
The
output
of
this
exercise
should
be
a
capability
map,
and
this
is
what
we
are
trying
as
I
speak.
We
are
trying
to
see
if,
if
we
can
automate
that
so
far,
the
domain
definition
in
the
process
definitions,
we
are
able
to
extract
using
some
automated
way,
but
that
would
be
like
less
10
to
20
percent
of
the
success
rate
and
so
ideally,
process
capability
is
nothing
but
a
group
of
similar
process,
definitions
that
you
bundle
together
and
that
is
exposed
as
an
API
to
your
business.
A
That
is
what
means,
as
as
the
domain
of
that
particular
service
right
and
the
process,
definition
may
encompass
one
or
more
domain
models.
So
this
is
what
I'm
showing
you
right
now,
that
is
for
a
core
banking
application.
We
have
similar
capability
modules
for
retail
industry,
for
manufacturing
industry
for
energy
industry.
The
approach
is
same
only
the
capabilities,
the
domains
and
the
processes
change.
A
How
the
reference
architecture
look
like
so
in
the
target
reference
architecture,
the
API
layer
plays
a
very
important
or
key
role,
if
you
think
of
this
as
a
nervous
system
right
human,
another
I
like
to
see
architectures
like
a
human
body
right.
So
if
you,
if
you
think
this
is
a
nervous
system,
the
API
is
I
in
the
brain
and
that
bottom
layer,
you
have
the
system
api's
right,
which
are
stateless
transactions,
which
are
the
data
API,
is
like
the
your
domain.
A
Objects
are
exposed
through
those
api's
and
then
in
the
process
layer
you
have
the
process.
Api
is
the
process.
Api's
should
not
know
how
the
data
is
structured
or
how
the
data
is
designed
tomorrow.
I
might
want
to
use
a
completely
different
data
structure
or
a
completely
different
data
base,
but
for
that
I
should
not
have
to
touch
that
the
process
layer
right.
That
is
what
so,
that
part
is
being
extracted
by
the
system
api's.
So,
once
your
process
layer
is
develop
your
process
api's.
On
top
of
it,
you
build
your
experience
api.
A
So
if
you
think
of
this
thing
right,
it's
a
inverted
funnel
right.
You
have
all
of
your
data,
then
the
process
takes
the
data
and
finally,
in
the
experience
layer
is
where
you
do
further
filtering
further
aggregation
and
give
that
data
like
like
the
consumption
model
for
the
consumer
right,
because
your
data
may
be
consumed
internally
or
by
partner,
but
the
way
a
internal
employee
consumes.
The
data
may
be
different,
like
a
partner
consumes
that
data,
the
data
attributes,
the
data
fields
may
be
different,
and
that
is
where
you
do
in
the
experience
API.
A
So
the
external
appear,
so
there
is
an
API
management
layer
externally
and
internally,
the
external
API
management
layer
should
take
care
of
your
throttling.
If
somebody
wants
to
do
a
DDoS
attack
and
all
right
that
should
capture
it.
The
authentication
right
so
that
external,
when
there
is
a
external
request
right,
if
it
is
a
if
it
is
a
malicious
request,
it
should
be
stopped
at
that
API
layer
itself.
It
should
not
go
inside
right.
So
a
lot
of
people
ask
me:
why
need
I
need
to
have
it
outside
the
DMZ?
That's?
Why?
A
That
is
why,
when
you
select
an
architecture
like
this
selecting
the
API
product
also
becomes
very
important.
There
are
a
lot
of
products
available,
but,
and
none
of
the
products
are
good
or
bad.
It
depends
on
what
your
architecture
needs.
That
is
why
you
need
to
do
a
product
evaluation
and
choose
what
is
the
right
product
for
for
my
architecture,
based
on
what
I
need.
A
A
So
far
we
have
seen
modernization
the
strategies
and
then
the
the
integration
technique
and
all
right,
but
it
is
not
easy
to
implement
or
deploy
or
design
that
particular
architecture
right.
There
are
a
lot
of
challenges.
The
first
one
is:
there
is
a
range
range
of
technology
product.
There
is
a
range
of
architectural
patterns.
Do
I
use
a
event-driven
architecture.
Do
I
use
a
micro
services
based
architecture
within
the
event-driven
architecture?
A
What
should
I
choose
should
I
use
event,
sourcing
event,
notification,
state
carried
even
transfer
right,
so
one
complexities
to
choose
architecture
once
you
choose
the
architecture.
The
next
complexity
is
now
I
know
like
it's
a
micro
services
based
architecture.
Now
what
do
I
choose
for
the
API
layer?
What
I
choose
for
the
database
layer
as
of
today?
There
are
more
than
300
varieties
of
databases,
no
secure
databases
or
our
DBMS
that
are
available
in
the
technology
space
and
every
database
has
its
has
its
utility.
It
depends
on
what
use
case
you
are
trying
to
solve.
A
We
are
actually
implementing
cockroach
DB
I'm,
not
sure
how
many
of
you
heard
about
cockroach
dB
good.
So
we
are.
We
are
implementing
cockroach
DB
to
take
care
of
a
use
case
of
distributed,
sequel
and
distributed
aggregation.
My
applications
will
be
can
be
on
premiere
on
AWS
edge
or
Guiseppe,
but
when
I
query,
the
database
should
be
able
to
do
a
distributed.
Query
aggregate
and
give
me
the
data
quickly
right,
so
every
type
of
database
or
every
type
of
product
has
its
own
utility.
A
It
depends
on
what
use
cases
so
the
complexity
of
this
is
what
should
I
use.
Is
cassandra
good.
Well,
Cassandra
is
ring
structure
highly
available,
but
it
is
also
an
MVC
see
it.
There
is
a
write.
Amplitude
that
might
happen
is
my
application
doing
lot
of
updates.
Then
then,
probably
I
will
choose
something
else
right
and
then
the
people
in
the
inner
who
can
actually
make
those
choices
any
any
good
things
are
limited
in
resource
right.
A
Similarly,
architects
who
can
make
such
decisions
are
not
scare,
very
scanty,
not
not
abundance
in
abandoned
right
and
there
is
a
complex
offender
ecosystem,
and
this
is
a
this
is
a
struggle.
This
is
something
that
our
clients
are
struggling
with.
So
in
any
modernization
program,
you'll
see
there
are
more
than
one
product
vendor
in
the
mix.
You
will
you'll
see
a
database
you'll
see
an
integration
product
you'll
see
an
API
product,
you'll,
see
a
micro
services.
Product
you'll
see
the
micro
services
platform.
Then
there
is
the
cloud
part
of
it
right.
A
So
we
recently
did
a
survey
and
we
said
in
any
modernization
that
there
is
at
least
eight
vendors
involved
and
negotiating
with
all
those
eight
vendors
doing
creating
a
contract
right
for
using
or
subscription
in
all
right.
It's
it's
a
very
cumbersome
process.
It's
a
it's
a
time
taking
process
in
all
right
and
then
the
to
actually
start
the
project
rate.
You
need
to
do
an
environment,
provisioning
software
provisioning,
get
the
environments
in
place
right
that
takes
lot
of
time.
A
That
is
where
we
built
this
suit
of
services,
plus
a
platform
called
Infosys
modernization
platform
right.
The
comprehensive
professional
services
is
like
me
like
in
in
our
practice
we
have
around.
So
it's
a
300
member
architect,
team
out
of
them
architects.
Who
can
actually
do
this
type
of
work
we'll
be
around
150
to
175,
not
even
200
right?
So
we
have
this:
architects
can
go
in
and
then
select
the
architecture
based
on
the
requirement
and
and
do
a
product
assessment.
We
have
some
consulting
kit
to
do
that.
A
To
do
those
product
assessments
and
all
influent
Infosys
modernization
platform
I'll
show
you
a
demo
of
that.
The
single
commercial
interface
with
all
our
strategic
partners,
Kong,
is
one
of
our
strategic
partner.
We
have
a
agreement
that,
along
with
the
services
right,
we
can
take
the
subscriptions
also
along
with
it
so
for
the
client,
it's
a
single
neck
to
choke
right.
Only
Infosys
is
visible
to
the
client,
not
the
other
vendors
single
support,
interface
right,
l1
support,
Alto
support
right
Infosys
is
a
face
for
l3
support.
We
interact
with
with
our
partners.
A
Client
does
not
have
to
interact
with
a
lot
of
these
partners
and,
lastly,
we
have
a
limited
set
of
full-stack,
agile
developers
right.
We
call
them
power,
programmers
right,
we
bring
them
along
for
the
initial
POC
or
a
pilot
right,
so
the
pilot
or
POC
can
be
done
very
quickly
right
now,
let's
take
a
look
at
the
Infosys
modernization
platform.
A
A
So,
while
it's
coming
this,
this
platform
has
three
roles:
the
architect,
role,
the
developer
role
and
a
platform
admin
role
when
the
architect
logs
on
to
this
is
to
the
platform
he
chooses.
The
architecture
chooses
the
products
in
each
layer
and
provisions,
the
environment,
the
application,
the
developer
comes
in
and
then
spins
up
a
local
environment
based
on
that
architecture.
That
has
been
chosen.
A
Thank
you
and
finally,
the
platform
admin
is
who
is
a
person
who
does
the
metering
and
monitoring,
because
this
is
if
this
is
let
us
on
cloud
right
and
I'm,
using
some
many
services
on
the
cloud,
how
much
have
I
used
for
MongoDB?
How
much
do
I
have
I
used
for
Kong
or
how
much
have
I
used
for
OpenShift
right?
That's
metering
and
monitoring
is
done
by
the
platform
admin.
So
let
me
start
the
video.
A
So
that
was
when
it
selected
the
architecture.
Now
it's
a
opinionated
stack
with
choices.
What
we
did
not
want
to
have
all
the
products
available
to
be
put
in
the
platform
right
each
layer,
we
selected
that
leading
two
or
three
products
in
the
market.
In
the
API
layer
we
have
three
scale,
we
have
Kong
and
we
have
WS
or
two.
These
are
the
only
three
choices.
Then
you
can
make
when
when
you
need
to
choose
a
API
product
using
this
platform.
Similarly,
we
have
a
choice
for
the
databases,
so
it's
an
opinionated
stack
with
choices.
A
A
So
I
think
yeah.
This
is
this
is
the
end
of
the
demo
now
I
want
to
I
want
to
leave.
That
was
the
last
thing
that
I
wanted
to
show
you.
In
fact,
there
are
some
migration
toolkits,
for
which
I
don't
have
any
demos
off
now.
So
lot
of
this
database
migrations
application,
server
migrations.
We
have
tools
developed
for
those.
Those
are
also
embedded
in
that
platform.
I
want
to
leave
you
with
a
thought
right.
A
Serverless
computing
is
actually
developing
in
a
pace
faster
that
we
then
we
think
right
there.
It
is
not
mature
yet,
but
it
is
getting
mature
right.
So
what
I
wanted
to
tell
is
like
we
can't
retire
after
we
move
all
everything
in
the
micro
services
architecture.
There
is
something
else
that
is
that
is
coming
up,
which
may
be
better
or
more
efficient
than
what
we
are
building
now
and
that's
that's
all
I
had
to
tell
today.
Thank
you.