Company where I work had huge risk audit.

The second highest risk is using USA based cloud with 66/100.

The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.

I still see Gavin working on JEE.

Yeah my old colleagues who work on Kroxylicious are now IBM. I keep asking them if they're wearing a blue tie to the office yet, they still don't think it's funny.

RPi doesn't exist due to Broadcom. It exists despite Broadcom.

Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.

RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.

Yeah Broadcom had a load of unsellable SOCs they needed to off load

That doesn't really answer the question, does it?

Write a few Helm charts and you'll understand why people want to stop using it. `nindent` will become a curse word in your vocabulary. It's a fine tool at the user level, but the DX is an atrocity.

Consuming one that is well written isn't too much pain, IME. But writing or modifying one can be really annoying. Aiui the values.yaml has no type schema, just vibes. The whole thing is powered off using text templating with yaml (a whitespace sensitive language), which is error prone and often hard to read. That's basically the main issues in a nutshell, it may not sound like much, but helm doesn't exactly do a whole lot and it does that limited set of stuff poorly.

I will leave it to others: https://noyaml.com

Golang string templating in a whitespace sensitive config language suuuuucks.

I might use Helm charts for initial deploys of operators, but that's about it.

Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.

I wouldn't say you're missing out. If kustomize works for you, keep using it. I personally use helm because I cannot for the life of me wrap my head around kustomize. I've looked at tutorials, read the docs, and it just doesn't make sense to me. Helm, on the other hand, immediately clicked and I was able to pretty effortlessly write charts for our use. It's just a case of different preference in tools, imo.

Helm gives you more than enough rope to hang yourself with. At $dayjob we barely use 3rd party helm charts, and when we do we eventually run into problems with clever code.

We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.

So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.

Would you like to count the number of spaces that various items in your manifests are indented and then pass that as an argument to a structure-unaware text file templating engine? Would you like to discover your inevitable yaml file templating errors after submitting those manifests to the cluster? Then yes, you are really missing out!

The main advantage of helm in my experience is:

1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories. 2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config