> If you’re arguing with a k8s purist, you’ll never convince them. I feel like the whole article very much sounded like constructing a strawman and arguing aga

> If you’re arguing with a k8s purist, you’ll never convince them. I feel like the whole article very much sounded like constructing a strawman and arguing against that. The way I see it, there can be advantages and disadvantages to either approach. If you really find a good use case for serverless, then try it out, summarize the good and the bad and go from there. Maybe it's a good fit for the problem but not for the team, or vice versa. Maybe it's neither. Or maybe it works and then you can implement it more. Or maybe you need to value consistency over an otherwise optimal solution so you just stick with EC2. Most of the deployments I've seen don't really need serverless, nor do they need Kubernetes. More often than not, Docker Swarm is more than enough from a utilitarian perspective and often something like Docker/Compose with some light Ansible server configuration is also enough. Kubernetes seems more like the right solution when you have strong familiarity and organizational support for it, much like with orgs that try to run as much of their infra as possible on a specific Linux distro. It's good when you can pick tech that's suited for the job (that you have now and in the near future, vs the scale you might need to be at in N years), the problems seem to start when multiple options that are good enough meet strong opinions. I will admit that I quite do like containers for packaging and running software, especially since they're the opposite of vendor lock (OCI).