|
|
|
|
|
by shane_siebken
2961 days ago
|
|
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. |
|
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.