A simple DIY Heroku replacement to keep your hosting costs down

Mine takes 30 seconds for a sizable rails app

It's easy enough to set that up (though it's not the recommended use case) using kubeadm.

I use Deis on a single server. It works great.

There are a few things you need to be aware of, but the tl;dr is that it works great for us. We'd be using it more, except that our org hasn't adopted containers in any meaningful way yet, and Deis is large and complicated, and a little too much for them to bite off and swallow all at once. They want to do a pilot on ECS so that we can say we're using more AWS services (yay lock-in, we love vendor lock-in.)

So, those things you need to be aware of:

#1 - In the default mode, Minio is used instead of a real Object Storage backend like S3 or Swift, and Minio is configured to keep all objects in RAM by default. Use S3 instead. This is an option to configure in values.yaml.

#2 - builder really needs to be on an SSD, but if you're not backing your Kube node with SSD, you can at least prevent a lot of builder crashes by making sure there isn't much swap to fill and bog down the disk with swapped pages. This may be counter-intuitive (don't things crash when they run out of RAM? Isn't that why you have swap...) until you realize that Builder has to respond to health checks by default once per second. So if the node that builder runs on is getting even remotely bogged down by swappiness and lots of swappy pages, it will be killed and restarted, which takes some time and is noticeable and annoying.

#3 - The remaining cloud services that Deis can optionally depend on IMHO are take-or-leave, depending on your cloud provider. Deis can do everything in-cluster. I actually use this configuration with Minikube and Deis, and it works great. I let Deis spin up its Postgres database on-cluster and restore from S3 WAL backups each day, it just works.

I'd be using Deis more heavily, except that my app development has a production database attached. (Our infosec department is leary about letting me put backups of sensitive data into S3. So we really have to use RDS for our app, even though Deis is creating a Postgres database that nothing else is stopping you from using with your app. It's for Deis controller operation though.)

#4 - This one may be a dealbreaker if your company is very serious, Deis is now "End-of-Life." This means that Microsoft has committed to provide break fixes for Deis until March only, and by middle of next year, any break fixes will have to come from the community. There is AFAIK nowhere to buy Deis support, although there is a new group that has formed to commit to support Deis into the future, it's not clear what form that support will take, or whether you'll be able to pay money for an SLA, or anything like that. It is open-source.

This may be exactly what you'd prefer, or it may be a deal breaker. I like Open Source, but my group likes support.

I do not work for Deis or any other cloud PaaS provider, although I have evaluated a lot of them including OpenShift (and I consider Deis to be technologically superior in some ways to OpenShift.) Because of my ECS requirement, I'm looking at Convox now. If you have to use ECS, so far I would definitely recommend Convox. If you're like the rest of the world and using K8S, I can't think of any really good reason not to recommend Deis.

> All with near zero effort from a developer perspective

For a very small subset of developers.

The last time I was tethered to a Heroku installation, I spend 60% of my time coding, and 40% of my time working around Heroku's shortcomings.

It doesn't matter how many times you reply to people on HN stating that their position is "provably false," that doesn't make it true.

My last job we were 100% hosted on Heroku and coming from managing hundreds of EC2 instances and databases via autoscaling, CF, Puppet and home-grown scripts, it was a dream to use Heroku. We simply didn't need any operations staff to manage infrastructure, maybe a few hours a week for 1 developer out of 11 to adjust or verify a few things.

Need a bigger database? Just a few Heroku CLI commands. Bigger web servers? 2 clicks. Want a test database to run queries against? 1 Heroku CLI command. Want to test a branch of your code against the staging database? Automatically done via GitHub PRs, with DNS setup too.

We had 0 downtime in a year due to actual Heroku issues, developers could push code easily (git push), databases were backed up automatically, servers auto-scaled, etc.

I was genuinely amazed at how well it all worked. The amount of operations work was easily 10x less than if we had to run our own infrastructure on AWS due to not just the hosting, but the tooling. Deployment, rollbacks, slave database setup, configuration management, access control, log aggregation, 3rd party integrations and more.

Heroku does have some drawbacks, request queuing is one of them, mostly due to lack of clear docs and information. Even with its flaws it still saves a massive amount of time and money. For nearly all startups to medium sized companies I'd highly recommend using Heroku.