Modernize and migrate to Kubernetes with open source tools

December 8, 2021
James Labocki Marco Berube Miguel Pérez Colino Ashok Pon Kumar Ramon Roman Nissen
Related topics:
ContainersDevOpsGitOpsKubernetes
Related products:
Red Hat OpenShift

An enormous change is taking place throughout the computer industry where monolithic applications are being modernized into lightweight, container-based services on hybrid clouds. Some of the factors driving the change are:

  • The difficulty of maintaining and upgrading monolithic applications, particularly after adopting a DevOps development process.
  • Long times required to roll out bug fixes.
  • Inability to scale up in production.
  • Slow reaction times due to heavyweight Java processes and virtual machines.

The following video presents a few of the problems you might encounter during this transition, based on a fictional company named Globex Corporation. We use this invented case study to show how to modernize and migrate an n-tier monolithic retail application to Kubernetes, and feature free and open source tools offered by the Konveyor community.

Read on for a summary of the issues discussed in the video.

Why did Globex decide to modernize its retail application?

Pain points experienced by the company are typical for the industry:

  • The time from code commit to production deployment took months.
  • A series of code deployments once brought down the system. Failures often took hours to fix, leading to long downtime.
  • The system couldn't handle transaction volume during peak times.

These issues negatively affected the company's DevOps software delivery metrics for the application.

Initial migrations

To solve these problems, the Globex developers started unpacking the monolith. The services they identified within the manufacturing application were the gateway, customers, orders, and inventory. The relationship of these services to the company's computing infrastructure is shown in Figure 1.

A single application, running on virtual machines and communicating through a web server, served four separate functions.
Figure 1. A single application, running on virtual machines and communicating through a web server, served four separate functions.

First, the team broke out the gateway and orders services on Cloud Foundry using Spring Boot (Figure 2).

Two services remained on the virtual machines, whereas two were moved to Cloud Foundry.
Figure 2. Two services remained on the virtual machines, whereas two were moved to Cloud Foundry.

However, they eventually halted the migration to Cloud Foundry when they saw the momentum of innovation taking place in Kubernetes, a competing container orchestration platform. With Kubernetes as the new target platform, they migrated the inventory service into a Kubernetes environment. A benefit of this migration was that they could bring their database onto Kubernetes because the platform can handle persistence.

Furthermore, since Globex learned that Quarkus was more efficient than Spring Boot for cloud application development, they turned to Quarkus to develop the inventory service on Kubernetes (Figure 3).

The final architecture runs a Quarkus application on Kubernetes.
Figure 3. The final architecture runs a Quarkus application on Kubernetes.

Meanwhile, the operations team embraced a GitOps methodology for development and wanted to redeploy services in an automated fashion instead of relying on manual deployments. Unfortunately, the inventory service was still manually deployed, and the operations team would not allow it to be promoted to production until it was automated.

Missing steps to the desired state

The result of all these modernization efforts left the company with several issues needing attention:

  • The customer service still remains on virtual machines, which slows the frequency of new deployments.
  • Services on Cloud Foundry need a path forward to a platform that has a strong future of innovation.
  • The deployment of the inventory service needs to be automated.
  • Maintaining three platforms is inefficient.

Konveyor community tools

The desired state is a set of services running on Kubernetes, with development following a GitOps paradigm to improve software delivery metrics. At this point, Globex leadership brought in the Konveyor community to learn how open source tools can help them reach this state.

The demonstration in the video focuses on:

  • Assessing the parts of the application service using Tackle and, in particular, preparing the customers service for containerization.
  • Refactoring the customers' service to run on Kubernetes.
  • Rehosting the Oracle database to KubeVirt using Forklift.
  • Replatforming the services running on Cloud Foundry to Kubernetes using Move2Kube.
  • Replatforming the inventory service into a new Kubernetes cluster and transforming it to use an automated deployment method using Crane.

Conclusion

A lot of companies today are in the position of the fictional company discussed in our video. Better packages and development processes, together with cloud deployments, can provide the rapid upgrades and scale needed by these companies. The Konveyor community provides tools to ease modernization and migration.

To learn more about modernizing your applications, see the following resources:

Last updated: September 20, 2023