A discussion about the need for application modernization, the challenges businesses encounter, and what technologies can help with the process.
Businesses are finding that they must modernize their legacy applications to be able to keep pace with fast-changing market conditions. Increasingly, application modernization means taking an existing legacy application and modernizing its infrastructure to improve the velocity of new feature delivery, improve performance and scalability, and expose the functionality for new use cases.
Such a major change brings many challenges. Recently, RTInsights sat down with Bilgin Ibryam, product manager and a former architect at Red Hat, to discuss the need for application modernizations, the challenges businesses encounter, and what technologies can help with the process. Here is a summary of our conversation.
RTInsights: Why should businesses be considering application modernization now, and what are some of the things they are striving to do with their efforts?
Ibryam: The term application modernization is pretty broad. So, let’s define it first and then talk about why businesses would do that.
Application modernization can be one of many things, including:
- Rehosting, where a business takes an application and puts it on a different machine.
- Re-platforming, where a business changes just the edges of the application
- A change to the underlying platform, where a business moves to a container-based application
- Re-factoring, where a developer goes into the weeds of the application and completely changes the architecture
Refactoring is the one that’s hardest because developers must go into the application itself. But while it’s one of the hardest to perform, it is often going to give a business the most benefits and value. That is why businesses do modernization.
Typically, if a business has a legacy application, a monolithic application, it might struggle with development, latency, and scaling related to increased load. To address these issues requires application modernization.
After modernizing an application, businesses can develop applications faster and have faster release cycles because they can distribute the work to multiple teams. And they can use more modern technology. Those are some of the benefits businesses get with application modernization.
RTInsights: Why is there a need for this now?
Ibryam: One important factor is the need for speedy development. Businesses are deploying many more applications, and those applications frequently need to be updated.
Another reason application modernization is so important is that it lets developers use the latest technology to develop their applications and in their applications. For example, they can create applications that are event-driven and cloud-based, making them easy to scale.
Related: FinServ App Modernization Essential to Counter New Players
Embracing application modernization also addresses another problem businesses face, namely, the challenge of finding skilled workers. Modernizing legacy applications means businesses can find more people that are trained in the newer technologies.
RTInsights: What are the general challenges when businesses try to modernize and are there different types of challenges?
Ibryam: In the ladder of modernization with rehosting, re-platforming, re-architecting, there are different challenges.
Rehosting is pretty mechanical. It is done primarily by the platform teams. They take a VM, move it to a different system or to the cloud.
The responsibilities for re-platforming moves to the developer teams. They need to look within the application. It is a level above simply rehosting an application to the cloud. Developers change elements of the application to take advantage of a cloud platform.
Going further up the ladder, into the re-factoring and re-architecting part, requires a deep understanding of the existing application. Developers focus on the business domains to start splitting the application into modular, separate microservices.
That is the hardest part. Businesses need people who know the business and the application. With that knowledge, developers can re-architect an application in a new way. That part of splitting a monolithic application into smaller microservices is probably the hardest.
RTInsights: What technologies can help?
Ibryam: The most common approach to application modernization, and specifically re-factoring, is based on the strangler pattern. The term was coined by Martin Flower. The concept is based on strangler figs that seed in the upper branches of a tree and gradually work their way down the tree until they root in the soil.
An application modernization based on the strangler pattern starts gradually evolving a legacy application by replacing it, step by step, with a new application. In this way, existing functions are replaced with new applications and services in a phased approach.
First, the business needs to identify what are the boundaries between the different domains so that it can pick one to start with. The choice typically comes down to this: does a business want to start with the hardest part, the one that may be deepest in the application that will give me the most benefits, or does the business start with an easy part?
Once a business makes that decision, they can select what they want to move to a new platform and deal with the challenges specific to that move. For example, a business may start by migrating a database to the cloud. It may not want to instantly retire the legacy application, so it will still want to synchronize data. There will likely be many other modules that need to be migrated. They must start by taking snapshots and then migrate and synchronize the data.
This is where a business can use different techniques. They can use database triggers, an approach that is not very popular right now because the triggers are not portable. They don’t want to write database triggers. There are not many people who can do that. Instead, a business may decide to pull the database. That has limitations and there’s always a challenge. The business must decide whether to pull frequently and create a load on the database or pull less frequently but miss updates.
Related: Open Banking: Has Technology Outpaced Regulations?
Application modernization may also require some changes to an existing database.
The approach that’s getting more and more popular these days is change data capture. Projects such as Debezium help a business read the database transaction log files and create a snapshot. It can move all the data to a new database, and it can keep synchronizing changes.
There are a few specific features in Debezium, which is an example of change data capture project, that makes it particularly attractive for application modernization. For example, one of the main reasons for going with strangler patterns is because, at any point, a business has the option to go back to its legacy application if things don’t go well.
Debezium is similar. It doesn’t require any changes to an existing database. A business does not have to go and add some columns to the tables to get changes. It can take the data, make a snapshot, and synchronize ongoing changes. And not only that, when developers migrate a bit of functionality, they are not interested in the whole database. They may be interested in certain tables and may not be interested in some columns. Debezium can filter those out.
And it can do some light changes. Maybe a developer wants to rename columns when moving data. That person may change it if desired and use the Schema Registry to ensure that the change in the legacy database doesn’t break the new service. That’s why Debezium is particularly attractive in this area.
Another challenge or something that’s not realized early in the application modernization is what happens when businesses create their first microservices or move to containers. They may not realize they are creating the blueprint, the new best practices, and the new architecture for their future microservices. In that regard, Debezium and Kafka fit very nicely.
It’s a very nice way of avoiding distributed transactions, which is something not recommended in a containerized environment. Once a business starts using Debezium and Kafka, it can use change data capture for data migration and stream events from one microservice to another.
What we do at Red Hat is give businesses the infrastructure for application modernization in the form of OpenShift Kubernetes. On top of that, a business can get Kafka (either running on OperShift or as a managed service), Debezium, Schema Registry, and more. In other words, a business can get the whole event-driven infrastructure to build on after migration or application modernization.
