Executive Summary

This customer required a transition for their software product suite from the current exclusive deployment onto the RedHat OpenShift Container Platform, to adding the deployment support onto Kubernetes and its AWS service equivalent named Elastic Kubernetes Service (EKS). The overall objective was for six products of the company’s software suite to be migrated and operated onto AWS EKS. QloudX, an AWS Advanced Consulting Partner, was approached to support this project because of their expertise in Kubernetes and EKS, and their previous experience in such migrations.

The Challenge

The customer had migrated to a containerized microservices architecture many years ago. Since then, they had been running their entire product suite on the Red Hat OpenShift Container Platform (RHOCP), which was the only deployment surface until a recent version upgrade of their product suite. For this project, the they thus wanted to migrate away from the RHOCP and transform their product suite to work on any Kubernetes platform, most notably AWS EKS, using the Helm package manager.

However, Helm is not designed to be used as a target of migration from another deployment-management system like OCP templates. Helm assumes that when Helm charts are installed, they will create afresh all Kubernetes objects included in the chart. In our case, many Kubernetes objects, that are now packaged as Helm charts, were already created in the OCP cluster using OCP templates. Thus, when installing a chart, it simply tries to create all objects & fails because objects by the same name already exist in the cluster. Additionally, there exist other cluster objects like DeploymentConfigs & Routes, which are not supposed to be adopted by Helm charts. Instead, the Helm charts are supposed to replace DeploymentConfigs with Deployments & Routes with Ingresses.

Seeing as we were to migrate the entirety of the customer’s flagship product suite, we had to take into account the 160+ microservices it is composed of, the 200+ containers it runs, the 35+ “framelets” that the microservices are grouped into & the 6 major products they make up. On a technical level, a collection of 140+ OpenShift templates with 70K+ lines of code, served as the input to the migration.

Opportunity

The customer and QloudX outlined several value adding opportunities:

• OpenShift’s additional features built on top of Kubernetes have no significant value for their use cases.
• Having dependencies on those OpenShift features makes the product suite less portable & artificially decreases the potential deployment targets.
• Some customers explicitly require the support of non-OpenShift distros.
• OpenShift license fee in cloud deployments is also much higher than Kubernetes.
• Being able to remove the OpenShift platform dependencies would significantly decrease the SaaS third-party costs.

Our Solution

QloudX proposed, designed, planned & executed a completed migration of all workloads that were based on proprietary OpenShift templates, to generic Helm charts that could be deployed on EKS.

Since this was an OpenShift to EKS migration, replatforming all products/workloads was the only way to go. The bulk of the migration was done using an extensive, Python-based, OpenShift to Helm conversion, automation framework, built by QloudX from scratch specifically for the company. This automation framework accelerated the migration & took into consideration company-specific requirements such as their choice of ingress controllers, their chosen approach for managing stateful workloads & their challenging requirement of migrating live production workloads in customer environments, from OpenShift templates to Helm charts, without downtime.

A Solution that creates Value & Benefits

The migration was completed in just 4 months, as it entered production for one of the company’s telcom customers at that time. The project was a success and the solution came with a number of benefits:

• The product suite was deployed to EKS in early 2022 for 1 product in the & all 6 products have since been fully migrated onto EKS.
• The migration was completed with no downtime or service disruption at all.
• Despite enormous pushback from company architects, QloudX convinced the company to embrace automation, which has led to up to 50% reduction in Helmification times.
• Additionally, teams are now using this automation to Helmify their framelets, without needing any assistance from QloudX.
• In order to mitigate the undesired effects of having a single common Helm library, QloudX designed a comprehensive regression test suite to avoid regressions caused by changes in the library.
• The company has gained a capability center in QloudX, as we have acquired a deep understanding of the company’s (technical) ecosystem, with little assistance from company engineers.

In short, the customer has successfully gained deployment support onto Kubernetes and modernized their software product suite. This has, amongst other inherent benefits of modernization, made the suite more portable and decreased unwanted third-party SaaS costs. Furthermore, they have gained a state-of-the-art Automation Framework, training, and guides to increase internal capability.