One pro is less overhead--I think all of the major options for an autoscaling Kubernetes cluster require at least one node that's always on. Meadowrun uses AWS

One pro is less overhead--I think all of the major options for an autoscaling Kubernetes cluster require at least one node that's always on. Meadowrun uses AWS Lambda/Azure Functions to manage instances, so it gets a lot closer to truly scaling down to zero. Another pro is if your workflows aren't already container-based, not running on Kubernetes means we can build your containers for you on Meadowrun so you don't need to e.g. install Docker locally to get your libraries/code running on Meadowrun (it's hard to build containers in Kubernetes itself). I mentioned this in another comment, but this also means we can e.g. use AWS Lambda as the compute layer, or if you have software that's hard to containerize, you can even use a custom AMI. (Both of these are features on the roadmap, so this is a bit theoretical at this point.) The biggest con is probably that a lot of people already use Kubernetes, especially if they have an on-prem/hybrid deployment, or maybe if they have services with e.g. a load balancer that interact with their ad-hoc/batch jobs. We are planning on adding the ability for Meadowrun to target Kubernetes as well, so Kubernetes takes care of the resource scheduling, but you still get the benefits of Meadowrun--a really simple API for running ad-hoc/batch jobs.