Companies adopt hybrid and multicloud strategies for various reasons, including reliability, geographic necessity, and vendor independence and with this comes the complexity that no two private or hybrid clouds are alike. Despite the industry standardizing on Kubernetes, how it presents itself is different for every cloud. Amazon‘s Elastic Kubernetes Service (EKS) requires different configuration than Microsoft’s Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE). Most private clouds are built on platforms like VMWare‘s Tanzu/VSphere or Nutanix where the installs and deployed capabilities are often highly customized. Any systems engineer who has tried to maintain multicloud or hybrid cloud infrastructure knows that this variability makes management very difficult. It is not just the different Kubernetes configurations but the scripts necessary to log in and apply the changes are also unique. And even if one is adopting infrastructure as code approaches, managing those scripts in git, managing the scripts across a set of git repositories and branches, and ensuring the right configs are applied to the right runtime environments remains a heavy lift. Let’s say, for example, that some new regulatory-related config needs to be added to deployments across AWS and vSphere, the SRE needs to first add the appropriate config to both the AWS and the vSphere branches in git, and then they need to make sure to apply the former to the EKS implementation and the latter to the Tanzu cluster. All too often, the application of these config changes is done by hand — say, using the AWS cli or the vSphere console — and mistakes will be made.