I completely agree with your point. I've been investigating options for moving a SaaS application away from Heroku, over to a self-hosted PaaS stack (e.g. Kubernetes-based Deis). While I think I have a modest to solid understanding of Docker, Kubernetes, and so on, shit will hit the fan and I'll be the one to frantically dig through docs, logs and other stuff once it happens. I've toyed around with the modern DevOps stacks(tm), and while the out-of-the-box experience has mostly been really great, I'm certain the dollars we'd save are not worth the sweat. Once it's out of the box, it will break, it's only a matter of time. Someone will have to fix it.

I should mention it's a very small team and the option to split the DevOps work does not exist. I'm still evaluating GCE and friends, because the amount we pay for Heroku is ridiculous.

Edit: Also I feel like a need an AWS <-> English dictionary

Ehhh. This is an unpopular viewpoint, but to be frank: I've rolled up k8s at scale, and to be honest? I think you might as well just use ECS if you're going to already be into AWS. And it plugs into pretty much everything AWS does without having to either reinvent every wheel or having to build translation layers (or use ones you don't fully understand). Failing that, use EC2 and run singleton Docker containers on each instance (easy enough to do with a short cloud-init script). You already have resource segmentation. You shouldn't have enough headroom in your cluster as-is to not be using all of it (otherwise it's just deadweight loss).

The set of shops that actually benefit from k8s or the like are a rounding error and so many person-hours are burned building stuff like this that it hurts. Simplicity is better than complexity until your needs require complexity.

If you'd like to chat further, feel free to reach out - email's in my profile.

AWS in Plain English: https://www.expeditedssl.com/aws-in-plain-english