Workload cloud migrations from one platform to another require careful consideration for multiple aspects of the current and target platforms. These considerations during cloud migration include differences in configurations, services, capabilities, technologies, and support. Transformation leaders have to balance and juggle numerous such factors along with establishing a meaningful business case before moving from on-premise to cloud. In this blog post, we will touch upon some of the issues they face when they consider migration from on-premises OpenShift to the cloud.

But before delving into the aspects, business leaders will need to answer the primary question – what are the reasons for migrating from on-premises to the public cloud? These could be multiple factors, such as data center exits, cloud services utilization, and performance. No matter what the reason is, moving your container platform from on-premises cloud to the public cloud will entail understanding the complexities involved in the same and ways to resolve them.

Here are 15 considerations for successfully migrating On-Premises OpenShift to the Cloud

Let’s deep dive into the checklist on crucial factors before making this ultimate shift:

1. Dependencies on hardware infrastructure

   The first factor to consider before cloud migration is to understand whether there are any dependencies on the underlying hardware platform or not. This is where the Red Hat OpenShift worker nodes are installed. The dependencies could range from high-performance storage devices, GPUs, SR-IOV, and TPUs to even a bare metal deployment of the OpenShift platform. Owing to this, some of the hardware capabilities and features might not be available on the public cloud and result in a non-starter. Hence, it is often advisable to check certain application dependencies before considering cloud migration.

2. Support for commercial off-the-shelf (COTS) applications operating on the container platform

   Red Hat OpenShift Container Platform (OCP) is the market leader in the enterprise container platform space. It commands a market share of over 44%  with more than 3000 active customers worldwide who run their applications on the production platform. This is the reason why a large number of OEMs of COTS products have certified their applications on OpenShift. But, it is not necessary for these OEMs to certify and support their containerized applications on a public cloud Kubernetes offering. Thus, if you have a considerable number of such OEM solutions, it is worth checking on the supportability before making the move.

3. Support for runtimes, middleware, and integration technologies

   Likewise, there are a large number of runtimes, middleware, and integration stacks that the applications rely on. The vendors of these runtimes, middleware, and integration stacks define the Kubernetes platform on which they support their offerings. If the organization chooses a Kubernetes public cloud offering that is not included in the supported platform for these offerings, they might face issues in getting support for them on the public cloud Kubernetes platform.

4. Ecosystem tools integrated with the Kubernetes platform

   Apart from the considerations discussed in the above two sections, ecosystem tools constitute another crucial building block of the PaaS solution. Considering the popularity of the OCP platform, a large number of ecosystem tools for monitoring, logging, security, backup, alerting, and the like are available with the OCP platform. The same rich ecosystem of tools might not be available with the public cloud offerings. Thus, it would be a good idea to check with your ecosystem tools vendor to confirm the supportability of the public cloud Kubernetes offering. Furthermore, all public cloud hyperscalers offer and promote their own set of tools to help them bind their customers to their cloud offering/services.

5. Support for base images used for container images – certified container images

   Red Hat OpenShift includes the Universal Base Image (UBI), which customers can use with their OCP platform. UBI is used to build base images that are certified, tested, supported, and secure. Once you move to an alternative container platform, such as the public cloud Kubernetes offering, the new platform might not support the underlying base images. This may require rebuilding all the container images on the public cloud platform, which in turn would question the universality of the certified and secure base images. So, it is imperative to consider the cost of rebuilding all container images and choosing a new base image.

6. Support for OEM offerings such as CloudPaks

   A large number of OEM offerings/bundles such as IBM’s CloudPaks are bundled with the Red Hat OpenShift container platform. If you are using such offerings, it would make sense to stick with Red Hat OCP as the underlying platform. These bundles are not available with the public cloud Kubernetes platform (at least, currently). You would need to run a combination of Kubernetes platforms, which would add to the complexities and overhead of managing multiple solutions.

7. Considerations for PVs for stateful workloads

   Migrating stateless applications is comparatively easier. With stateful applications, there is an additional overhead to manage the persistent volume and their claims. Your application may currently be using some stateful workloads, which would need to be migrated to the public cloud Kubernetes service. There are complexities involved in migrating these storage volumes and ensuring compatibility. This includes the storage volumes available on-premises and those available and compatible with the public cloud Kubernetes solutions. Besides, you may need to use a third-party migration solution to migrate this data to the public cloud for ensuring consistency.

