4 ms·

> As an aside, the existence of the '{{ | indent 4 }}' function in helm should disqualify it from any serious use. Render, don't template. This. My first thoug

• 015a 4y ago
  For a complex use case: cdk8s is cool https://cdk8s.io/ https://cdk8s.io/
• vlunkr 4y ago
  It is shocking that such a clearly bad design choice has stuck, and that Helm has become so popular in spite of it. I've had my eye on jsonnet, I'll have to try that next time I do something in k8s.
  • runevault 4y ago
    We are using helm at work but I've never touched it so I cannot comment on it being bad. However cargo cult habits have made quite a few technologies over the years take off when they never should have just because someone with either the right sort of intelligence and/or charisma made people believe it was good, and then the ripple effect made it take off.
    • nfhshy68 4y ago
      I had someone on here assume we were a small dev shop because we don't use microservices the other day. I don't think they were expecting 2k devs to be what I responded with. Apparently monoliths a scale a lot bigger than you'd think.
  • 0xbadcafebee 4y ago
    It makes sense if you consider how poor K8s' design already is. They somehow made it overcomplicated, yet lacking in critical features, with terrible security, no multitenancy, unnecessarily duplicated concepts, confusing and redundant configuration, a nightmarish setup process, no VCS integration, with mutable state, and lock-in reliance on specific external software components, while also having microservices, when the components were never really intended to be replaced, and misbehave when their assumptions change between versions. Then they invented and sunsetted multiple iterations of the same concept (plugins, essentially), redesigned other concepts (Roles) without consolidating them, and decided long-term support/stable ABIs are for chumps, so that anyone using it was stuck doing infinite migrations. It's up there with Jenkins and Terraform as one of the worst designed systems I've seen. The fact that you need a million integrations to make it do anything useful at scale is proof that it's more of a development toy than a practical tool.
    • yuppie_scum 4y ago
      You don’t like terraform? The version churn and things like the .lock file are pains in the ass, but overall it’s gotten pretty elegant and well documented.
      • 0xbadcafebee 4y ago
        Google "terraform wrapper". Terraform's interface is so bad that a million people have written their own interface to deal with how terrible Terraform's is. Most people settled on Terragrunt, but in some ways that's actually worse (DRY configuration is actually impossible with Terragrunt; I wrote my own wrapper (https://github.com/pwillis-els/terraformsh https://github.com/pwillis-els/terraformsh) to fix that problem). Terraform's design is that of a half-baked configuration management program. It's not even declarative programming, because declarative programming requires the program actually try to achieve the desired end state. Terraform won't do that. It will try to create or destroy something based on what it thinks the world looks like, rather than what the world actually looks like. If anything is inconsistent, it simply dies, rather than try to fix or work around the inconsistency. Which is the opposite of what configuration management is supposed to do. It's supposed to fix the system state, not run away crying. In many ways, Puppet, Chef or even (ugh) Ansible would be better than Terraform at handling infrastructure state. For example, if you tell Terraform you want an S3 bucket, and it tries to create one, but it already exists, Terraform dies. In that case they want you to manually use an 'import' command to import the existing S3 bucket (which btw is a different syntax for every single resource). Why doesn't it automatically import resources? Hashicorp's "philosophy" is that automation is bad and why would we want a computer to make a human's life easier when we can make the human serve the computer? This basic but critical feature is so important that Google created an entire project dedicated to it, called Terraformer. If you write some Terraform HCL, you may be able to create your resources with it. But it's also very likely Terraform will not be able to change or destroy those same resources. Every provider has its own rules about what you can do with a resource, and none of those providers are required to apply those rules throughout the resource's lifecycle. So you deploy something to prod, and then need to change it, only to find out that change is impossible, half way through a terraform apply in production. Leaving you with broken production infrastructure. Many provider resources also have rules that require you to add a Terraform lifecycle policy, or it will be impossible to create, destroy, rename, etc a resource. Rather than make those lifecycle policies the default for a given resource, Terraform requires you to know in advance that that resource requires that lifecycle policy and to add it to every instance of that resource. But it will cheerfully create resources without the policy, with a big gaping hole in the floor waiting for your infra to fall through when you next make a change. This is a very brief list of the insane stupidity that is Terraform. A blindfolded configuration management tool that can't handle changes and doesn't like automation, validation, or sane defaults.
  • vbezhenar 4y ago
    I like helm because it's like a package manager. I don't know what's inside rpm or dpkg. I think they're terrible inside either. But the fact that I can apt install gimp makes it awesome. Same about helm. I didn't write a single helm yet. But I like packages that I can helm install and I probably would avoid software without first-class helm. Helm is good for users. I can install it, upgrade it, configure it with values. Awesome.