Part 2 of the hybrid cloud architecture video series: Modernize
Hey everyone, we’re back with the next installment of the hybrid cloud architecture series—Part 2: Modernize.
Modernization is a complex process that differs from application to application; it’s not one-size-fits-all. That said, there are key strategies to help transform your legacy (usually monolithic) applications to take advantage of hybrid cloud. In this second video in our hybrid cloud architecture series, I’ll cover the following strategies for modernizing legacy or monolithic applications:
Deconstruct: Follow a four-step process for breaking apart your monolith
Lift and Shift: Take advantage of cloud while maintaining speed to market
Innovate and Improve: Identify bottlenecks and utilize cutting-edge cloud technology like serverless and Kubernetes
We’ll continue to use the Stock Trader example, as introduced in the previous videos in the series. This time, we’ll take a step back in time to when Stock Trader was still a monolith. We’ll then walk through specific strategies to transform it into the modern hybrid cloud architecture it uses today.
By the way, did you know that Stock Trader is a real open-source application? Learn more about it on our Developer blog, Introducing Stock Trader!
Say tuned for the final video of the hybrid cloud architecture series, and if you haven’t already, be sure to watch Part 1 on Connectivity:
Part 3: Security—What are the right solutions to ensure that you can take advantage of your existing on-prem assets (and the security and the ease of use that you have there) while securely moving some of your assets to a public or private cloud? (Video coming soon.)
Learn more about hybrid cloud
If you’re interested in learning more about hybrid cloud, its capabilities, and how it fits in with public cloud and private cloud, please check out the resources below.
Hybrid cloud architecture: Strategies to modernize legacy or monolithic applications
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.
The Stock Trader sample application: Monolithic architecture
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-prem, 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 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-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 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.
Deconstructing the monolith and taking advantage of the public cloud
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-prem, 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.
Lift and shift
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.
Always be innovating and improving
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.