8. Kubernetes version mismatches and feature unavailability

   With Kubernetes developers constantly upgrading the software, it is not possible to have control over the version at the time of migration to the public cloud. Whereas your application may still not be compatible with the latest version of the Kubernetes platform and you might be running an older version of OCP on-premises.

   As technology is changing at a fast pace, new features continue to be introduced and older features become obsolete. Some of the features that you might be using on-premises might be unavailable in the version on the public cloud. Therefore, compatibility of different versions and features is important to ensure your applications are not impacted when they are moved to the public cloud Kubernetes environment.

9. Interfaces (internal or external to the cluster) and associated dependencies

   There are legacy applications, large databases, authentication, and various other applications on-premises that get integrated with the containerized applications. But, not all the integrations that your application talks to are containerized. While this might not be evident now, the moment you start moving out from the current environment, these integrations could start failing and result in performance issues. You will need to consider these external integrations and dependencies in your on-premise to cloud migration strategy.

10. Hybrid cloud and multi-cloud configuration support

    Enterprise container platforms such as OpenShift support multiple deployment configurations, including those in on-prem, hybrid cloud, public cloud, bare metal, multi-cloud, and the like. But, most of the public cloud offerings provide only public cloud PaaS services. This limits the ability to expand and move from one platform to another.

11. Technological differences

    While Kubernetes is at the core of OpenShift, it is just one of the several components that make up the OpenShift product. Having just Kubernetes to run your mission-critical, production-grade workload is not sufficient. You would additionally require several other components, such as authentication, networking, security, monitoring, logs management, and the like. Red Hat brings all these capabilities into one product and maintains their cohesion by ensuring updates, upgrades, and bug fixes for the product as a whole and not Kubernetes alone. Moreover, some of the capabilities are handled a bit differently in OpenShift as compared to upstream Kubernetes. These are some of the value additions that Red Hat has brought in upstream, which include RHEL, UBI, SCC, and other enhancements. One needs to take cognizance of these aspects when moving from on-prem deployment of OpenShift to the public cloud.

12. Migration methodology recommended by hyperscalers

    The approach that the public cloud Kubernetes services providers recommend includes rebuilding the container and then performing rigorous testing on these applications on the public cloud test instance. This approach not only delays the migration but also involves overhead in terms of the testing effort, and applying fixes in case of test failures. Of course, if the target platform is OpenShift, it rebuilds and does not require rigorous testing, making the migration easier and fast.

13. Vendor lock-in

    While moving the workload to the Kubernetes service instances of a public cloud hyperscaler vendor, a common ask is to integrate with public cloud PaaS services and implicitly bind to those. Afterward, if the business plans to move to another public cloud vendor – it is vendor locked. Then the organization will need to re-do the entire process of public cloud PaaS integrations. It is thus a good idea to continue to use vendor-agnostic tools for ecosystem integration during migration to the public cloud. It does not matter if the migration involves OpenShift or not.

14. Developer interface or perspective

    Red Hat OpenShift Container Platform provides very intuitive developer and administrator interfaces. This interface provides GUI-based information about the running applications and their integrations. This aspect is very helpful for developers to manage their applications and is certainly not available in public cloud offerings.

15. Integrated and secure by default PaaS capabilities with easier permission management in OpenShift

    As stated earlier, Red Hat OpenShift bundles additional capabilities and also provides support to these integrations. Moreover, at the time of upgrading the cohesion of integration is maintained and you are not required to separately manage the tools and integrations. Some of these capabilities that OCP brings are:

    1. Internal container registry
    2. Logging stack based on EFK
    3. Prometheus-based monitoring
    4. Jenkins

    But, in the public cloud K8s services, not all of these may be bundled as a product and you would need to incorporate and manage them separately. This inherently becomes a burden in larger deployments.

How can Public Cloud IaaS deployment of OpenShift help eliminate these concerns?

As we are aware, Red Hat OpenShift is fully compatible and supported on not only the on-prem environment but also across all major public cloud IaaS services. One would not be required to worry about the supportability of middleware, runtimes, integrations, COTS applications, UBI, and the like when they migrate from on-prem deployment to public cloud deployment. Moreover, one can continue to enjoy technically advanced comparative capabilities such as OpenShift projects, deployment configs, image streams, and the like. One of the most important capabilities that OpenShift brings in is the secure-by-default capability. You can continue to leverage the same by not allowing containers to run with root privileges, SELinux, SCC, RHEL maturity, and the like.

We recommend either a Managed OpenShift Container Platform deployment or a Red Hat OpenShift IaaS-based public cloud deployment (initially in hybrid and eventually completely on the public cloud). This would be the fastest, simplest, and cheapest solution for the transformation/migration of your containerized workloads to the public cloud with trust and without having to worry about the application’s compatibility. We, in HCLTech, can help you with a detailed analysis of your current environment and suggest the best way forward considering your current landscape.