K8s absolutely has a steep learning curve, but it feels like we always focus on the most complex setups and use cases so that we can admire the shiniest new fea

K8s absolutely has a steep learning curve, but it feels like we always focus on the most complex setups and use cases so that we can admire the shiniest new features. If you're going from "our app is running directly in tomcat in our on-prem data center" to "we want to move to a mirco-services architecture with a service mesh, canary deployments, multi-cluster observability, fault injection, automatic global failover, etc...", you're almost certainly going to have a bad time. I really like the concept of "innovation tokens" [0] here. Pick one or two big innovations at a time and don't add more until you're comfortable with what you have. Get your app running in docker first, and then get it running in a basic k8s setup first instead of leapfrogging to the more advanced stuff. Chances are if you didn't need a service mesh for your original non-k8s deployment, you probably don't need one for the v1.0 first pass of your k8s rollout. [0]https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology