Well, Dokku [1] is already a good solution to the heroku cost problem. All the power and convenience of heroku commands with the freedom and low cost of docker deployment. It has lets-encrypt ssl support too!
I want to see if I can use Kubernetes as a Dokku replacement (hopefully a more stable one), but I don't think Kubernetes has all the niceties Dokku has (automatic reverse proxying, Let's Encrypt support, etc).
Cloud Foundry has buildpacks too, but it's usually seen as a heavyweight solution -- the light footprint variant is 6 VMs, the standard variant is 20-something.
Disclosure: I work for Pivotal, we contribute a lot to Cloud Foundry. Red Hat is a competitor.
My own company has Pivotal Web Services[0], which gives a Heroku-like experience using Cloud Foundry. Pricing is per-megabyte[1], plus services. I expect we'll introduce a container service before long, because we like to dogfood our stuff with real production workloads.
For my side-projects, where I am cost-sensitive, I think the best solution would be a dedicated server with something like Dokku. It would just be nice if the "something" could be an industry standard.
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.
Maybe I should look into OpenShift instead, as that's more active?
If you are not sure, feel free to drop in and ask any and all questions: https://slack.deis.io/
The announcement of EOL came in July, and the announcement that Team Hephy would take over was almost one month to the day later, in August. I have a lot of faith in the Deis codebase and I'm on Team Hephy now.
We have yet to put out a fully e2e acceptance test passing and providence-verified signed, versioned release of our own, but we have and know of a number of production users that still use Deis in Production.
It definitely does not feel like a ghost town on the Deis slack. Questions get answered. Neither does OpenShift (it is definitely not deserted, and it does not seem to suffer from "abandoned k8s fork" syndrome, they do keep up with the release cadence, because they have to.)
I would go with the one that solves your problem better. I'm personally still recommending Deis, as I like the built-in support for Heroku buildpacks that OpenShift lacks. (Convox also has support for this, on ECS.) I'm not aware of any K8S-native Deis competitor (other than Hephy) at least for now.
Edit:
The really nice thing about working in Kubernetes is that you have the conformance suite[1]. You shouldn't worry about breaking something with the next Ubuntu update, because if Ubuntu update has broken Kubernetes in a way that will cause Deis to fail, then it will not be a Kubernetes-conformant distro anymore (and there is a large list[2] of K8S-conformant distros and platform to choose from, so you should pick a conformant one[3] instead.)
So, your question should be whether Deis will continue to work on Kubernetes distributions that are conformant, and with some minimal research, I think you should be able to say that with a high degree of certainty it will, regardless of ongoing vendor support from either side.
Then, you can ask whether your K8S distro is likely to remain conformant. (This should be a no-brainer.) Finally, is there anything that can break within Deis internally (not related to how it interacts with Kubernetes) that would mean you'd have to stop using it?
For me, the big reveal / final test will be, can we upgrade from Cedar stack to Heroku 16, which is on Team Hephy's planned roadmap for the future.
If that goes smoothly, then I'm not sure what else there is to worry about.
[1]: https://www.cncf.io/certification/software-conformance/
[2]: https://www.cncf.io/certification/software-conformance/#logo...
[3]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...
They also used to use soft-forked Heroku buildpack code. Almost all of the Cloud Foundry buildpacks have now been rewritten on top of a single shared library. The strength of Heroku's code was that each buildpack has a maintainer familiar with the relevant ecosystem. The weakness was that they were all different. Often forked from a previous one and then tinkered into submission.
https://www.suse.com/products/cloud-application-platform/ https://www.suse.com/communities/blog/take-look-suse-cloud-a...
I tried it recently with an internal app, and the experience was very similar to Heroku. cf push and my app was running.
Disclosure: I work for SUSE, we contribute to Cloud Foundry and the containers ecosystem. Pivotal is a competitor.
https://www.suse.com/communities/blog/introducing-stratos-ui...
The link to the UI blog post has turned up in our private chat channels :)
Putting a few labels on the containers you want to expose with your reverse proxy is all you need to do. Traefik continuously monitors docker to react to changes. Traefik handles load balancing and automatic certificate generation with ACME, too
You can set up your Kubernetes, Helm, Tiller, Runner, Prometheus by one click.
Dokku is basically a wrapper around Herokuish which is just a docker image with Heroku buildpacks pre-installed on them to build an image of your app to be dployed to docker instance...
Source: Am a maintainer of Dokku.