Why should I use this instead of Cloud Foundry?
Not trying to bash, just curious.
Not trying to bash, just curious.
The community is absolutely amazing here. I have had pleasant conversations with everyone from day 1. The OpDemand folks were very welcoming to my suggestions and they really helped me get started in the early days. everything is done in the open. Not a single feature goes by without a fair trial or a discussion from the community.
Hacking on Deis, getting started and tuning it to your liking has always been there from the get-go. Cloud foundry... not so much.
Cloud Foundry provides the application deployment workflow, but they're missing a few core features, most notably application rollbacks and zero-downtime app migrations at the router level. There is also no scheduler tag support so you cannot control what node your apps will be scheduled to.
They use forks of heroku buildpacks, making them heroku-incompatible in some cases. Their java buildpack is specific to cloud foundry. Hello vendor lock-in.
In-place upgrades work beautifully. I've been dogfooding a running Deis cluster for about a month now, testing upgrade paths from version to version. Just stop the components, bump the platform version and boot them up again. Boom, v0.14.1 to v0.15.0. Cloud Foundry's upgrade path is to basically stand up a second production cluster, migrate your data, app slugs, cluster config and cut over DNS records to your new cluster.
If you have any more questions on Cloud Foundry vs. Deis, Gabriel or myself would be more than happy to discuss with you over IRC or email. My email is matthewf@opdemand.com
While I agree tag support would be cool, complaining about CF buildpack incompatibility is a bit disingenuous, no? I mean, you generally can use a Heroku build pack on CF, but if you have unique requirements, that's why there are CF-only buildpacks. The general reason is that some CF deploys don't have internet access and therefore need a completely offline cache of the binaries.
Secondly,
> they're missing a few core features, most notably application rollbacks and zero-downtime app migrations at the router level
I'm curious why you think this? For example:
http://blog.pivotal.io/cloud-foundry-pivotal/case-studies-2/...
Email me for a longer answer: gabriel@opdemand.com. ;)
http://www.activestate.com/blog/2014/09/cloud-foundry-diego-...
https://blog.openshift.com/openshift-v3-platform-combines-do...