If you, like me, are in the software field, know that this is likely the most comfortable job even invented by humanity, we should really be paid just above the poverty line in exchange.

As long as you don't use their exclusive DBaaS, moving away is easier than from other places, as egress traffic is free.

The user experience though, stuff of nightmares...

Messages of that sophistication are always dangerous, and modern advertising is the most widespread example of it.

The hostility is more than justified, I can only hope the whole industry is regulated downwards, even if whatever company I work for sells less.

Give it a few more decades, hopefully it'll be boring by then, the same way, say, making a house is boring.

Now, of course they should get paid for the work they do, but these sort of "we were FOSS and surprise we're not anymore" are becoming commonplace and are always done hoping no one notices.

It's just old ideas that get repeated even once they stop being true.

can you elaborate?

After a decade of use I've seem some more cutesy porcelain popping up, but the commit-tree basic concepts have never changed.

The company I work at is using the same exact branching strategy I introduced when we moved to git, with essentially no discussion in the meantime.

Could you elaborate? I'd like to learn from the errors of the past

* a good trade on the templating side (swapping the helm go-template-like thingy with a real language)

* a loss on the cluster integration side, where I like the integration of helm with ArgoCD and would instead need to add a manifest generation step

Will add it to the "cool shit to check out" pile, thanks.

Will add it to the "cool shit to check out" pile, thanks.

Kustomize is extremely limited and opinionated, which is great if your deployments have only kustomize-approved differences between them, but it has no way to write business-aware config files and at my typical 100 deployments/chart is was becoming megaduplicated.

For secrets I'm a big fan of https://external-secrets.io/latest/ paired with a cloud vault, which allowed me to offload secret production/maintainance to the resource teams.

I tried using TF to manage kube manifests, I hated it all around and moved away immediately, so I agree with you.

I want the values.yaml to express business logic, like feature flags or external endpoint configuration, so that the Delivery team can easily read and update it.

The complex infrastructural components should derive from the business config and deploy the needed infrastructure to support it.

Still, I wish I had this tidy list of working kubernetes yaml templates years ago, when we started rolling our charts where I work. I'm definitely checking out some of the resources to see if there is some cool parameter I can steal, thanks for sharing.

See: https://github.com/scanmem/scanmem/blob/c6045a8677f37a51b976...