The benefits of containerizing workloads are numerous and proven. But, during infrastructure transformations, organizations are experiencing common, consistent challenges that interfere with accurately forecasting the costs for hosting workloads in Kubernetes (K8s). Planning the proper reservations for CPU and memory before migrating to containers is a persistent issue Densify observes across our customers.
This is also true regardless of where you deploy your containers. In the case of public cloud container deployments this means an increased monthly bill—even if you opt for a managed offering. In the case of deploying containers in your own datacenter this means running out of host hardware faster—let’s hope your procurement team can keep up with your DevOps workflow (spoiler: they can’t).
To get around uncertainty about how to properly size containers, developers will naturally reserve more CPU and memory if permitted. Containers don’t solve the persistent human challenge of people asking for more resources than their apps require.
But, let’s say you don’t even have your app containerized yet—let’s say your app is still running as a VMware VM or as a public cloud instance. Or, perhaps, you run your app containerized on-premises, but you want to forecast moving those apps to containers running on public cloud before doing the move to containers or the move to cloud?
Densify can model actual existing workload patterns of VMware VMs or cloud instances moving to varied hosting environments with varied constraints to determine costs before doing the move. Transform to containers, transform to cloud, and on-premises transformation modelling—all are valuable planning scenarios for which Densify can solve.
A Densify customer running OpenShift on premises with VMware wanted to forecast their costs for moving to public cloud-based containers.
Densify predicted the costs for multiple scenarios to answer questions such as:
The team used Densify data from the existing on-premises VMware cluster to evaluate various scenarios that considered how the cluster was designed and managed, as well as to consider resizing the cluster host nodes with estimated cost projections for forecasting purposes.
One of the scenarios illustrated below demonstrates the 169 source VMware VMs as containerized workloads with associated CPU and memory request and limit specifications provided per VM based on the actual historical usage patterns of the VMs. Including considerations for parameters such as storage and networking throughput, overall workload headroom and affinity/anti-affinity this scenario would require 10 host nodes in the cluster.
Densify enlists a consultative approach when helping customers undertake successful infrastructure transformations.