100% this. Pre-K8s I’ve done EC2 auto-scaling with ansible and packer, our own in-house healthcheck framework (https://github.com/hootsuite/health-checks-api ht

100% this. Pre-K8s I’ve done EC2 auto-scaling with ansible and packer, our own in-house healthcheck framework (https://github.com/hootsuite/health-checks-api https://github.com/hootsuite/health-checks-api), our own rolling deploys, our own in-house service discovery (https://medium.com/hootsuite-engineering/how-our-service-mesh-eased-migrating-from-mesos-to-kubernetes-19a1a7f6d853 https://medium.com/hootsuite-engineering/how-our-service-mes...), our own in-house udp logging to an ELK stack (https://github.com/hootsuite/udp-logger https://github.com/hootsuite/udp-logger), our own init scripts, etc. It was a lot more complexity for us to manage than K8s, far more bugs/issues, far less uniform across teams/services. We switched to mesos, then K8s, and K8s was the simplest by far. My new company also uses K8s, and it’s also overall easier to manage with fewer issues than any alternative I’ve used. I think if you’re a small org with just a few devs and one or a handful of services, sure, K8s is overkill. But for a decent sized dev org, it’s probably way better and significantly simpler than what you’d rollout without it.