There is a lot of terminology for sure. We've gone from "is docker ready for production usage?" to "Hey Bob, look at this, a service which isn't running in a co

There is a lot of terminology for sure. We've gone from "is docker ready for production usage?" to "Hey Bob, look at this, a service which isn't running in a container yet" in about 5 years. In order to work effectively within kubernetes you've got to understand docker, with all of its nomenclature (images, containers, volumes, layers etc). Then you've got the things kubernetes layers on top (pods, ingress, stateful sets, persistent volumes etc). You then probably layer Helm (adding tiller, deployments, charts, templates) or something else on top of that. We've still got the complexity from before that, remember when ansible, puppet and chef were all the rage? You're probably still using that to initially configure your bare metal. You still have to understand all of the quirks of your data store, except now instead of throwing everything in a huge SQL DB you have some things in Redis, MongoDB, Kafka and maybe some legacy stuff in that big DB in the corner. Let's not forget your CI stack in Jenkins, Travis or maybe codefresh which builds and runs your tests. That probably does some magic with docker too. Oh, and if anything goes wrong in any of that you'd better be well grounded in general unixy debugging (permissions, networking etc). It's certainly getting to the point that I feel no one person can be an expert in all of it, especially because when it all works you can more or less let it do its thing. When it breaks though it feels like playing Jenga.