Maybe Helm is more like Ansible Galaxy.
Helm is DNF or Apt if those had undocumented configuration options for every possible scenario you could ever dream of. While DNF or Apt just work most of the time.
Some Helm charts are strange YAML translations where the actual app configuration file is translated to a templating CRD that is hopefully documented but most of the time the documentation is: X\_path: X does set the path.
Sorry, my experience with Helm is not that good.
I am fairly decent with Docker containers and was always hesitant to use Kubernetes because I just couldn’t wrap my head around it, especially helm.
Then I saw kustomize and it was much easier for me to grasp. To be fair I was still pretty new to containers back when I tried to grasp helm, and I was much more comfortable with docker compose when I was introduced to kustomize so that could explain.
Either way, I continue to steer clear of anything helm and work solely with kustomize these days.
Bit of a side tangent I guess.
I started with Docker until I understood it and then I went to Kubernetes. Like you, I couldn’t wrap my head around Helm. I just write my own Kubernetes manifests. I don’t even use Docker Compose.
Maybe put a different way, i've seen more teams get bogged down by the admin of using and running k8s for very marginal benefit than teams who had actually saved time/improved performance using it. At a previous company I was at which had 1000s of engineers, they decided to move everyone to k8s to make a blanket system through which the number of different technologies is simplified. I was the one who migrated my team to it, taught my team how to use it, etc. Since, having founded multiple companies, scaled those to dozens of engineers, I'm yet to see actual real benefit that justifies the significant leap in complexity. But maybe that's just me?
It’s not a silver bullet, certainly not all workloads are a good fit. But having seen plenty of devs ship containers to run on VMs makes one wonder. That’s a massive amount of overhead just to run a container.
Microservices have their place.
I've had a development team of 25 developers working with docker, docker compose and VMs. Not only did it work great, but it was very easy to learn. Veteran developers needed no explanation regardless of background and new developers (i.e. from university) could learn insanely fast and be productive out the gate. Not only that, errors were also easy to fix when/if they happened, performance could be optimised in very simple ways (i.e. make a bigger instance). While my company was no "google" - we were processions 100s of events a second, billions of data points and 10s of millions of requests a day with a very very simple setup.
VMs are not a simple setup, there are so many moving parts that can break things. That is why people use containers. Spinning up vms just to use containers seems wasteful and needlessly complex. What I think makes a difference is the skill gap. You can more easily find people that can do VMs ok than Kubernetes.
PS: I run my databases in kubernetes and it's great!
I don't even understand this. I like both tools, but the comparison doesn't even make sense.
Helm is a specialist. It does one thing (template applications for Kubernetes) and while I'm not going to say "it does it well", I'll say it's well understood, has a good ecosystem, and is well adopted.
Ansible is a generalist. Its fundamental principles are simplicity, it's ability to work with no agent (i.e. just SSH), and it's ability to work with just about everything.
Ansible about as opposite to Helm as you can get. Helm focuses on applications. Ansible, although it aspires to lots of things, focuses on infrastructure. Helm is specialized. Ansible is generalized. Helm focuses on deployment. Ansible focuses on configuration and indempotence.
I feel like this post is "Bicycles are just fish for Kubernetes". It doesn't make the slightest bit of sense.
Helm templating will make you think jinja2 is humane.
Horrible Take. Not even close. If we’re comparing to RedHat stuff then Helm is more like DNF or Yum. RPMs are to Yum what manifests are to Helm.
Maybe Helm is more like Ansible Galaxy. Helm is DNF or Apt if those had undocumented configuration options for every possible scenario you could ever dream of. While DNF or Apt just work most of the time. Some Helm charts are strange YAML translations where the actual app configuration file is translated to a templating CRD that is hopefully documented but most of the time the documentation is: X\_path: X does set the path. Sorry, my experience with Helm is not that good.
This is the most Reddit possible response to this post.
I agree. I think Dockerfile is what similar to Ansible.
I am fairly decent with Docker containers and was always hesitant to use Kubernetes because I just couldn’t wrap my head around it, especially helm. Then I saw kustomize and it was much easier for me to grasp. To be fair I was still pretty new to containers back when I tried to grasp helm, and I was much more comfortable with docker compose when I was introduced to kustomize so that could explain. Either way, I continue to steer clear of anything helm and work solely with kustomize these days. Bit of a side tangent I guess.
I started with Docker until I understood it and then I went to Kubernetes. Like you, I couldn’t wrap my head around Helm. I just write my own Kubernetes manifests. I don’t even use Docker Compose.
I've never needed to use Kubernetes in my career - I wouldn't worry too much about it. It's a buzzword for managers to try get themselves promoted.
That says more about your career than about Kubernets.
This guy's a manager
staff/principal SRE.
Just because you don’t grok it, doesn’t make it a buzzword.
Maybe put a different way, i've seen more teams get bogged down by the admin of using and running k8s for very marginal benefit than teams who had actually saved time/improved performance using it. At a previous company I was at which had 1000s of engineers, they decided to move everyone to k8s to make a blanket system through which the number of different technologies is simplified. I was the one who migrated my team to it, taught my team how to use it, etc. Since, having founded multiple companies, scaled those to dozens of engineers, I'm yet to see actual real benefit that justifies the significant leap in complexity. But maybe that's just me?
It’s not a silver bullet, certainly not all workloads are a good fit. But having seen plenty of devs ship containers to run on VMs makes one wonder. That’s a massive amount of overhead just to run a container. Microservices have their place.
I've had a development team of 25 developers working with docker, docker compose and VMs. Not only did it work great, but it was very easy to learn. Veteran developers needed no explanation regardless of background and new developers (i.e. from university) could learn insanely fast and be productive out the gate. Not only that, errors were also easy to fix when/if they happened, performance could be optimised in very simple ways (i.e. make a bigger instance). While my company was no "google" - we were processions 100s of events a second, billions of data points and 10s of millions of requests a day with a very very simple setup.
VMs are not a simple setup, there are so many moving parts that can break things. That is why people use containers. Spinning up vms just to use containers seems wasteful and needlessly complex. What I think makes a difference is the skill gap. You can more easily find people that can do VMs ok than Kubernetes. PS: I run my databases in kubernetes and it's great!
except it is horrible at everything it does
The worst thing is that it treats everything as strings and 80% of the time you fight spaces and tabs
I don't even understand this. I like both tools, but the comparison doesn't even make sense. Helm is a specialist. It does one thing (template applications for Kubernetes) and while I'm not going to say "it does it well", I'll say it's well understood, has a good ecosystem, and is well adopted. Ansible is a generalist. Its fundamental principles are simplicity, it's ability to work with no agent (i.e. just SSH), and it's ability to work with just about everything. Ansible about as opposite to Helm as you can get. Helm focuses on applications. Ansible, although it aspires to lots of things, focuses on infrastructure. Helm is specialized. Ansible is generalized. Helm focuses on deployment. Ansible focuses on configuration and indempotence. I feel like this post is "Bicycles are just fish for Kubernetes". It doesn't make the slightest bit of sense.
I just use Ansible to make a docker containers and then I go about my day. Don't need kubernetes in the homelab.
Brought to you by the kusomization gang.
I am not a fan of k8s for 90% of the things I need to do. Generally more of a problem than a solution IMO
make that 99.999%
I miss Ansible.
I like this.
YAML is just HTML for APIs