I am no Concourse expert, but I've tried it a couple times.

Concourse's interface is just beautiful and functional, the CLI is great as well, but it has it's own ecosystem. Lot's of tools to solve problems that K8s already solves (Jobs, Volumes, resources, scheduling, etc..) it also uses workers which if I remember correctly is just like a scheduled slave which you need to install stuff into.

Argo is a different beast, it uses k8s like it should be done in my view.

It schedules container to one or multiple k8s Clusters, using CRDs which is kind of a DSL on top of the k8s api. It does not run slaves, is simply a debian or busybox pod, a Job or other resource that runs and returns pakages to the workflow or pass it on. The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing.

BTW I have zero to do with Argo, I just find it awesome and am waiting for it to be more stable.

> Lot's of tools to solve problems that K8s already solves

In fairness, Concourse predates Kubernetes and was invented developed to support a team working on a different container scheduler (Diego, similar vintage to Kubernetes).

Otherwise you're right. The pain of carrying around its own container scheduling, worker management etc has been a notably hefty thorn in the side of Concourse for the last two years or so. It should go away as Concourse gets rebased onto Kubernetes.

> The Syntax, is K8S YAML syntax, the same with a couple more things, very little learning curve if you know K8S YAMLs, Concourse is a very different thing.

As part of my work in and around Knative Build, Topher Bullock and I wrote a little façade Kubernetes controller[0] that lets you send pipelines and see builds from kubectl. Basically it looks like an existing Concourse pipeline, but with the usual k8s boilerplate.

I'm not sure what the final Concourse-on-Kubernetes will look like. kubectl is showing one-size-fits-all discomfort (see, for example, knctl[1]) and I am not sold that CRDs are suitable for every purpose. 2018 is clearly The Year of the CRD, so I figure we're about 18 months away from the trough of disillusionment on those.

[0] https://github.com/jchesterpivotal/knative-build-pipeline-po...

[1] https://github.com/cppforlife/knctl

Concourse's components (ATC, DB, Workers) can run on Kubernetes, but it is still handling the scheduling of containers it creates.

Delegating container scheduling to Kubernetes is the next major epic on the Core track for Concourse.

As for Argo: I am not particularly in favour of Turing-complete YAML.

Disclosure: I really like Concourse. I work for Pivotal, which sponsors Concourse development.

Valid point.

Don't fly you end up creating a turing-complete config file as well? I remember it being stored as some kind of Yaml like syntax.

Fly does substitutions, but that's it: no loops, no if-thens. It's almost certain that something can be tickled into being Turing-complete; it's actually devilishly difficult to avoid doing it by accident. My hunch is pipelines are Turing complete, but I haven't gotten around to proving it.

But there's a difference between trying not to introduce it and going out of your way to build a programming language in YAML. An actual, honest-to-god programmable YAML.

Wait, doesn't Pivotal also sponsor Turing-complete YAML development?

BOSH v1 manifests were Lovecraftian. Well beyond Turing and into the deep underdark of the Beyondness That Must Not Be Yea Even Unto Enterprise.