Hi everyone, my name is Sai Vennam, and I'm a developer advocate with IBM.
Today, we're going to start with Part 2 of the hybrid cloud architecture series
- strategies to modernize legacy or monolithic applications.
In Part 1 of this 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-premises, on VMs.
But the architecture is mostly the same
- it's using an SOA (or service-oriented architecture)
that's actually a precursor to microservices-based architectures.
So, very simply, within the monolith itself,
you can imagine this is something like a Java-EE-based application.
We've got the frontend - the UI application - that works with the Portfolio
- which 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 Investor's Exchange public REST API endpoint.
All of that data and the Portfolio information is stored in an on-premises database.
And then we've also got a couple of services here.
So, we've got the loyalty service, which keeps track of
loyalty with specific stocks that you might have in your portfolio,
and then notifies users, as well, on that loyalty whenever it changes
by taking advantage of a message queue service
which notifies the user through something like email.
That's a very simple overview of the architecture,
and this is something that's worked quite well 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 that 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 taking advantage
of the public cloud. So, let's talk about how they can do that.
The first step of the process to deconstructing is going to be to identify the piece that
we want to break out of the monolith. So, a couple ideas we can throw 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 - in fact, it's 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.
Probably the best portion to break out is going to be the UI, or the frontend. That
allows us to put the frontend in multiple geographic locations. Just a quick clarification,
the UI is not only a frontend component, but also the backend for that frontend, which
kind of makes calls to all these other backend services to render data.
So, yeah, I think UI is a great piece to start with - it allows us to start small and set
us up for better deconstruction in the future. 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 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 software-based calls - it's based within the SOA architecture
within the Java platform. We need to take advantage of something like
REST - something that performs well over the public internet. So, the first thing we need
to do is create glue code; essentially, we need to create endpoints said the UI can access
that Portfolio. In addition, we have to expose REST API endpoints on the Portfolio on the
Loyalty side so that the UI can access that 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 the second step - we refactor it. And once we've done that, we can actually
go ahead and deploy that into the public cloud. So, the third step is going to 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 got the same thing over here where
the UI is exposed from the monolith. The legacy API flow - you know, when a user
traditionally hit this application - comes from their browsers and hits that monolith
application. This continues to work great - we've verified it, that the glue code that
we put in place isn't breaking anything. And then, 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, with the remaining percent
goes to the on-prem. This allows you to, kind of, make sure to 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 deprecate 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 have successfully broken out a part of the monolith into the public cloud,
we can start thinking about the next things that we want to break out.
So, so far, we've moved the UI to the public cloud, and let's say that things are going
great. All the international users are getting better response times when they're accessing
the applications. Things are going well, 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
refactorization and converting services into microservices - it's an expensive approach,
and until you feel the need to do so, it might make sense to keep your monolith as it.
But, regardless, let's say that this application is continuing to grow, and we have a new bottleneck
- that's gonna be the Stock Price.
So, with all 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, where we're heading that so many times, we're using the
Investor's Exchange to get those stock prices, and we want to scale that out.
Unfortunately, with our monolithic architecture, if you want to scale Stock Price out, we've
got to scale everything out. And then, on-premises, we don't have enough resources to do that.
So, our users are getting bad experiences again as our user base grow, 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 microservice. 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 with Stock Trader. But, you know, although we have the whole portion
here, the piece that we really want to scale out is the Stock Price. So, although this
is the entire monolith, we want to only use the getting the stock price portion. So, inside
here, we have a smaller portion to "Get" stock prices.
So, now that we've effectively lifted and shifted the entire model it out to the public
cloud, we can start taking advantage of scalability. We can maybe scale it out eight times, as
an example of taking advantage of public cloud resources.
Now, I understand that this is not the best approach, but with the limitations and since
we needed to go to market, by containerizing 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 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.
What we've noticed here is that 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 that we notice is that the UI hits the Portfolio, which then has
to come back out here to hit 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 database storage activities asynchronously? Well, that's
one easy way to innovate and improve on our existing architecture. Let's refactor these
applications so that the UI is talking directly to the monolith in the public cloud to get
those stock prices. That's one example 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 is not the best approach, but it allowed us speed
with go to market. Let's take advantage of some new technology - say serverless, for
example. So, we want to factor out this one portion right here and take advantage of serverless
capabilities to get stock prices. So, by using the serverless platform on a
cloud, we can then take Functions as a Service, which in turn goes and hits the Investor's
Exchange public APIs. So, we'll take advantage of the IEX public APIs using serverless, and
then what we want to do again - so, same four-step process - we've identified the piece (Get),
we've refactored into a serverless action, we've deployed 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 is going to hit that serverless 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 for simply just stock prices.
So, again, we talked about how we take advantage of this four-step process to break out individual
portions of a monolithic architecture and move it into a public cloud. These three things
- deconstruction of monoliths, lifting and shifting, plus always innovating and improving
are going to set you up for success when you're modernizing your monolithic applications.
As always, we checking for feedback, so drop a comment below.
In the next 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 in the links below.
Thank you.