Seamless modernization and migration of media services with LG U+

Hello, good morning, everyone. Welcome to re:Invent 2023. I'm super excited and honored that you are here.

First of all, I'm not sure how many of you have wondered why the first session is on application modernization. But when I discovered our session was scheduled as the opening one, I asked myself why? After careful consideration, I conclude that the reason for this choice is because when customers think about AWS and public cloud today, they no longer view it as merely infrastructure for cost savings. Instead, they see it as a crucial accelerator for business growth. That's precisely what we'll be discussing today - application modernization with AWS.

I'd like to introduce you to the speakers who will be guiding today's session on this topic.

Firstly, my name is JB Kim. I'm a Senior Practice Manager at AWS Professional Services Korea, a team that specializes in application modernization and migration.

Next is Sonia Kim, a Research Fellow and team lead of DevOps team at LGU+. Since joining LGU+, her contributions have been instrumental to the success of this journey. She has proven indispensable to LGU+ media service as our DevOps team lead.

Lastly, we have Xizong Lei, Senior Cloud Application Architect at AWS Services Korea. He is the driving force behind our challenging application modernization efforts, always considering potential business outcomes that our customers aim to achieve. He plays a vital role in our customers' successful journeys with AWS Professional Services Korea.

Alright, let's talk about what we'll be discussing today.

Firstly, I will provide an introduction to who LGU+ is and what their media platform entails, their AWS journey of modernization and migration.

Next, Xizong will guide you through understanding LGU+'s problems and challenges, to how AWS Professional Services helped LGU+ accelerate modernization.

Following that, Sonia will take a deep dive into how LGU+ modernized and migrated to AWS seamlessly and achieved business outcomes.

Lastly, we will conclude this session by letting you know our email addresses to communicate with us regarding this topic. Please don't hesitate to ask us any questions and share your thoughts, and we will do our best to provide answers.

Okay then, let's just start with the fundamentals. It's crucial for us to gain a clear understanding of who our customer LGU+ is, and get acquainted with their media platform...

[Transcript continues]

My name is Ha Ha. I am Research Fellow in IPTB De Lead in LG Plus. I'm super excited and honored to be here with you. Yeah, by taking the mic from my previous teammate, Hizo.

I'll introduce how LG Plus modernized and migrated to AWS seamlessly. Two core values we should keep in mind during migration are non-disruptive and long-term.

Our service is media service that demanding very challenging requirements. Nobody imagine TV stops. You know, you never imagine your TV screen stops or hiccups while you're watching TV. This is why our first core value is non-disruptive transition. Incoming traffic never stops 365 days and 24 hours. And the customers easily notice the service accident by TV screen hiccups or delay.

And next, our service has been maintained for a long time and there are many APIs accumulated for the long time with a large number of APIs. We need detailed migration portfolio. This is why our second core value is long-term phase long-term transition.

In the past, I've worked on some challenging non-disruptive migration project. Fortunately, the migration of the past and the current one all have been successfully completed. Based on these experiences, I've narrowed down four key practices to a successful and seamless transformation cloud and des.

You know this one, this first one is probably the most critical one when you want to have business agility and infra flexibility cloud and is a key strategy of most modernization and migration project. Cloud provided us flexibility, scalability and high availability, des accelerate development and deployment cycles. And this results in business agility.

Here are legacy infrastructure and software development problems that LG Plus had before. There is hardware inflexibility and operational difficulty in the LG Plus media platform. We should purchase equip manage the bare metal hardware by ourselves. This made the service development take a long time and limited to hardware computing power.

Cloud solved all of these issues and provided us flexibility and scalability. In addition, infrared code has maximized the productivity of infrastructure management.

Large changes and long release cycle is one of the reasons that affect badly both developers ability and service reliability. Cloud native deployment pipeline, automated and accelerate this process and relieve the developer's burden.

Previously Plus deployed binary files manually. And this was one of the big problems, configuration changes and burden control over binary files are not trivially because an application is not affected, not only the binary affected, not only by the binary itself but also the environmental context.

Developers hands on deployment can lead to human error making deployment process a scary and difficult task for them. We resolve this issue to set up immutable image based deployment.

In this slide, I'd like to share, share you the basic CI/CD pipeline that LG Plus applied to the single source of truth policy. Separate CI and CD. The policy of applying one image for multiple environments reduces the impact of service bugs by deploying verified images to the public.

