More and more frequently, modern applications are choosing a container-first development and deployment paradigm built on the foundation of Kubernetes. However, not all applications are fully modernized and containerized micro services. Many applications are a hybrid of architectures and technology which have existed for years, even decades. This can add complexity, both to the application architecture and management overhead, when a container-based, cloud-native application component needs to access existing functionality which is virtual machine based.
Container-native virtualization provides flexibility during the modernization process so that you can focus on the most critical aspects first, while still being able to access, manage, and consume VM-based aspects using the new Kubernetes-centric tools. Based on the KubeVirt project, recently accepted by the CNCF, Container-native virtualization manages both virtual machines and containers through a single control plane saving time, resources, and budget. Red Hat Container-native virtualization delivers KubeVirt functionality directly to OpenShift customers and helps to manage both virtual machines and OpenShift deployments from a single platform. This single platform simplifies the management of virtual machines and containers with a common Kubernetes interface that standardizes orchestration, networking, and storage management while also supporting the long term move to containers.
What does this mean for the developer? Regardless of where your company is in their digital transformation, you have a platform to develop on. Many legacy applications find it too complex or expensive to move to containers. Container-native virtualization allows you to continue using existing virtual machines without the overhead. And because Container-native virtualization is Kubernetes-native you keep the structure of your existing virtual machines on a platform that takes advantage of all things Kubernetes.
If you have an application built on .NET and Windows Server 2012 R2, as an example, but you’re ready to start bringing Kubernetes into the equation, Container-native virtualization may be a path to do so. In this scenario legacy applications built on .NET continue to live on in its original state, without change. Little effort is needed to migrate this workload in its existing virtual machine to Container-native virtualization. Meanwhile, those applications that are ready to start development in a Kubernetes-native state can do so. Typically, this would cause major complexities, but with Container-native virtualization both environments can be managed through a single management pane without compromising their unique architectures. Leveraging Container-native virtualization minimizes management time and resources and allows your application to live under its current requirements while delivering flexibility for future technology upgrades.