I did infrastructure work on OpenShift for the majority of last year, and I can tell you that my team's experience was absolutely horrendous. OpenShift, to me, suffers from "too early syndrome", and since it was building features on top of k8s before the underlying platform was mature, has ended up in a very weird state in relation to k8s.
Frankly, it was a supremely painful platform to work on. They obfuscated just enough of the k8s API to make it simultaneously completely unintuitive for less "orchestration minded" team members, yet severely underpowered for me and my fellow platform workers. It struck an unhappy medium for our team that no-one wanted or needed.
All my looks at OpenShift suggest that not enough has been peeled back to make it a useful platform-on-a-platform, but since they probably paved the way for certain features, those features have predominantly been implemented (and more tightly integrated) into k8s. RedHat is going to need to come up with a new value proposition for OpenShift for it to ever be a truly viable alternative to "raw" Kuberenetes, and given their buy-in to the technology, I'm not convinced they'll want to throw away the work they've done so far. Good money after bad, or something.
My team's experience is the exact opposite - we're very happy with it, especially because it _doesn't_ obscure the k8s API and is quickly rebased on top of upstream.
It's been great for us since we were productive from day one without having to worry about setting up Kubernetes or figuring out things like deployments and builds. Their documentation is great and the Ansible installer is very helpful. They have a lot of operational docs, which are invaluable (day two ops guide, among others).
Apart from the obvious PaaS features, it has a lot of small and seemingly minor improvements like "oc rsync --watch" (copy changed files to a container) or "oc rsh dc/foobar", proper auditing, and a lot of other small stuff that makes life easier.
Red Hat is one the main k8s contributors and is responsible for the RBAC implementation, among others.
You did not mention any particular pain points, but I'd love to hear about them.
Maybe. I'm skeptical of Red Hat. The openshift.com web site, which is definitely not geared toward engineers, doesn't give me any confidence that this is what I'm after.
Not that Google is better here, but I already know what GCP provides; something that wants to compete with GCP/GKE really needs to explain why they're a viable competitor.
(And to people who design these things: If you need to have a "Products" dropdown filled with unexplained product names, you're doing something wrong.)
I work for Pivotal, we directly compete with Red Hat.
Look: they're Red Hat, I mean c'mon now. If you don't think they have great engineers then I'd hate to hear what you think of the rest of us.
These websites are not usually intended for you or I. They're intended to get the interest of the cheque-signers. Enterprise software is a very particular world and it has its particular cadences and norms and approaches. Red Hat understands it well. So does Pivotal. That's why we see so much of each other at a number of places where folks are looking to adopt modern platforms.
We were talking about openshift.com, though. I didn't realize there were more than one site. Since you're going there:
- I didn't even know it was called "OpenShift Origin"!
- I don't understand what the differentiation is between the various things called "OpenShift", from having visited the Google links briefly.
- Third Google hit (https://www.redhat.com/en/technologies/cloud-computing/opens...) does not even mention Origin anywhere, but describes it as "a container application platform that brings Docker and Kubernetes to the enterprise". With that copy, you already lost me. That IBM-type business site that makes my skin crawl.
- The Github site actually introduces it as "Enterprise Kubernetes for Developers", which... I don't even know what that means! What does "Enterprise Kubernetes" even mean? The actual readme's introduction ("a distribution of Kubernetes optimized for continuous application development and multi-tenant deployment") does make sense, and the readme itself is fine. However, still no explanation of what "Origin" is compared to other things named "OpenShift".
- Openshift.org (5th link on Google) is good. That's exactly the kind of site I'd want to see as a developer/CTO. However, still no explanation of "Origin". From Openshift.org it seems like Origin is the only product.
- I go back to openshift.com and click on "Products" out of curiosity, and it's clear that there's a bunch of other OpenShifts. What are they? Why should I care? The site isn't inviting me to find out, so I leave.
Why are there are so many sites? Github is one thing, but so far we have three, and none of them really give a cohesive story.
I understand that the marketing department is targeting different people, but do they realize that people google this stuff, and will likely end up on the wrong site, with no signposts to the right thing? The fuzzy messaging leaves the impression that the company is messy and disorganized, and also pretty lost in a fog of enterprise buzzwords.
Anyway, in my original comment, what I was seeking was Kubernetes a cloud service. After sniffing around on openshift.com, I suspect the product I want is called OpenShift Online, but I'm not actually sure. Because there's also something called OpenShift Container Platform, which is also Kubernetes, but apparently in the cloud of your choice? Unfortunately, the site doesn't explain what the relationship is between this and Origin, and of course there is no pricing for Container Platform, probably because it has the label "ENTERPRISE" next to it. Figures.
There is, though; "Origin is the upstream community that powers OpenShift". Meaning Origin is the open source project upon which commercial products are built. Much like Moby is the open source project upon which Docker is built, for example.
I fixated on something else, which was my impression that you were downplaying their engineers and the ability of their engineers to communicate with fellow engineers.
We have a similar mix of CxO-focused and engineer-focused literature. So I guess I felt you were giving us a hard time too.
Edit: and I guess it figures that, since I work for a competing company, I'm primed with some background details on OpenShift.
Red Hat's marketing is definitely a mess (I say this as an enterprise Red Hat customer in the midst of an OpenShift roll-out), but their engineering is top-notch. Many pieces of k8s originated in OpenShift, and Red Hat is heavily involved in k8s development.
A lot of people come to websites looking for specific products. When you don’t offer an obvious path to what they’re looking for, they get frustrated. I know I do.
Frankly, it was a supremely painful platform to work on. They obfuscated just enough of the k8s API to make it simultaneously completely unintuitive for less "orchestration minded" team members, yet severely underpowered for me and my fellow platform workers. It struck an unhappy medium for our team that no-one wanted or needed.
All my looks at OpenShift suggest that not enough has been peeled back to make it a useful platform-on-a-platform, but since they probably paved the way for certain features, those features have predominantly been implemented (and more tightly integrated) into k8s. RedHat is going to need to come up with a new value proposition for OpenShift for it to ever be a truly viable alternative to "raw" Kuberenetes, and given their buy-in to the technology, I'm not convinced they'll want to throw away the work they've done so far. Good money after bad, or something.