Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.

Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works.

There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing.

I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.

> I don't think Heroku or Otto are designed for big projects anyways.

If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.

I think the truth underlying that observation is that scaling is always hard. It's relatively easy to pick some defaults that work to get 99% of projects off the ground when they are small, but once you approach real scale inevitably hard decisions need to be made, and those decisions will depend on seemingly minute details of your service's workload. Therefore, tools like Kubernetes necessarily have a threshold of expertise required to use them effectively. I think all of these things are all trending towards more scalable and easier to use, but fundamentally there will always be a tension between those two goals.

A Heroku-like PaaS layer that serves as a manager for—but crucially, doesn't attempt to abstract away—a set of IaaS components would be interesting. Sort of a convention-over-configuration CLI tool for interacting with some CloudFormation-like API.

The "non-abstraction" part doesn't seem to be in any cloud provider's interest to sell, though; even with AWS, when you allocate a database, it doesn't result in a new EC2 instance for the DB being dropped into your bag of instances, such that you just get charged instance fees for the instance. Instead, it all gets packaged up so that you can be charged higher, separate, value-based database fees. It's a bit ridiculous.

What works for me is

    cf scale my-app-name 4

Or 10, or 100, or however many copies I need.

As opposed to throwing money at a person to solve the problem?