These are really good observations and probably points to us needing to add some clarity.

I think the thing we could explain better is we take the docker-compose and use that as a starting point to define how an application will run in Kubernetes. We aren't just running Docker when environments deploy, we're running applications in K8's. We've debated long and hard about how much K8's we expose to customers. We tend to think it's complex and if we can abstract the complexity so our customers don't have to worry about it, that would be better. Interested to know what people think about how much K8's we should expose.

The reason we choose to create a new YAML file was we needed a way to define environments. docker-compose does have some stanzas for environments but they were meant for Swarm and the older versions of compose didn't map well to K8's. This file is automatically generated and attached to an application so you don't have to write it by hand, just update pieces that apply to environments. There is definitely duplication with docker-compose in this file, we may end up migrating towards just using docker-compose with the Swarm environments definitions but we haven't seen anyone using those yet.

We're working on a few solutions to seed data and database cloning. It's a really big request and will be added very soon. We do have a few ways to do it now, but they are more one-off solutions than products at the moment. Same goes for testing. We've purposefully not tried to be a CI/CD replacement at the moment. Most of our customers are already using Jenkins or Circle so we decided to integrate for now. We are going to add simple test running soon.

So how is this different from https://github.com/kubernetes/kompose ? What is the value add here?

Kompose is a really great tool in converting docker-compose to K8's yaml. But from there you are on your own. We've worked with a few companies that started down this path, realized how difficult K8's was and gave up. We handle everything in the K8's world so customers can just focus on their apps and simple environment definitions.

What I’d whip my wallet out for is someone to just take care of a k8s cluster and keep the damn thing healthy. Even on cloud managed their a bit of a pita to manage if you are not a devops.

Can you give some examples of what you would want from this tool?

You mentioned something along the lines of deploying docker compose into kubernetes.

I find docker compose simple, and k8s quite complex. So if I can deploy a docker compose kind of project into it that would be nice.

And then on top of that it would handle or greatly assist with fault diagnosis, making sure the thing is highly available etc. There seems to be a lot of weird mistakes you can make with k8s which result in downtime of the app. If you have a full time dev ops person they can train and learn all those corner cases, but for a busy team that uses it and is doing other stuff it is too hard to stay on top of it. I have probably spent 8 hours in total seriously learning k8s! The rest is hacking.