One of the lead developers here - this is a ground up rewrite. In brief, we felt that the Kubernetes process (pods and the way containers were grouped) model "

One of the lead developers here - this is a ground up rewrite. In brief, we felt that the Kubernetes process (pods and the way containers were grouped) model "felt right" - it was the right fundamental bedrock concept for running software processes in the cloud. Realizing that, it was obvious that we wanted to be built in a way that benefited from the work we've contributed to Kubernetes, so we decided to rearchitecture on top of Kubernetes as micro service components. There have been a lot of productive discussions about Kubernetes being the "kernel of a cloud OS", and we wanted to bring developer experience / build / hands-off deployment flow pieces on top of that. Combined with supporting Docker images natively, the changes were sufficient to justify a rewrite (as much as we all wanted to avoid that). Also, we had some pain points around distributing and packaging large Ruby apps into random environments, and so a switch to Go meant we could simplify the model of deploying the system components (clients, masters, node agents) onto systems. The CLI client shares a lot of code with the Kubernetes client, and having that in Go allowed us to deal less with the vagaries of deploying Ruby onto Windows (for Java developers). And yes, I do realize that we've hit every single HN hot button thread in that list.