Hybrid Cloud Modernization: UI Migration
Key Points
- Sai Venom, an IBM Developer Advocate, introduces Part 2 of the hybrid‑cloud architecture series, which focuses on modernizing legacy monolithic applications.
- The sample “stock‑trader” app is described as a Java‑EE monolith using a service‑oriented design with a UI front‑end, portfolio service, loyalty service, message queue, and an on‑premises database that pulls stock data from an external REST API.
- As the fictional company expands globally, users experience increased latency, prompting architects to consider breaking the monolith and leveraging public‑cloud resources.
- The first step in deconstruction is to identify the component to extract; the UI (including its backend logic) is chosen because it can be replicated in multiple geographic locations without tightly coupling to other services.
- Moving the UI to the cloud allows a small, low‑risk start to the migration and sets the foundation for further incremental refactoring of the monolith.
Full Transcript
# Hybrid Cloud Modernization: UI Migration **Source:** [https://www.youtube.com/watch?v=iZR0TJPmj_U](https://www.youtube.com/watch?v=iZR0TJPmj_U) **Duration:** 00:11:22 ## Summary - Sai Venom, an IBM Developer Advocate, introduces Part 2 of the hybrid‑cloud architecture series, which focuses on modernizing legacy monolithic applications. - The sample “stock‑trader” app is described as a Java‑EE monolith using a service‑oriented design with a UI front‑end, portfolio service, loyalty service, message queue, and an on‑premises database that pulls stock data from an external REST API. - As the fictional company expands globally, users experience increased latency, prompting architects to consider breaking the monolith and leveraging public‑cloud resources. - The first step in deconstruction is to identify the component to extract; the UI (including its backend logic) is chosen because it can be replicated in multiple geographic locations without tightly coupling to other services. - Moving the UI to the cloud allows a small, low‑risk start to the migration and sets the foundation for further incremental refactoring of the monolith. ## Sections - [00:00:00](https://www.youtube.com/watch?v=iZR0TJPmj_U&t=0s) **Legacy Monolith Overview for Modernization** - Sai Venom outlines the on‑prem, Java‑EE based Stock Trader monolith architecture—including UI, external API calls, on‑prem database, loyalty service, and message queue—as the foundation for hybrid‑cloud modernization strategies. ## Full Transcript
hi everyone my name is sai venom and I'm
a developer advocate with IBM today
we're gonna start with part two of the
hybrid cloud architecture series
strategies to modernize legacy or
monolithic applications in part one of
the series we talked about hybrid cloud
connectivity and we used a similar
sample application stock trader this
time around we're taking a step back in
time to when stock trader was still a
monolithic application running on Prem
on VMs but the architecture is mostly
the same it's using an SOA or
service-oriented architecture it's
actually a precursor to micro services
based architectures so very simply
within the monolith itself you can
imagine this is something like Java EE
based application we've got the
front-end the UI application that works
with the portfolio basically manages
your different portfolios and keeps
track of the stock prices so to get
those stock prices it actually hits
another service which goes out to the
investors exchange public rest API
endpoint all of that data and the
portfolio information is stored in an
on-prem database and then we've also got
a couple of services here so we've got
the loyalty service which keeps track of
you know loyalty with specific stocks
that you might have in your portfolio
and it notifies users as well on that
loyalty whenever it changes like taken
advantage of a message queue service
which notifies the user through
something like email so that's a very
simple overview of the architecture and
this is something that's worked quite
well for for that fictional company
stock trader it's worked well for them
and they've seen growth and expanded and
potentially you know maybe they become
an international company so what they've
noticed is certain users that are using
this application are seeing increased
latency so the architects on the stock
trader side decided you know it's time
to get rid of the monolith it's time to
start deconstructing it and stick taking
advantage of the public cloud so let's
talk about how they can do that the
first step of the process to
deconstructing it's going to be to
identify the piece that we want to break
out of the monolith so a couple ideas we
can
out here for example we don't want to
move the portfolio service to the public
cloud because you know it's tied so
deeply to the other services fact is
actually also talking to the loyalty
service so you know if we move that
portion there'd be a lot of unnecessary
Network hops probably making the issue
even worse for our users put the best
portion to break out it's gonna be the
UI or the front end that allows us to
put the front end in multiple geographic
locations just just a quick
clarification that UI is not only a
front-end component but the backend for
that front end which kind of makes calls
to all of these other back-end services
to render data so yeah so I think UI is
a great piece to start with it's it
allows us to start small and sets us up
for better kind of deconstruction in the
future but okay so the first thing we've
done we've identified the resource the
second thing we want to do is refactor
so we can't simply just move that
portion out of the monolith into the
cloud and and and there's a lot of
reasons for that but the main one being
that communication between these
services doesn't do well on public
Internet it's it's software-based calls
it's based within the SOA architecture
within the Java platform we need to take
advantage of something like rest as
something that performs well over the
public Internet so first thing we need
to do is create glue code essentially we
need to create endpoints that the UI can
access that portfolio and in addition we
have to expose REST API endpoints on the
portfolio on the loyalty side so the UI
can access it itself this is essentially
what we call glue code because it allows
us to kind of keep that same pathway of
communication between services but we
enable it to work over the public
Internet so that's that second step we
refactor it and that once we've done
that we can actually go ahead and deploy
that into the public cloud so third step
gonna be deploy so we take that UI and
we put it in the public cloud and
basically what we need to do is expose a
point for access of it and you know
we've got the same thing over here where
the UI is exposed from the monolith
the legacy API flow you know when a user
traditionally hits this application
comes from their browsers hits that
model at the application this continues
to work great you know we've we've
verified it that the glue code that we
put in place isn't breaking anything and
then here's the here's the important
step we want to make sure that that new
API flow the one that's directly
accessing the UI in the public cloud
continues to work now a good strategy
here is to initially maybe do 10% of
your user traffic goes to the public
cloud UI whereas the remaining percent
goes to the on Prem allows you to kind
of make sure catch issues in production
make sure a lot of your users aren't
affected eventually you catch all the
errors you make sure the public cloud is
error-free that's when you deprecated
the older UI portion you know just get
rid of the whole thing and take
advantage of the UI on the public cloud
side so the last step is repeat once
you've successfully broken out a part of
the monolith and into the public cloud
we can start thinking about next things
that we want to break out so so far
we've removed the UI to the public cloud
and let's say that things are going
great you know all the international
users are getting better response times
when they're accessing the applications
things are going well and and we may not
have a need to further our
deconstruction of the monolith I think
this is something very important to
think about doing this refactor is a
ssin and and and converting services
into micro services it's a expensive
approach and until you feel the need to
do so it might make sense to keep your
monolith as is but regardless let's say
that this application is continuing to
grow and we have a new bottleneck and
that's going to be the stock price so
with all of these portfolios and all of
these different users using it you know
we don't need to scale out these other
portions as much but maybe the stock
price you know we're hitting that so
many times we're using the investors
exchange to get those stock prices and
we want to scale that out unfortunately
with our monolithic architecture if we
want to scale stock price up we have to
scale everything out and then on Prem we
don't have enough resources to do
so our users are getting bad experiences
again as our user base grows and we want
to move that stock price to take
advantage of the public cloud
scalability but let's say that we don't
have time right so users are already
having a bad experience we don't have
time to refactor that stock price out
and create a micro service that's where
we can take advantage of lift and shift
essentially take this entire monolith
and move it over to the public cloud so
you can imagine you know let's take that
entire monolith a stock trader
but you know although we have the whole
portion here the piece that we really
want to scale out is a stock price so
although this is the entire monolith we
want to only use the getting the stock
price portion so inside here you know we
have a smaller portion to get stock
prices so now that we've effectively
kind of lifted and shifted the entire
monolith out to the public cloud we can
start taking advantage of scalability we
can maybe scale it out eight times as an
example taken advantage of public cloud
resources now I understand that this is
not the best approach but with the
limitations since we needed to go to
market by container izing the monolith
and moving it to the public cloud we can
really start taking advantage of the
resources there and then start thinking
about the next step of our kind of
modernization process one thing I want
to mention here
so my next line here innovate and
improve you always want to find ways to
improve your application well we've
noticed here is that you know the UI is
in the public cloud but kind of the
communication channel for it essentially
the UI is always kind of going back to
the monolith to take advantage of the
portfolio loyalty and whatever other
services might be there right so the
first thing we notice is that the UI
hits the portfolio which then has to
come back out here to hit the the
monolith in the public cloud to get the
stock prices that in turn goes back to
the portfolio and then back out to the
UI that's a lot of unnecessary Network
hops we can always innovate and improve
throughout this process of modernization
why don't we get the stock prices
directly in the UI and then offload all
of the kind of database storage kind of
activities asynchronously
well that's one easy way to innovate and
improve on our existing architecture
let's refactor these applications of the
UI is talking directly to the monolith
in the public cloud to get those stock
prices so that's one example of kind of
always innovating and always improving
when doing this kind of migration
another thing so we talked about how
using the whole monolith in the public
cloud it's not the best approach but a
lot of speed with go to market let's
take advantage of some new technology
say server lists for example so we want
to factor out this one portion right
here and take advantage as serverless
capabilities to get stock prices so by
using the server list platform on a
cloud we can then take functions as a
service which in turn goes and hits the
investors exchange public api's so we'll
take advantage of the IE acts public api
s-- using server lists and then what we
want to do again so same four-step
process we've identified the piece get
we've refactored it into a service
action we've deployed it into production
and then what we want to do is test it
there right so legacy and new API flows
so again this is the legacy flow and
then the new API flow it's gonna hit
that circle as action directly once we
verified that this flow works well we
can entirely cut out that monolithic
architecture that we pulled into the
public cloud first simply just stock
prices so again we've kind of talked
about how we take advantage of these
four step process to break out
individual portions out of a monolithic
architecture and move it into a public
cloud these three things deconstruction
of monoliths lifting and shifting so
it's always innovating and improving
we're gonna set you up for success when
you're monitoring modernizing your
monolithic applications as always we
check for feedback so drop a comment
below in the neck
part of the hybrid cloud architecture
series we'll be talking about security
so definitely subscribe and stay tuned
if you want more information about what
we talked about today check the related
information for links below thank you