Live data from Hacker News

Red Hat releases new OpenShift CLI developer tool

odo.dev

21–30 of 52 posts

Re: Red Hat releases new OpenShift CLI developer tool

#21
If you're confused about what OpenShift is, we have coloring books and O'Reilly Books [0][1][2][3][4][5].

:D

[0] https://raw.githubusercontent.com/fedoradesign/coloringbook-...

[1] https://docs.fedoraproject.org/en-US/fedora-silverblue/_atta...

[2] https://www.openshift.com/resources/ebooks/openshift-for-dev...

[3] https://www.openshift.com/learn/resources/ebooks

[4] https://www.openshift.com/resources/ebooks/deploying-to-open...

[5] https://www.openshift.com/resources/ebooks/devops-with-opens...

Re: Red Hat releases new OpenShift CLI developer tool

#22
post #9

Earlier quoted context omitted.

I had to deal with it past 2 years - it is extremely bloated, not very well thought out and anything that needs decently performing storage is screwed over by GlusterFS and now I guess Ceph. All in all you really want to carefully analyze which apps you want to put on it and how much benefit you are really getting out of it - because it isn't free in any sense of the word - licensing, maintenance, operations - you ar…

I want to get into OpenShift/OKD, but the distributed storage systems are quite frightening. There are plenty nightmare stories related to GlusterFS performance. However, strange as it sounds, I'm looking to deploy a cluster on a single node, primarily for the Kubernetes API & ecosystem (so many tooling options). What is your opinion on running K8s this way, and having only local RAID storage?

This sounds like you want https://k3s.io, a kubernetes distribution specially made for single node and probably much simpler.

Re: Red Hat releases new OpenShift CLI developer tool

#24

Prediction: It's only a matter of time they come up with a monitoring suite named ODOMETER !

Hahaha. I don't think so. We have a built-in monitoring stack of sorts based on Prometheus and Grafana. There's lots of other partners that do monitoring well too.

Re: Red Hat releases new OpenShift CLI developer tool

#26
post #13

Earlier quoted context omitted.

Disclaimer: I work for Red Hat Consulting where my day job is 100% OpenShift. Storage isn't easy on OpenShift unless you're in one of the public clouds. Even then, there's caveats based on (mis-)use cases and what nots [0]. But on complexity, I think companies and developers do it to themselves by getting excited about 12 Factor Apps, Microservices, and Event Driven Architectures and not understanding what that all m…

> OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is…

> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools

> True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles

Ignoring OpenShift, I don't think the comparison is quite that simple because it's leaving out all of the drawbacks from that traditional approach. Instead of writing a few lines of YAML you have to wrangle time and support from central IT, debugging is often a multi-party finger-pointing exercise with access limitations, and because you're talking about separate services and usually hardware changes and updates are hard because they need to be coordinated across multiple applications and teams.

That's not saying that there aren't legitimate areas for concern but I've seen fairly large amounts of developer time and downtime go into working around the limitations of that model (“ isn't compliant with this 15 year old RFC so we need to distribute forks of these 15 common tools for years until we can replace those $$$ appliances”).

Re: Red Hat releases new OpenShift CLI developer tool

#28
post #26

Earlier quoted context omitted.

> OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is…

> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools > True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that…

I have thought a lot about this - I have and do work with a ton of apps across number of clients. The stated benefits of K8s/OpenShift are negated by the complexity that it brings for most of those apps - especially when they don't need or use any of the sophisticated features of K8S.

If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to setup Jenkins/Ansible/Tower based self service workflow for automating deployment and other things. Most enterprise apps do not need autoscaling, or weird unsupported OSes and libraries - JVM and CLR solved that problem long time ago. If you did it right horizontal scaling any app server should be a piece of cake if and when that one time you actually need it.

If you do need specific OS versions/libs - just use plain old docker - that's much less complicated and at least serves a purpose.

The point I am trying to make is - very few classes of apps can benefit from the added complexity of K8S and you should carefully evaluate if your app can benefit from K8S specific features and your Developers/Ops team are ready to deal with the complexity they are signing up for.

Re: Red Hat releases new OpenShift CLI developer tool

#29

Is Openshift an extremely wellfunded solution seeking a problem?

It's a well-funded solution to a well-funded problem.

Producing platforms for enterprise customers is truly, genuinely difficult. There is enormous variation and complexity between and within customers, which cannot be dismissed easily.

Disclosure: I work for VMware, a direct competitor in this space.

Re: Red Hat releases new OpenShift CLI developer tool

#30
post #26

Earlier quoted context omitted.

> > OpenShift & Kubernetes is just ELBs, App Routers, scheduling, monitoring, and logging systems, some orchestration tools > True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that…

I have thought a lot about this - I have and do work with a ton of apps across number of clients. The stated benefits of K8s/OpenShift are negated by the complexity that it brings for most of those apps - especially when they don't need or use any of the sophisticated features of K8S. If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to set…

Your experience is rather unlike mine — especially the belief that central IT departments are advanced devops practitioners.

Similarly, you're talking about a significant amount of work maintaining bespoke infrastructure duplicating what systems like Kubernetes, OpenShift, Nomad, etc. do but taking on the responsibility for integrating and supporting all of those disparate parts yourself, not to mention getting the policy, security, and operational go-ahead to do so.

“Easy peasy” does not match my experience with that approach but I'm glad it's working well for you.

Post reply on HN