Container technologies at Coinbase: Why Kubernetes is not part of our stack
&gt; We would need to build&#x2F;staff a full-time Compute team<p>This actually was a very real problem at my current job. The data pipeline was migrated to k8s and I was one of the engineers that worked to do that. Unfortunately, neither myself (nor the other data engineer) was a Kubernetes guy, so we kept running into dev-ops walls while also trying to build features and maintain the current codebase.<p>It was a nightmare. If you want k8s, you really do need people that <i>know</i> how to maintain it on a more or less full time schedule. Kubernetes is really not the magic bullet it&#x27;s billed to be.<p>&gt; Managed Kubernetes (EKS on AWS, GKE on Google) is very much in its infancy and doesn’t solve most of the challenges with owning&#x2F;operating Kubernetes (if anything it makes them more difficult at this time)<p>Oh man this hits home. EKS is an absolute shitshow and their upgrade schedule is (a) not reliable, and (b) incredibly opaque. Every time we did a k8s version bump, we&#x27;d stay up the entire night to make sure nothing broke. We&#x27;ve since migrated to cloud functions (on GCP; but AWS lambdas could also work) and it&#x27;s just been a breeze.<p>I also want to add that &quot;auto-scaling&quot; is one of the main reasons people are attracted to Kubernetes.. but in a real life scenario running like 2000 pods with an internal DNS, and a few redis clusters, and Elastic Search, and yadda yadda... it&#x27;s a complete pain in the butt to <i>actually</i> set up auto-scaling. Oh, also, the implementation of Kubernetes cron jobs is also complete garbage (spawning a new pod every job is insanely wasteful).