3 ms·

So... it's like a poorly explained PaaS which is: - An IDE - A platform for running containers - A set of productivity and collaboration tools

So... it's like a poorly explained PaaS which is: - An IDE - A platform for running containers - A set of productivity and collaboration tools - CI service - Deployment tools ...all in one? Really? I'm scratching my head over this one. I really respect the work RedHat do, but there's this idea of picking one thing and doing it well... but heck, I mean, you can also just do everything as well, and hope one bit or another sticks I guess. ? ...but why would you? How can you expect to offer all of that at any kind of acceptable level of quality? Why would I pick this up? It feels like if you do, you're basically going to play in some walled garden where the rules might change at any time, and you'll be out in the cold when they do.

jldugger 9y ago
Last I checked, OpenShift was comparable to Heroku.
- yebyen 9y ago
  Yes and no. Deis Workflow is like an open-source Heroku (even uses Heroku buildpacks.) OpenShift has its own build stacks and does not share as much in common with Heroku and Workflow. From a naïve user experience perspective, OpenShift is probably a bit more like Heroku. Workflow does not (yet) have service brokers or add-ons that provide sidecars like a MySQL database or a Redis server. OpenShift provides those things in a manner more similar to Heroku's add-ons. OpenShift also provides users with a point-and-click interface, but Deis Workflow expects you to use a command-line interface or bring your own dashboard (deisdash is a thing). Deis Workflow depends on Kubernetes, and OpenShift =~(subsumes/supplants) Kubernetes in a marginally incompatible way, but to my knowledge Heroku has no relationship at all with Kubernetes. At least if it does, it's very opaque about it. (I couldn't tell you either way because it is opaque.)
- jacques_chester 9y ago
  Not quite. OpenShift 3 is oriented around containers as the unit of deployment and operations. Heroku pioneered the buildpacks model. I believe OpenShift has a buildpack-like onramp now, I am not qualified to name it or describe it. Deis takes the Heroku buildpacks from upstream and so is more-or-less plug compatible with Heroku. Cloud Foundry does something similar, though with extra wrapping to allow it to work smoothly in disconnected environments. Some of those buildpacks are being rewritten, but I expect they'd be compatible with Deis too. Disclosure: I work on Cloud Foundry for Pivotal. I've been on CF Buildpacks twice.
sbose78 9y ago
Almost all the internals are matured/stable upstream projects which have been around for a while. Openshift.IO makes all them work as a SaaS for production use.
oso2k 9y ago
Full Disclosure: I'm a Red Hat Consultant focused on OpenShift. All of our work is open on github under the OpenShift Origin project, Kubernetes, and other projects. We push most of changes upstream. Doing containers at a scale of 10,000+ running containers would be unimaginably hard without something like OpenShift. Clusters of 1,000s of nodes, Security, RBAC throughout our supported tools, optional SCM (git via GOGS), optional integrated local Docker Registry, optional CI/CD (Jenkins), optional build/artifact repo (Nexus), optional basic metrics (Hawkular, Heapster, Cassandra), optional monitoring (CloudForms, Cockpit), optional EFK logging stack, (Elasticsearch, FluentD, Kibana), horizontal autoscaling, support for NFS, NetApp, OpenStack, RHEV, KVM, VMware, AWS, GCE, Azure, Ceph, GlusterFS, BIG-IP F5, iSCSI, FibreChannel, dynamic node provisioning, dynamic storage provisioning, OAuth2 authentication and app integration, LDAP authentication, SAML2 authentication, Okta, auto SDN creation, SDN segregation, application load balancing, multiple encryption flow options, HTTP/2 support, internally secured communications, Ansible integration. For a solution so encompassing, you need something that marks the way. Most of our customers exchange several parts for what they have or what they want. And we do all of this with Quality as we develop in the open & commit to upstream projects. We spend $100Ks (probably more) on R&D and testing every release (every 3-4 months). The benefits, again, are usually committed upstream. You have Red Hat's award winning Customer Support. I'll personally vouch for our OpenShift Customer Support Teams. Absolutely amazingly talented and insightful engineers from all over the globe. One of our biggest customer concerns is in integrating customers' code to run on the Platform, aka, the Last Mile of Integration. IMO, OpenShift.io is intended to reduce that barrier. We support just about all the popular languages, frameworks, and platforms. We have examples & templates for Perl, PHP, Python, Ruby, nodejs, Java (Spring Boot, JBoss, xPaaS, FUSE), and even .Net Core, MySQL, PostgreSQL, MongoDB, CouchDB. Figuring out how to integrate legacy CI/CD, monitoring, logging, IDEs, etc. with OpenShift takes the most time. In choosing OpenShift.io, in return, you get an environment that is built from the get-go to work together.

jldugger 9y ago

Last I checked, OpenShift was comparable to Heroku.

yebyen 9y ago
Yes and no. Deis Workflow is like an open-source Heroku (even uses Heroku buildpacks.) OpenShift has its own build stacks and does not share as much in common with Heroku and Workflow. From a naïve user experience perspective, OpenShift is probably a bit more like Heroku. Workflow does not (yet) have service brokers or add-ons that provide sidecars like a MySQL database or a Redis server. OpenShift provides those things in a manner more similar to Heroku's add-ons. OpenShift also provides users with a point-and-click interface, but Deis Workflow expects you to use a command-line interface or bring your own dashboard (deisdash is a thing). Deis Workflow depends on Kubernetes, and OpenShift =~(subsumes/supplants) Kubernetes in a marginally incompatible way, but to my knowledge Heroku has no relationship at all with Kubernetes. At least if it does, it's very opaque about it. (I couldn't tell you either way because it is opaque.)
jacques_chester 9y ago
Not quite. OpenShift 3 is oriented around containers as the unit of deployment and operations. Heroku pioneered the buildpacks model. I believe OpenShift has a buildpack-like onramp now, I am not qualified to name it or describe it. Deis takes the Heroku buildpacks from upstream and so is more-or-less plug compatible with Heroku. Cloud Foundry does something similar, though with extra wrapping to allow it to work smoothly in disconnected environments. Some of those buildpacks are being rewritten, but I expect they'd be compatible with Deis too. Disclosure: I work on Cloud Foundry for Pivotal. I've been on CF Buildpacks twice.

sbose78 9y ago

Almost all the internals are matured/stable upstream projects which have been around for a while. Openshift.IO makes all them work as a SaaS for production use.

oso2k 9y ago

Full Disclosure: I'm a Red Hat Consultant focused on OpenShift. All of our work is open on github under the OpenShift Origin project, Kubernetes, and other projects. We push most of changes upstream. Doing containers at a scale of 10,000+ running containers would be unimaginably hard without something like OpenShift. Clusters of 1,000s of nodes, Security, RBAC throughout our supported tools, optional SCM (git via GOGS), optional integrated local Docker Registry, optional CI/CD (Jenkins), optional build/artifact repo (Nexus), optional basic metrics (Hawkular, Heapster, Cassandra), optional monitoring (CloudForms, Cockpit), optional EFK logging stack, (Elasticsearch, FluentD, Kibana), horizontal autoscaling, support for NFS, NetApp, OpenStack, RHEV, KVM, VMware, AWS, GCE, Azure, Ceph, GlusterFS, BIG-IP F5, iSCSI, FibreChannel, dynamic node provisioning, dynamic storage provisioning, OAuth2 authentication and app integration, LDAP authentication, SAML2 authentication, Okta, auto SDN creation, SDN segregation, application load balancing, multiple encryption flow options, HTTP/2 support, internally secured communications, Ansible integration. For a solution so encompassing, you need something that marks the way. Most of our customers exchange several parts for what they have or what they want. And we do all of this with Quality as we develop in the open & commit to upstream projects. We spend $100Ks (probably more) on R&D and testing every release (every 3-4 months). The benefits, again, are usually committed upstream. You have Red Hat's award winning Customer Support. I'll personally vouch for our OpenShift Customer Support Teams. Absolutely amazingly talented and insightful engineers from all over the globe. One of our biggest customer concerns is in integrating customers' code to run on the Platform, aka, the Last Mile of Integration. IMO, OpenShift.io is intended to reduce that barrier. We support just about all the popular languages, frameworks, and platforms. We have examples & templates for Perl, PHP, Python, Ruby, nodejs, Java (Spring Boot, JBoss, xPaaS, FUSE), and even .Net Core, MySQL, PostgreSQL, MongoDB, CouchDB. Figuring out how to integrate legacy CI/CD, monitoring, logging, IDEs, etc. with OpenShift takes the most time. In choosing OpenShift.io, in return, you get an environment that is built from the get-go to work together.