This blog post starts under a false premise. Kubernetes is not for app developers, it is the substrate on which applications, databases, and other workloads run

This blog post starts under a false premise. Kubernetes is not for app developers, it is the substrate on which applications, databases, and other workloads run. Just like you wouldn't want an application developer SSHing into machines in production (assuming you have ops people), you don't want them to use kubernetes, except kubernetes has done one better -- it's abstracted so well (especially with the introduction and widespread use of Custom Resource Definitions AKA CRDs) that you can let them write resource definitions, which are declarative representations of the resources they will need for their application, and run those. Coming from someone who gave a talk at Kubecon I'm very surprised to read something like this. Maybe I'm the one with the misunderstanding, but I'm going to try and refute the things this article said/is implying. 1. Kubernetes is complex This is kind of right, but it's also kind of not -- Kubernetes is essentially complex, given that it encourages write-once solutions to all the problems it faces. Here are the pieces that make a basic Kubernetes "cluster": - apiserver => you send commands to this to change/query cluster state - controller-manager => works to make your ensure that the cluster is in the state you want it to be (making workloads replicate/restart/etc) - scheduler => figures out where to put workloads - kubelet => runs containers -- one on each node that can do work - kube-proxy => maintains the routing infrastructure necessary to enable containers on any node to hit a container on another one. All of those pieces are needed -- the only concession I would make is that they could all be in the same daemon (one executable), but that's actually worse at scale, and harder to debug -- all of these services can produce a lot of logs. 2. Application developers can't use kubernetes as it is Application developers can use kubernetes as it is. Learning to write a kubernetes resource definition is not any harder than figuring out the conventions and configuration you have to write for Heroku, or AWS ElasticBeanstalk, or AWS ECS. In fact, I would argue that it's simpler. We've touched on another problem here -- the competitor for kubernetes is not SSH, it's not heroku -- it's tools like CloudFormation/ECS. I don't know if you've CloudFormation, but it's kind of a clusterfuck, hard to set up quite right, and the dynamic yaml approach they've taken is enough rope for one clever developer to hang you and your whole team with. Bold prediction, but I think AWS is going to abandon CloudFormation and ECS in favor of Kubernetes resources once it stabilizes. OK, let's say you disagreed with everything I've said up until this point -- at the very least, you can deploy tools like the following to your kubernetes cluster: https://gitkube.sh https://gitkube.sh => heroku workflow https://helm.sh https://helm.sh => cloud-formation/elastic-beanstalk workflow (with kubernetes primitives) And presto, you have a completely different interface to your cluster, WITHOUT changing anything fundamental underneath. 3. Developers who only focus on the application-level are the goal Why would you even want this? Not only is it basically impossible to hide the underlying infrastructure so well that the application developer doesn't have to know about it, it's arguably not even a good idea. Take session management -- if you want to handle it in the context of more than one frontend running at a time, you generally outsource that state to a cache like redis. An application developer who grew up in this imaginary world where app developers never touch infrastructure is not who I want solving this issue, assuming there isn't a qualified ops person. If you needed to optimize even further, app-local caches could be deployed, but this requires knowledge of "sticky sessions" -- this very much is a deployment/infrastructure specific question, again, that app-only developer is just about useless here. I'm no hiring manager but the desire to stay an "application" developer who only worries about that part of the stack when the "application" as a whole is so much more would be a red flag for me. Even if you were delivering a desktop application, the developer who worries about underlying OS-specific enhancements (for example knowing how to optimize the app for MacOS) is the one I want, the one I want to pay the big bucks for. 4. It's hard to deploy the usual app+backing store+caching+worker pool structure The author touches on this a little bit with the "maybe operators and helm charts solve this", and that's exactly what the operator pattern (Custom Resource Definitions, AKA CRDs, plus custom controllers) were meant to solve -- now you can actually give declarative specifications of what you want your Redis/Postgres/Celery/whatever cluster to look like, and `kubectl apply`, and the platform handles it. There's arguably no difference here between how you'd use this and a tool like heroku. Also, for the record you can trivially extend `kubectl`: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/ https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plug...