Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAQ:Helm vs. alternatives #446

Merged
merged 3 commits into from
Jan 13, 2020
Merged

FAQ:Helm vs. alternatives #446

merged 3 commits into from
Jan 13, 2020

Conversation

drnickiw
Copy link
Contributor

what

  • Helm vs. alternatives FAQ

why

  • Imported from Google Doc

Links to #353

@@ -0,0 +1,26 @@
---
title: "What are the reasons for using Helm over some alternatives?"
description: "Of the tools out there, Helm has probably a 1000x lead over the others."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: "Of the tools out there, Helm has probably a 1000x lead over the others."
description: "Helm is the only available package manager for Kubernetes"


## Answer

Tiller potentially introduces well-known security concerns. There are plans for removing it, but no ETA yet when that will be released.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Tiller potentially introduces well-known security concerns. There are plans for removing it, but no ETA yet when that will be released.
There are many valid security concerns over deploying Tiller (v2) in Kubernetes clusters. These can and will be addressed in Helm v3.


Tiller potentially introduces well-known security concerns. There are plans for removing it, but no ETA yet when that will be released.

The only constant in the K8s ecosystem is that it’s constantly changing and evolving. Helm is a very intrusive decision, and there are many alternative approaches. Of those, Ksonnet is most interesting, since it presents a pretty terse way of expressing Kubernetes resources and is the result of years of research into developing a concise language for JSON manipulation. Then again, coding in JSON isn't our fave either (Cloud Formation = evil).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The only constant in the K8s ecosystem is that it’s constantly changing and evolving. Helm is a very intrusive decision, and there are many alternative approaches. Of those, Ksonnet is most interesting, since it presents a pretty terse way of expressing Kubernetes resources and is the result of years of research into developing a concise language for JSON manipulation. Then again, coding in JSON isn't our fave either (Cloud Formation = evil).
The only constant in the K8s ecosystem is that it’s constantly changing and evolving. Helm is one of the be options available today and there are many alternative approaches. Of those, Ksonnet is most interesting, since it presents a pretty terse way of expressing Kubernetes resources and is the result of years of research into developing a concise language for JSON manipulation. Then again, coding in JSON isn't our favorite pastime either; writing raw Cloud Formation is a horrible experience.


The only constant in the K8s ecosystem is that it’s constantly changing and evolving. Helm is a very intrusive decision, and there are many alternative approaches. Of those, Ksonnet is most interesting, since it presents a pretty terse way of expressing Kubernetes resources and is the result of years of research into developing a concise language for JSON manipulation. Then again, coding in JSON isn't our fave either (Cloud Formation = evil).

Here's the deal. Yes, there are a lot of alternatives and the ecosystem is rapidly expanding. Of the tools out there, Helm has probably a 1000x lead over the others. It sucks to template YAML. We’re not a fan. It sucks to have the Tiller deployed. If we consider "academic ideals," then we can probably select some other approach today that is incrementally better than Helm. However, to put things into perspective, we've spent thousands of hours getting everything running on Kubernetes using Helm Charts provided by the community (who have in turn spent thousands of hours developing those charts). We cannot begin to imagine the scope-of-work to use any other tool and the SME required to redraft that many services (probably 10x the cost). It would be possible to take a hybrid approach where some core/central services are deployed via Helm, then deploy custom services using a different strategy. This would optimize perhaps the developer experience. However, it introduces yet another way of deploying software to the cluster. We're open to alternative approaches, but it’s not our standard recommendation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Here's the deal. Yes, there are a lot of alternatives and the ecosystem is rapidly expanding. Of the tools out there, Helm has probably a 1000x lead over the others. It sucks to template YAML. We’re not a fan. It sucks to have the Tiller deployed. If we consider "academic ideals," then we can probably select some other approach today that is incrementally better than Helm. However, to put things into perspective, we've spent thousands of hours getting everything running on Kubernetes using Helm Charts provided by the community (who have in turn spent thousands of hours developing those charts). We cannot begin to imagine the scope-of-work to use any other tool and the SME required to redraft that many services (probably 10x the cost). It would be possible to take a hybrid approach where some core/central services are deployed via Helm, then deploy custom services using a different strategy. This would optimize perhaps the developer experience. However, it introduces yet another way of deploying software to the cluster. We're open to alternative approaches, but it’s not our standard recommendation.
Here's the deal. There are a lot of alternative strategies for deploying applications to kubernetes and the ecosystem is rapidly expanding. The most important distinction to make regarding `helm` is that it's a package manager that does some templating. All the other alternatives out there are strictly template engines. Templating is not enough and is the equivalent of managing an operating system with only tarballs and `sed`; it can be done, but you can't find a single operating system out there that works that way. Kubernetes is a modern incarnation of a cloud-native operating system. It needs a package manager and critical mass is behind Helm. Of the tools out there, Helm has probably a 1000x lead over the others. While we are not in favor of using `gotemplates` for YAML, it's an implementation detail; for example, helm v3 will add support for Lua. What helm does is provide an interface for package management. How it does it on the backend can and will evolve.
While there are a number of aspects of helm we're not fond of and there are some other more elegant approaches to defining kubernetes resources, we urge our customers to put things into perspective. We've spent thousands of hours getting everything running on Kubernetes using Helm Charts provided by the community (who have in turn spent thousands of hours developing those charts). We cannot begin to imagine the scope-of-work to use any other tool and the SME required to re-draft that many services (probably 10x the cost). It would be possible to take a hybrid approach where some core/central services are deployed via Helm, then deploy custom services using a different strategy. This would optimize perhaps the developer experience. However, it introduces yet another way of deploying software to the cluster. We're open to alternative approaches, but it’s not our standard recommendation and we defer to the kubernetes community at large to provide thought leadership in this area.


