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?
A few cool specific things that OpenShift does that others don't:
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.
Openshift wraps around Kubernetes, with some of their own special offering stuff on it. Generally, plain K8s is a building block - RedHat made Openshift with a bunch of opinionated choices, geared towards enterprise deployments, some of them migrating later to Kubernetes itself (OpenShift's Route inspired K8s' Ingress), some OpenShift cribs from K8s (Istio becoming part of OpenShift by default in OS 4).
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.
I have yet to touch OpenShift 4 - every environment that used OpenShift that I worked with professionally except for some testing runs was air-gapped to some extent from internet, something that is not supported on OpenShift 4, and which was treated as a crucial requirement by the customer deploying OpenShift.
Oh, that's a good news. Just this friday when I first looked into OpenShift install, it looked like it wasn't even in the plans, so I might have hit older docs than I intended.
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...
It's the expensive k8s distribution for enterprises with large IT budgets. It adds enterprise-focused add-ons and is very opinionated. Its primary target is people who have a large existing IT staff dedicated to running on-prem / self-hosted, but lacks the expertise to run a "community supported" k8s distribution on their own, and maybe has no existing CI/CD workflows yet.
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.
I work for a company that recently reconsidered our stance on OpenShift. Long story short, we looked at vanilla k8s rather fondly because of nearly all of the counter-points. The factor that brought us back to OpenShift was the secure-by-default aspect and that some of the training wheels (OCP console) couldn't be replaced by vanilla in a secure way.
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)
I don't feel like any of the responses really answered your question well, so I'll take a stab. Up front disclaimer tho: I work for Red Hat and work on OpenShift nearly every day.
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).
OpenShift is Kubernetes, just like RHEL is a Linux distribution with support for enterprises. OpenShift makes an opinionated choice about what they bundle (distribute) with vanilla Kubernetes. For example, Istio was chosen as the service mesh distributed with OpenShift 4.
I agree with you here, but do think it's worth pointing out that 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.
