These are the things I want out of my cloud management layer.
The repeatable builds argument is the most interesting to me, in part because this is the same promise that java made in the 90s (write once run anywhere).
If you develop on linux and run on linux and youre in a deploy-as-source language, you may not care that much about repeatable builds.
If youre deploying C programs that rely on system libraries, things may get tricky if you cross flavors or versions of linux. But you can probably deploy static-linked executables more easily than setting up docker.
The dev experience for incremental builds on docker is really bad. If youve had a positive experience with this, write an article and Ill link to it here if you convince me.
Warning: the HN discussion on this article leads me to believe my kubernetes knowledge is stale. A lot has happened since summer 2016 when I played with it. If youre going to read this section, close one eye.
I still dont love the kube model. It seems like a many-headed monster in a use-case where clean, orthogonal primitives are called for. In particular, requiring a cluster & a container registry as a floor seems like a lot to ask. But the tools have come a long way in a year so try them yourself and draw your own conclusions.
Kube configs seem shitty and rigid to me but all configs are so thats not a valid criticism.
When I used kube in 2016 the cluster turnup support was bad; it seemed like you could use it managed in the G cloud but not anywhere else.
It also gave me a duct tape feeling or batteries not included like the critical pieces (docker support, DNS, load balancing) werent integrated into the original design.
I realize all of the above are bad feelings rather than arguments. Ive been reading the build releases and would be willing to try it again, but my takeaway from last time was too complicated and bad at testing.
6 months x 3 smart devs who understand the linux kernel. So like $600k.
Getting it running in a distributed fashion would take 3x that. (But distribution & scale arent the be-all and end-all; a lot of small teams want heroku workflow, are willing to host / manage it themselves, and dont need 100% uptime).