Over the last few years, enterprises have adopted multi-cloud strategies in an effort to increase flexibility and choice and reduce vendor lock-in. According to Flexera's 2020 State of the Cloud Report most companies embrace multi-cloud, with 93% of enterprises having a multi-cloud strategy. In a recent Gartner survey of public cloud users, 81% of respondents said they are working with two or more providers. Multi-cloud makes so many things more complicated that you need a damn good reason to justify this. At Humanitec, we see hundreds of ops and platform teams a year, and I am often surprised that there are several valid reasons to go multi-cloud. I also observe that those teams which succeed are those that take the remodeling of workflows and tooling setups seriously.
What Is Multi-Cloud Computing?
Put simply, multi-cloud means: an application or several parts of it are running on different cloud-providers. These may be public or private, but typically include at least one or more public providers. It may mean data storage or specific services are running on one cloud providers and others on another. Your entire setup can run on different cloud providers in parallel. This is distinct from hybrid cloud services where one component is running on-premise and other parts of your application are running in the cloud.
Your Helm Zoo Will Kill You
This article is controversial. It aggressively questions helm-charts and current dev workflow designs, and I’m well aware that not everyone will like this. Let me be clear before we dive in: this is an enterprise view. It’s a view that is relevant to team sizes of 20 developers onwards. If you’re a smaller dev shop that builds a few apps, this doesn’t apply to you, and you should just keep things as is. But for those of you that are working at scale or that are about to scale: watch out. Your helm-chart zoo will kill you. Maybe not tomorrow but almost definitely next year.
Working Change by Change With kubectl
At first, they created kubectl-kangaroo, and everyone could do everything the way they wanted. However, the challenge with just using kubectl is that you are working change by change. That’s fast but makes it impossible to track what has actually changed in your cluster. One super clever person went ahead and managed everything in Kubernetes manifests and then versioned them in Git. Dope, my friend, dope.