I am currently moving from ECS to EKS and I'm confused over the divide between Helm and Terraform.
We currently have a dedicate Terraform/Packer repo for our EKS cluster.
We then have a repo for our app. The app requires an AWS RDS instance and SQS/SNS.
My understanding is Helm doesn't support SQS or other service setup, in which case I question why I would bother with Helm when it's pretty easy to deploy all required queues/db/app in EKS using purely Terraform? It seems that by introducing Helm all I end up doing is creating an unnecessary split in the app setup for K8/NonK8 app setup.
I feel like I'm missing the point of Helm, but I'm struggling to see what it is? Help me see what I'm missing!
Helm is for installing applications on your EKS. SQS and RDS are not applications running on your container cluster, they are infrastructure. For those you can use Terraform, CloudFormation or CDK.
You can find more examples on how to use the different tools here: https://www.eksworkshop.com/
You can do whatever Helm does using other tools like Terraform. It depends on what background you're coming from in my opinion.
Helm was one of the initial tools DevOps folks had available to tackle "YAML hell" as Kubernetes, Cloud-Native, Microservices were really taking off in Production use. It's easy to pick up for an ops oriented person used to hacking things in shell, command line, or using Jinja text-templates in Python scripts.
Because of this, there's a lot of inertia behind Helm charts and a lot of Cloud Native products choose to publish Helm charts as a "quick" way to get their product up and running on a Kubernetes cluster.
I personally avoid using Helm charts and (if these charts aren't too insane) elect to translate them into Terraform so it fits properly within the GitOps/IaC paradigm and I gain consistency across both infrastructure provisioning and deployment. I also suspect Helm charts are harder to maintain from a team development perspective in the long run.
If IaC isn't your preference, then a "cleaner" solution then Helm would be kustomize, especially as it's supported by Google and is actually built into the kubectl binary at this point. This is also a utility for templating/generating Kubernetes manifests, but does not introduce or rely on external state like Helm does.
Helm and Terraform serve two different purposes. Typically, you use both for CI / CD focused cloud native provisioning. Helm lets you easily provision services that are intended to run within a Kubernetes cluster. With Terraform, you can provision the Kubernetes cluster itself or any other PaaS components (such as databases or message brokers) intended to run outside of the Kubernetes cluster. For more elaboration, see this blog on devops renaissance.