Helm (also in combination with terraform) is a client side tool for deploying charts to your cluster.
Glasskube on the other hand is a package manger where you can find look up, install and configure packages via a cli and UI and overcome some of the shortcomings of Helm.
I think there is a fundamental misunderstanding about what a package manager is.
From Wikipedia: "A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer in a consistent manner." https://en.wikipedia.org/wiki/Package_manager
Helm is a package manager as it consistently,
* Can pull and deploy applications via packages
* Can manage (upgrade/reconfigure/delete) deployed applications
* Can search and find helm charts.
So the difference is it lacks a GUI? Afaik GUI was never a requirement for a package manager.
And another perspective is, as GlassKube does not provide a packaging mechanism, and uses helm in the backend (established in another question, which I'll also reply) it's not really a package manager but a frontend to another one.
(examples: dpkg - package manager - apt-get/apt/aptitude frontend)
Also IMHO, Considering CNCF landscape, Glasskube is more positioned as a Continues Delivery tool than a package manager. But this is my take.
You’ll hear various opinions on how good it is at each of these roles. In my personal experience it is a decent package manager, a poor but serviceable templating engine, and a horrifically bad deployment tool.
Normally you pair Helm with something like Flux or Argo if you want IaC
IMO terraform is probably not the right tool for the job for managing deployments. It can do it, but like helm itself, it’s also not super great at doing cluster deployments. If you’re looking for a good GUI like experience Argo is a good option.
I like Terraform for managing infra, and it’s good at a lot of things, but managing deployments on a cluster with IaC is not one of them. Why? Mainly because deployments are much more dynamic than infrastructure and the amount of throat clearing required for terraform to perform a state diff is much much much higher than other tech. Much better to look at the tech I mentioned (Argo and Flux) for that, because they do state diff for these things in milliseconds. I’ll leave it to the reader to figure out how long it takes terraform to do this.
It’s possible to go entirely in the “everything is a kube manifest” direction using technologies like Crossplane and Cluster API and (for AWS) technologies like ACK. But I don’t think we are entirely there yet for these technologies in terms of maturity, so in my recent designs I usually settle for provisioning of cluster and initial bootstrapping with terraform before mostly handing off to Argo for deployment, but then doing this weird counterbalance for having to go back to terraform when infra stuff is necessary. I can see a future world, however, where you bootstrap management clusters with something like terraform but then basically everything else, both infra (clusters, buckets, IAM, etc) and deployments (Helm) is declarative through tech like Argo and Crossplane provisioning.
The tough part right now is when you have application devs that need to provision infrastructure and then deploy on top of it. Right now that looks like asking your developer to write some app specific terraform like S3/IAM/KMS/Redis/whatever and then deploying their app on top of it with Argo or flux or what not. The ideal maybe looks like using the same tech for both eventually, as well as even provisioning the cluster that the stack runs on with the same tech.
Glasskube on the other hand is a package manger where you can find look up, install and configure packages via a cli and UI and overcome some of the shortcomings of Helm.