Shift to the Future: OpenShift 4.4 and Legacy Apps

by | June 08, 2020

For some time VirtaMove has been urging enterprises to address their legacy application deficit and shift their Windows and Linux app stacks to new, faster, more secure servers. Now, with the surging interest in containers and container technology, the industry appears to be on the same page. We’re excited by the possibilities for new apps and new uses of legacy applications that these developments promise. In this blog we’ll look at OpenShift 4.4 and how this new product might apply to legacy apps.

Red Hat OpenShift 4.4 Opens a World of Possibility

In Spring 2020, Red Hat released OpenShift 4.4., an evolution of the Kubernetes Enterprise 1.17 platform. OpenShift Container Platform is a cloud development Platform as a Service (PaaS) built around Docker containers. The platform is orchestrated and managed by Kubernetes on a foundation of Red Hat Enterprise Linux. It offers a cloud foundation for building, deploying, and scaling new containerized applications. It’s particularly attractive for IT shops interested in developing cloud-enabled micro services. 

Red Hat believes that companies need faster and more widespread access to essential apps and services. IT departments are pressured to become ever more agile to deliver innovative solutions. According to Red Hat, this landscape translates to “container and Kubernetes-powered open hybrid cloud”. A preferred path in the enterprise cloud adoption journey is “application platforms supporting an architecture that gives developers a wide choice of components across hybrid cloud infrastructure.”

At VirtaMove, we’re also intrigued by new applications such as OpenShift, believing that we can use them to containerize legacy applications and retro fit them for load balancing and service architectures.

Containerization boasts many benefits, chiefly among these accelerating the development and deployment of apps on cloud infrastructure. Both Kubernetes and OpenShift promise easy container management. 

What’s the Difference?

While there are many similarities between Kubernetes and OpenShift, there are some important differences. The most notable difference is that Kubernetes is an open-source project, while OpenShift is a commercial product (you pay). 

Kubernetes is an open source system or framework for automating deployment, scaling, and management of containerized applications. Open source means self support, but it also means a significant ecosystem of users. 

As a product, users must subscribe to OpenShift in order to install it and access support. Users need to renew the subscriptions for their cluster, and the amount increases when the cluster expands. An OpenShift subscription includes CloudForms, which offers features such as configurable chargeback, monitoring, and central provisioning etc. Basically, a way to recover costs.

Kubernetes is an integral part of OpenShift, but with a rich set of features built around it. OpenShift complements Kubernetes, making it a comprehensive, enterprise-ready platform that offers a better developer experience and is easier to use in production. You could think of OpenShift as a “smarter” flavor of Kubernetes.

OpenShift 4.4 – Lots to Be Excited About

OpenShift 4.4 offers improvements to Kubernetes, for both administrators (the traditional user base) and now developers. For example:

  • Developers can use a graphical console to interact with Kubernetes and deploy apps. 
  • More automated operations, which makes it easier to install, administrate, and upgrade a container platform.
  • OpenShift ServiceMesh (Istio, Kiali, Jaeger) helps you with microservices development.
  • Out of the box, developer-centric dashboards for network metrics and monitoring.

Version 4.4 includes the HAProxy 2.0 load balancer for better performance, improved storage management with volume re-size, snapshot and clone, and includes OpenShift Serverless for function-based, event-driven applications.

In Technology Preview now is OpenShift virtualization, based on KubeVirt. KubeVirt enables organizations to develop, deploy, and manage virtual machines (VM) applications alongside containers and serverless. Container native virtualization may be attractive for teams that are shifting to cloud-native application development and have a large investment in conventional VM technology.

Also in Technology Preview is Red Hat’s new management solution, Red Hat Advanced Cluster Management for Kubernetes. This provides a single control point to manage Kubernetes clusters, whether they’re on premise or dispersed across data centers and multiple clouds.

OpenShift Technology Preview features will be available across hybrid and multi-cloud footprints, including major public cloud providers in Amazon Web Services, Google Cloud Platform, IBM Cloud, Microsoft Azure, and many specialized cloud providers. Red Hat is promising support for multiple computing architectures, including x86, IBM Power, and mainframes.

What about Containerizing Monolithic Legacy Apps?

Historically, there’s been a gap between legacy applications and containers. In a previous blog, we discussed that a new cloud app might be built as a microservice. In a Linux platform this is a perfect scenario for using OpenShift. Containers may make sense for new greenfield app development or on mature Linux platforms. In this scenario you could leverage APIs, containerization, application virtualization, or a microservices architecture as a basis for new stateless, serverless applications. However, using containers by default for legacy applications may not pay off given the performance and management overheads we’ve discussed in several previous blogs.

In the case of a monolithic legacy Windows Server app, the current production state of the app needs to be installed into a WS2016/WS2019 Windows container (VirtaMove can do that). For example, WS2003 and WS2008 apps still need to be reconfigured to run on the WS2016 or WS2019 Core OS. You’ll likely need to address deprecated app features and OS reconfiguration. You’ll also likely need to harden the stack with antivirus or container security software, then implement authentication and user access control, given security issues discovered around both Kubernetes and Docker.

Here’s an Alternative

You could consider an alternative: an automated, stateful re-install of legacy apps on a modern server and Host OS.

At VirtaMove, we use our own lightweight container for isolation and testing on a host server. However, there is no permanent reliance on our container: it can be removed at the end of the moving process. The legacy application can run natively on a modern Host Windows OS or in a Windows or Linux Container Core OS. 

Benefits of an automated, stateful re-install include:

  • Closing known security exposures on old Windows or Linux OS.
  • Apps will run natively on a supported OS.
  • New hardware improves performance. New servers are scalable and run faster. You’ll get more work done with your existing apps.
  • Stateful re-installs allow apps to be split and installed on separate servers. Or, apps can be consolidated and installed on a single server. They can also be load balanced.
  • The life cycle of legacy apps can be extended. New features such as a micro-service architecture can be added gradually. You’re not forced into costly app re-development simply because you want to run apps on modern host servers.

If you need to shift forward with your legacy Microsoft Windows Server and Linux applications or would like to understand more about what VirtaMove does, don’t hesitate to give us a call. We’re pleased to share what we know. 

Red Hat, Red Hat Enterprise Linux, the Red Hat logo are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. IBM®, the IBM logo, and ibm.com® are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Azure is a registered trademark of Microsoft Corporation in the United States and/or other countries. Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Amazon Web Services, the “Powered by AWS” logo, [and name any other AWS Marks used in such materials] are trademarks of Amazon.com, Inc. or its affiliates in the United States and/or other countries.”