I'm not familiar with the space so my question might not be that relevant - where does OpenShift fit in all of this (I still struggle to differentiate it from Kubernetes) and is there any merit to IBM trying to sell it so hard?
1. ships a built-in Ingress controller that has smarts like blocking subdomain/path hijacking across namespaces. Someone's dev namespace can't start adding its Pods to a production API's ingress path
2. the oc cli has first class support for switching namespaces without bash aliases
3. RBAC logic is implemented such that as a unprivileged user you can list only the namespaces you have access to with `kubectl get ns` vs "not allowed to list all namespaces" error.
4. first class representation of an "image stream" which given a container location will cache it locally, emit events like "do a rolling deployment when this changes" and a few other very simple but logical helpers
Plus all the other top-level features like Operators and over the air updates. I think seeing some very specific wins can help folks understand that the little things matter just as much as the big ones.
disclosure: work at Red Hat
Generally OpenShift heavily targets enterprises as "All-in-One" package. Some of that works, some doesn't, but honestly it's often more a case of the IT dept that manages the install ;)
Except installing OpenShift. That's horrific. Someone should repent for the install process, seriously.
Makes for higher possibility that $DAYJOB upgrades to OpenShift 4.x, but then, we would rather get rid of our (intra-group) provider and their openshift environments...
If your problem is "I have a BigCo with my own infra running RHEL" then it's almost definitely what you want. It follows the old saying of "nobody ever got fired for buying IBM." It gives your boss a vendor to yell at when things go wrong and its add-ons can provide an onramp for enterprise-type ops and devs who are still unfamiliar with CI/CD and containers.
Where it's not very good is if you're not a BigCo. If your org has one or more of the following characteristics consider other distros / managed cloud hosting first: a nimble ops team, existing cloud buy-in, a limited budget, a heavy "dev-opsy" culture (i.e. existing CI/CD/container processes), a desire to avoid vendor lock in, or less conservative management.
Here's what we do:
- We don't use "develop on OpenShift" features like Eclipse Che or on-demand Jenkins nodes to build a project
- We don't use OpenShift-specific resources if there's _any_ alternative in the vanilla kubernetes resource definitions (e.g., use Ingress instead of Route)
- Use outside CI/CD to handle building and packaging of the applications, then deploy them with Helm like any other Kubernetes cluster
- Use the OCP console like a crutch of last resort, preferring `kubectl` whenever possible
All of this helps avoid vendor lock-in as much as possible while still taking advantage of the secure-by-default approach to a kubernetes cluster.
Talking with Red Hat engineers, it sounds like the OpenShift-specific things are contributed upstream and, while they may not become available by exactly that name and syntax, essentially the same functionality does come into vanilla Kubernetes. Routes inspired Ingress resources, for instance. The official stance is for OpenShift users to prefer the vanilla resources because the OpenShift-specific ones are intended to be shims.
(not a Red Hat employee, just work for a company that is a customer)
OpenShift in general I don't think can be compared here, because most of the time OpenShift isn't a cloud product. There is OpenShift online, which I would love to see improved, but it's a minority of OpenShift uses. The pricing there isn't direct apples-to-apples either, since OpenShift adds a lot of value on top of "raw k8s" (there's really no such thing as "raw k8s" since k8s is a platform for platforms, and every cloud vendor adds stuff to it, but it's a useful simplification for comparison). OpenShift adds some non-trivial features to Kubernetes and they aren't just plucked from existing projects and bundled. Some major K8s features started out as OpenShift features and got merged upstream (Ingress, Deployments, etc). Red Hat innovates and improves the distribution rather than just repackaging it and slapping on a support contract. Red Hat also tests and certifies other products so you have confidence that they'll work together, which is important for decision makers that don't have the technical depth to evaluate everything themselves.
> is there any merit to IBM trying to sell it so hard?
Red Hat is trying to sell it hard, and technically Red Hat is a subsidiary of IBM, so what you say is not technically wrong. However, it's not really accurate either. People that work for "IBM" don't really care much about OpenShift, people that work for "Red Hat" do. It's an amazing product and is getting better every day, and we see it as a major contender in the Kubernetes and PaaS space. Internally we don't think of ourselves as "IBM." The two companies are quite separate and are being kept that way. Over time we will cross-polinate more, but that's a ways down the road IMHO.
If we `s/IBM/Red Hat` tho, I probably shouldn't answer regarding if there's merit to selling it. I do, but then I wouldn't be working on it if I didn't think that. I am not a fan of our pricing model, and hope that changes, but nobody in pricing cares what I think :-)
If you are an enterprise customer, I think OpenShift is a great buy. If you're a startup, it probably isn't (at least not yet. I'm hoping to change that in the future).