This message was deleted.

Acorn is more like a whole paas, there is https://score.dev/ and https://github.com/gimlet-io/onechart

Thanks @Hugo Pinheiro! I have also found: • https://github.com/ocd-scm/ocd-deployer • https://github.com/energywebfoundation/generic-microservices-helm • https://gimlet.io/k8s-yaml-generator < linked to your Onechart suggestion

You can also try https://github.com/devtron-labs/devtron

Interestingly I think these tools all try to define the interface but I have found that either companies like to use the Kubernetes native interfaces (e.g. a deployment) or generate their own with something like a custom helm chart values file. Are you thinking you want to rely on something public (which is often vendor specific) or build your own?

It's a bit of an 'unknown unknown' at the moment. In the ECS world we have built a tool that synthesises Cloudformation from a declarative YAML config, but when it comes to escape hatches I've felt we're always playing 'catch up' to AWS. Day 1 support for new fields and features is the best we can achieve, but more realistically it's Month 1 or Quarter 1 support given pre-existing commitments and constraints. When digging into the Kubernetes way of working, I'd love to avoid repeating the same mistakes. Terraform is so effective because it has Day 1 support for practically everything by way of open-source contributors and a large community. If there were such a thing for deploying 12-Factor apps to k8s, I'd rather 'buy' (free or paid) before building. But, in saying that, I personally dislike in-house abstractions. I want to hire someone and have them be productive from the get-go, I don't want them learning our specific tooling if they can help it. If we can avoid building a tool all together and just craft a generic helm chart (similar to the

generic-microservices-helm

repo I linked earlier) and this is expected and 'normal' in the k8s world, I'd go that route too. Thank you for the insights, I like the sound of companies using the native interfaces!

That all makes a lot of sense, and honestly sounds like the dream! My experience is that we are still in that xkcd world of everyone trying to make a new final FINAL standard. So the idea that people would be familiar based on experiences at other companies is highly unlikely. The only chance is the k8s API, but that comes with its own challenges since it is such a low level concept for most software/application engineers.

k8s is a platform with many knobs. Most companies pick a few open source tools and combine them. Some use Terraform all the way, others crossplane. I think something like cnoe.io gives you an example of all the things you can pull together for a solution. Simpler would probably be use AWS fargate or GCP Cloudrun. Lets you skip a lot of the k8s knobs