This is the first of a 2-part blog series on how IBM storage solutions can help you move from VMs to Containers.
I am spending a lot of my time in customer conversations and writing RFI responses about moving workloads off VMware. These engagements tend to take two forms (1) “We need to accelerate our digital transformation journey to cloud native application deployment.” or (2) “We need a different hypervisor ASAP.”
Many customers have started their move to containers with OpenShift Virtualization (upstream Kubevirt). Running VMs in containers works great for commercial software or for internal applications whose cost/benefit analysis for refactoring to containers is too expensive. Running VM applications side-by-side with container applications is a common pattern in the digital transformation journey. (For those new to OpenShift, full support for Kubevirt began with OpenShift 4.5 in 2021, called Container Native Virtualization (CNV) at the time.)
The accelerated move from VMware has added new focus on OpenShift Virtualization (OSV) (the new name for CNV). Moving VMs to containers is an established pattern with a new catalyst. Instead of refactoring applications before moving to OpenShift, applications in VMs are moved to OSV and then are refactored to cloud-native architecture. This gets all the workloads running on a single platform that is not VMware.
Customers who have not started the journey to containers have a strategic decision to make. Are they going to pick a different traditional hypervisor to run the VMs or go to a Kubernetes platform and run their VMs in Kubevirt. The former may be easier, but it leaves another re-platforming effort ahead. Moving to Kubevirt may be more difficult (unclear – Red Hat tooling to move VMs to containers is very good) but it does involve learning new infrastructure paradigms.
Making a “new hypervisor only” decision must be driven by a very compelling financial advantage. Almost all IT prognosticators view the move to cloud native deployment as a “when” and not an “if” event. So, making a “new hypervisor only” decision is just kicking the can down the road, eventually the organization will have to invest in the transition to containers. If you are questioning the value of converting you’re applications to microservices, I suggest you read Virtual Machines Versus Containers, a case study from 2021.
Real or Virtual SAN
Current VMware deployments fall into one of two architectural camps: (1) deployed on physical SAN infrastructure with switches (IP or FC) and storage arrays or (2) ‘converged’ with storage-rich servers and software to distribute & protect data across the nodes in the compute cluster.
Figure 1: VMware Deployment Options
In my conversations, customers are looking for similar architectures for their next gen deployment as they have in their VMware deployment today, i.e. if they deployed VMware in a converged architecture, they want to deploy OpenShift in a converged manner. If they have SAN, they want to continue with a dedicated storage infrastructure.
Aside: I talked to one customer who was interested in going back to SAN infrastructure from HCI because they felt there was too much stranded capacity in their HCI solution. When I explained the difference between software defined converged infrastructure and an HCI appliance, their desire to move back to SAN waned. (The scale-out nature and support for OpenShift Hosted Control Planes (HCP) in the Fusion HCI solution addresses this challenge.)
One of the many benefits of IBM Fusion Data Foundation (FDF) is it can be deployed in either a converged or an external storage infrastructure. Data Foundation internal mode deploys both the Ceph data plane and data services control plane within the OpenShift cluster. Data Foundation external mode uses a standalone IBM Ceph cluster for the data plane that can be shared by many OpenShift clusters running independent control planes. Both have the same user features (integrated GUI; file, block, S3 object storage, integrated backup and disaster recovery) that have made Data Foundation the leading storage services provider for OpenShift.
Figure 2: Fusion Data Foundation Deployment Options
Internal mode Fusion is deployed via opinionated OpenShift Operators that makes it very easy to install, setup and manage. Using an external Ceph Cluster adds another point of management, but also exposes the full power of Ceph. Ever wish you had real “superuser” access to your storage system. Root access to a Ceph cluster gives you access to the RHEL kernel and everything above. Want to understand how your storage system really works, look at ceph.io. Further, tired of waiting for your vendor to implement your favorite new feature – welcome to open-source solutions.
The increased desire to move workloads off VMware is causing major disruption in most organization’s IT departments. Major efforts are being undertaken to reduce IT spend. Reducing the spend means making an investment to employ a new infrastructure for running applications critical to the business. Surveys for years have shown that most IT spend is just to keep the “lights-on” for the business. Companies are faced with the decision to invest solely to save money and maintain the same business operations or to invest to accelerate their journey to a new infrastructure paradigm that improves IT and business operations. If you choose the to invest in the future, i.e. deploy your VMs on OpenShift, IBM Fusion will let you proceed with your storage architecture of choice and provide the foundation for the future.
In my next blog I will discuss how IBM Ceph can provide storage for your current deployments. I expect to get it published in the next couple of weeks.
More information on IBM Fusion:
IBM Fusion on IBM.com
Fusion Community Page
IBM Fusion Documentation