Responding to the inlined kubectl command mentioned above: As an outsider, that command looks really easy to mess up. * shell interactions with quotes * d

Responding to the inlined kubectl command mentioned above: As an outsider, that command looks really easy to mess up. * shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name? Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs offer way more support to get it right. * var x = new List<Dictionary<CustomType,int?>>() This will light up warnings if you get anything wrong; You get: * go to definition of `CustomType` * autocomplete on classnames * highlighting on type mismatches * warnings about unused vars. * if you initialize the var, the IDE will try hard to not let you do it wrong So structurally, 1) in the code realm, for doing minor work we have really strong guarantees, 2) in deployment realm, even though it's likely going to hit customers harder, the guarantees are weaker. I think this is behind the feeling that the k8s system is not ready yet.