The large number of deployment pipeline and platform configurations of multiple environments are managed with enhanced get ups for cities such as ro cd above webs. The entire deployment process is fully automated so it results in deployment speed up. It is 10 times faster than before.

Changes can be deployed anytime anywhere regardless of time and location. This allows developers to deploy small changes frequently. And the stability of the deployment system also helped developer no longer fear deployment.

The second practice is probably the most critical one when you think about long term and incremental that is stable data sync pipeline. Our migration is incremental so we need both legacy database and new and new database system to be consistent for a long time.

Here are three challenges that in our database sync pipeline had before. Firstly, database types are heterogeneous. The existing database is Oracle in LG Plus data center and in transition database is Postgres in AWS cloud.

And the second challenge is the amount of data update in our service. More than 500 tables are sinking and 136 million data updates happen in a day. If you transfer me to updates per second, it is 1500 UPS. The amount is huge.

The data sync, the data sync latency between two databases is critical because three KP codes such as updates to one database and reach from the other database frequently happen during migration.

Hence for incremental migration, it is critical to build stable and fast data sync pipeline to avoid those difficulties. Many of many of other projects choose big bang migration strategy. It is kind of you are moving your application and the whole data to the cloud just one overnight. This is tempting because it is simpler and cheaper than incremental approach, but it is risky and irreversible when something goes wrong, finding issues were rolling back from big bank changes is extremely difficult or sometimes almost impossible.

All of our concern is our customer experiences. We want seamless and non-disrupt changes so that our migration does not harm our customer experiences. So we select incremental approach to overcome those challenges.

We select high performance distributed messaging system that is Apache Kafka. By using AWS MSK managed the streaming pool, Apache Kafka we can offload the Kafka management overhead. And there are many well-developed Kafka open source to open connectors to MSK and Kafka connectors enabled us to overcome the challenge of data sync pipeline except one thing that is initial data load speed.

The the amount of initial data is one terabyte and the initial load took almost three days. You can easily understand we couldn't use this setting because our data in pipeline hardly catch a three days gap and this get would would get larger as time passes. It is a moment when you think about the fastest and easiest way to migrate huge amount of data that is AWS Data Migration Service.

With the help of AWS DMS, we could easily load the large amount of initial data to Postgres in some hours. Now, I will recap our data testing pipeline. For main database. We select AWS Postgres for high performance Postgres or high performance database engine that provides us high availability and scalability.

AWS MSK for data in pipeline is processing huge amount of data transfers consistently. One of the most challenging problems in our data pipeline is transfer delay with months of analysis and many many retrials we could finally minimize the transfer delay into nearly real time.

This stable and fast data sync pipeline enabled a series of API transitions to complete on schedule.

The third practice is strangler fig migration pattern. When you want to migrate your APIs to the cloud incrementally without your customer noticing it. What you firstly need is strangler freak migration pattern.

Let's look at an example of applying the strangler fin migration pattern. Before migration. The customer requests from IPTB setup are directly received and processed by the on premise data center in the in transition system.

Sprint cloud gateway intercepts the customer request from IPTB setup and sends them to the on premise or to the cloud in the transition system. You can see that where the look up and content curation have completed their migration to the cloud. So sprint cloud, the gateway intercepts customer record of where to look up and contents creation and sends them to the new system while routing the rest of APIs to on premise.

It is important to note that the existing services in on premise are still available to receive customer request at any time. So if any issues arise during migration, we can change the routing to the on premise without impacting the customer experiences using this stable data testing pipeline and strangle free migration pattern.

We were able to successfully make a sequential API transitions over the course of a year. First, we categorize the services into several groups based on dependencies and cohesion. We analyzed and separated the monolithic code into microservices. The modules that are lightened to be microservices were moved to the cloud one by one.

And the transition jobs performed are more than 20 times before the transition. There were 980 monolithic legacy APIs in the on premise data center. But after the transition, 765 APIs were modernized and located in AWS cloud. The remaining 215 APIs were retired to achieve platform simplicity.

Now I will show you the final practice application, modernization and microservice architecture. The legacy applications in LGO Plus media platform were the accumulation of many technical depths that includes outsourced development, a focus on schedule and delivery rather than quality ad hoc development rather than good planning and design and a long time operating environment.

