Sometimes there's a perverse dynamic where you have to know a technology extremely well to use it simply, and if you can't invest time in understanding it at an expert level, you have to use it in a much more complicated way.<p>If you stay on the well-trodden path, using it exactly the way everybody else uses it, you get easy fixes to the problems you encounter. You google for a problem, and the conversations you find apply straightforwardly to your situation. You never have to ask your own questions, because somebody has asked them before, and the only time you have to consult the docs is to help you understand the answers on Stack Overflow. However, you have to take on the burden of implementing the same architecture as everybody else, even if it's more complex than you need. This is how my last company used Kubernetes. When I arrived, they had a functioning bog-standard Kubernetes deployment. None of the (very small) team of full-time employees understood it very well, but they were able to cargo-cult their way forward. It worked out okay. I lived in fear of the day I would have to do a deep dive into Kubernetes to solve a production outage, but it never came.<p>I think if we had had an expert in Kubernetes who understood the technology thoroughly, they might have been able to build a simpler solution that had fewer moving parts, fewer opportunities for failures and mistakes, while still meeting our needs. However, the downside of using a tool in a from-scratch expert way is that you have to take the same from-scratch approach to troubleshooting problems. The answers online won't apply to your setup. If you try to ask for help, people won't understand you. They might even tell you you're doing it wrong. If you tell them, "Module X is for Y, and we don't need Y. Our setup has been working fine without X for two years," they'll still say, "Your error must be because you're not using X." You'll be entirely on your own. That's how I imagine it would have been if somebody on our team invested the effort to become a Kubernetes expert and build exactly what we needed. If they left, we would have been left with a perfect bespoke solution, and we would have been screwed the first time something went wrong (or the first time our needs changed.) Again, that's not my expert opinion on Kubernetes, just what I imagine based on my experience with other complex technologies.<p>I think something similar to an "innovation token" is at work here. Gaining fundamental expertise with a technology and building a bespoke solution with it (making a cover song your own, in the article's analogy) is an investment of effort. Cargo-culting your way forward (playing the song just like someone else) allows you to spend that effort elsewhere, at least for a while.