Just to expand a bit on why I'm saying this generalizing orchestration is hard and why just a reference implementation may be the best way forward is just from what I"ve seen. The only thing that's consistent about how people think about their infrastructure is that they are all unique in their own ways. K8s is a great abstraction layer (Implemented this on my last team as well, put 10 devs on a K8s cluster internally so I get the concepts decently) but the idea that each k8's environment is created equal is wishful thinking (I hope I'm wrong here but based on what's happening in these markets I don't think so) . EKS vs Baremetal vs a,b,c,d,e,f,g,h ways of deploying K8s is tough. Many times my team would rip apart a helm chart for the 3 things they wanted, and just make their own files as it was easier/cleaner than frankensteining a helm chart that's setup for infinite scale together. (Maybe that was just us, and we were doing K8s wrong, totally possible) To me it's fairly similar to the idea of having DBT models for sources (Which is at least an order of magnitude less difficult). Fivetran, and Meltano both have some model packages for difference sources. Almost always what actually happens when people use these that I've seen is they either , copy paste the whole thing into their own DBT project and edit to their own needs. Or they wrap the model and imminently add and work around things they don't like in the model Finding that sweet spot of Meltano to the Orchestrate layer will take some finesse chef kiss , if any team can figure it out I'd think it'd be the Meltano team!