Without modernization. For example, the legacy applications were the tangled code of complex data and motor dependencies. Services were maintained for 15 years in on premise data center without modernization like other long maintained and outsourced applications, we had few documents and no original developers remained and the history is delivered by word of mouth.

Business logic were implemented in oracle db queries c and all java spring were not designed for business logic but just used for wrappers of oracle queries. The painstaking and difficult process of analyzing all the application code is one of the areas where we have benefited most aws preserve together.

We analyzed the legacy code identified the architectural characteristics of services and redesigned them into microservices. In practice. Modernization process was not as noble as it sounds in the books. Months of code analysis, design disagreement between developers and redesign that didn't work in production were commonplace.

Our desire to eliminate all the technical depths by refactoring all applications was not easy to achieve. We accepted the reality of the situation and we changed our strategy to cloud first with rela this is because we think that once the services in the cloud refining the application can be done quickly and easily on top of our cloud and des foundation.

As a result, we were able to complete 45% of APIs to refactoring and 33% to relat. If we classify refactoring and replaying as modernization, we can consider 78% of APIs as modernized according to aws last year's reinventor applic application application modernization is performed about 20% in typical migration pattern.

The big 50% of migration spectrum is lift and shipped with many companies opting for a simplified migration. This pattern involves lifting the latest apps and replacing the hardware with is two machine. Another 20% to rep adapts so is a service to replace them and the remaining 10% retire, which means shutting down the service.

In our case, the transformation of LG Plus media platform is a remarkable achievement compared to typical migration pattern. We we succeeded in modernizing 78% of APIs through a combination of refactoring and relat. We retired 22% of APIs. Our pattern doesn't include uh uh lift and shift approach were introduction of set.

That means we completed full change of all applications by application modernization.

Now I will show you what we gained from this migration. A long and passionate journey to AWS cloud finally ended in April this year. In the past two years, LG Plus media platform has been equipped with cloud devops and MSA. But more importantly, we built a culture of people and rapid development as a transformed organization with culture of communication, share and sharing the ownership and the teamwork has improved the software delivery performance by leaps and bounds.

We went from twice a month deployment twice a month deployment to on-demand deployment. Since April deployment frequency has improved a lot with actual measurement of deployment showing five times a day deployment. When change request comes in such as voice of customers, we are able to deploy changes within a day or two instead of the weeks it used to take.

When an issue is found a rollback or each improvement which used used to take four hours. Now takes less than an hour.

In conclusion, LGU Plus has grown from a low performer to a high performer to a fast and efficient organization just by moving to the cloud as bus business outcome, customer experiences gets gets much better than before as explained by his own.

Previously in November 2020 there were big setup updates that had hours of huge performance degradation due to increased database load. In order to recover from the degradation, we had to harm our customer experiences by limiting what's your history footprint by 25%.

After transformation, cloud service provides four times a longer watch history footprints as well as five times faster API latency feedback and changes for voice of customer is much faster than before.

Previously, customer issues took a long time to complete. Infra engineer should get lo deliver the log to to the developer and developer should dig into his program and data and make changes and wait for another two weeks for deployment.

Currently, we are using modernized observable systems such as Splunk and developers now can directly access their log and easily run issue locating queries on the real time log, you know, building a fix and deploying. It is accelerated by our, by our cloud native CI pipeline.

Now we are provide quick and accurate fixes or feedbacks to our customer within one or two days, fast and easy scalability of AWS helped us when a sudden delay of beauty. What happen after migration?

We found out that there was a tricky API containing heavy queries. These queries raises DBCPUs up to 80 or 90%. Not 89, 8090 very huge, especially special time. The time was between 6 to 10 p.m. exactly when families come back home and watch TV. Together, if our database is on premise, it would be almost impossible.

It would be impossible to add one more DB so quickly because buying hardware and relative license, equipping in and finding and reserving special engineer for the setup. All of this will take a few days or a few months.

In the cloud. We can easily solve this issue just by literally clicking the button at the reader. Just a few minutes is enough for our customer to recover from. We watch delay and this also saved my life too.

The transformation of LG Plus media platform is not over and we are still moving forward. We completed the transformation project in April. But our products still need to change to meet customer requests and create new business opportunities, the service architecture and infra media infrastructure needs to be innovated and reviewed.

Our successful migration will be a key foundation to to drive our service platform into a fast exile and efficient one to create new business opportunities in the future.

Thank you for joining this session of LG Plus cloud journey. That's all. Thank you.