I appreciate the author's pragmatism. I might be biased because I seem to share some of the author's worldview. > One of the big points he made in that convers

I appreciate the author's pragmatism. I might be biased because I seem to share some of the author's worldview. > One of the big points he made in that conversation is that if you don’t figure out the manual process you won’t have a clear explanation of the steps involved and if you don’t understand the thing you are doing you are going to end up in a mess. You’ll may even end up in the situation of “I don’t want to touch it, I don’t know why it works”. Kubernetes is that to me and I have no compelling reason to demystify it. I don’t operate at immense scale with a massive team. Regardless of the deployment system and underpinnings you work with, someone needs to know how to deploy your application, it needs to be well understood somewhere. At the human scale. Documentation is a good way of making that information transmissible. It is not a solution for immense scale, it is a solution for the human that needs to implement it at scale. That really speaks to me. I have never understood Kubernetes; I have never worked on a team or project that employed > 100 developers at once, so it seemed unnecessary to me to read, say Kubernetes in Action (IIRC it's over 600 pages) when Ansible would do the trick. I'm not saying I'm a huge fan of Ansible but I have found it to work without a ton of knowledge, because it's fairly comprehensible. I would probably prefer some sort of deployment-via-source-code, actually, though I bet that could be relatively inflexible (after all, who is going to focus on code review and best practices for deployment source code when you have real feature development and customer-facing bugfixes to prioritize?) and is perhaps how things like Ansible came to exist in the first place.