One can learn the developer side of K8's in a week or so enough to be deploying apps and setting up services and pods without the overhead of managing etcd and distributed clusters.
One can learn the developer side of K8's in a week or so enough to be deploying apps and setting up services and pods without the overhead of managing etcd and distributed clusters.
In an ideal world, you could purchase or rent commoditized resources (compute, storage, bandwidth) and have those resources deploy your application in a standardized way. K8s is so close to that out of the gate, that having to use cloud provider's expensive and proprietary offerings feels sub-optimal.
I agree that cloud offerings are the way to go for anyone without good reasons not to (eg compliance, lack of connectivity, or full control over upgrades). But a lot of the "I prefer on prem" attitude comes from realizing that having a black box of an ingress controller on my cluster isn't the end state of how apps get deployed
Setup = rep groups, internal services, etc? You need k8s-savvy ops people, or really good devs who like ops stuff.
They are called DevOps Engineers and it's a standard role these days.
And it doesn't matter whether they like it or not. In many organisations these days developers own their piece of work all the way through to production and are expected to provide an ops-like support for it.
OTOH if a service is available and would work for someone's use case, by all means, use the service. I've set up native k8s clusters just as exercises, and it's no picnic–and I didn't need to manage those clusters, later. Just doing build exercises alone was enough to scare me straight.
But people still use the cloud.