Here's the deal. Yes, there are a lot of alternatives and the ecosystem is rapidly expanding. Of the tools out there, Helm has probably a 1000x lead over the others. It sucks to template YAML. We’re not a fan. It sucks to have the Tiller deployed. If we consider "academic ideals," then we can probably select some other approach today that is incrementally better than Helm. However, to put things into perspective, we've spent thousands of hours getting everything running on Kubernetes using Helm Charts provided by the community (who have in turn spent thousands of hours developing those charts). We cannot begin to imagine the scope-of-work to use any other tool and the SME required to redraft that many services (probably 10x the cost). It would be possible to take a hybrid approach where some core/central services are deployed via Helm, then deploy custom services using a different strategy. This would optimize perhaps the developer experience. However, it introduces yet another way of deploying software to the cluster. We're open to alternative approaches, but it’s not our standard recommendation.

Side rant: We’ve see a lot of beautiful demos of "easy deployments" on Kubernetes. Kelsey Hightower has one that makes us green with envy. However, all the ones we’ve seen (including his) fall apart when you want to deploy real apps (not `hello world`). For example, take a look at the Helm Chart for [Grafana](https://github.com/helm/charts/blob/master/stable/grafana/templates/deployment.yaml) or Prometheus. It would be a massive effort to port something like that to any other mechanism. There are approximately 15 more resources.
Copy link
Member

@osterman osterman Apr 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Side rant: We’ve see a lot of beautiful demos of "easy deployments" on Kubernetes. Kelsey Hightower has one that makes us green with envy. However, all the ones we’ve seen (including his) fall apart when you want to deploy real apps (not `hello world`). For example, take a look at the Helm Chart for [Grafana](https://github.com/helm/charts/blob/master/stable/grafana/templates/deployment.yaml) or Prometheus. It would be a massive effort to port something like that to any other mechanism. There are approximately 15 more resources.
Side rant: We’ve see a lot of beautiful demos of "easy deployments" on Kubernetes. Kelsey Hightower has demoed many that embody what we aspire to achieve, but are not reflective of the current reality of deploying complex interdependent applications. The "hello world" examples brush over many challenging requirements such as secrets management, persistence, multi-tiered rollbacks, canary deployments, mesh networks, etc.
For example, take a look at the Helm Chart for [Grafana](https://github.com/helm/charts/blob/master/stable/grafana/templates/deployment.yaml) or Prometheus. It would be a massive effort to port something like that to any other mechanism. Then multiply that times the 15-20 other services we typically depend on in a production-grade cluster deployment. For example: `external-dns`, `kiam`, `prometheus`, `prometheus-operator`, `alert-manager`, `nginx-ingress`, and `fluentd`. It’s no small feat.


Side rant: We’ve see a lot of beautiful demos of "easy deployments" on Kubernetes. Kelsey Hightower has one that makes us green with envy. However, all the ones we’ve seen (including his) fall apart when you want to deploy real apps (not `hello world`). For example, take a look at the Helm Chart for [Grafana](https://github.com/helm/charts/blob/master/stable/grafana/templates/deployment.yaml) or Prometheus. It would be a massive effort to port something like that to any other mechanism. There are approximately 15 more resources.

Multiply this number by 10 for all the other services: `external-dns`, `kiam`, `prometheus`, `prometheus-operator`, `alert-manager`, `nginx-ingress`, and `fluentd`. It’s no small feat.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Multiply this number by 10 for all the other services: `external-dns`, `kiam`, `prometheus`, `prometheus-operator`, `alert-manager`, `nginx-ingress`, and `fluentd`. It’s no small feat.

Copy link
Member

@osterman osterman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments

@osterman osterman merged commit 251aa93 into master Jan 13, 2020
@osterman osterman deleted the helm-vs-alternatives branch January 13, 2020 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants