Live data from Hacker News

Red Hat is pretty good at being Red Hat

redmonk.com

41–50 of 81 posts

Re: Red Hat is pretty good at being Red Hat

#41
post #7
post #5

OpenShift is a fork of Kubernetes. Case in point. OpenShift has functionality called a Route. That isn't in Kubernetes. Kubernetes of course went and added something similar called ingress. This means that anytime Kubernetes does a release that RedHat has to manage merging all those changes in with their local changes that aren't part of their project. This is exactly the same sort of thing that RedHat does with thei…

My understanding is that OpenShift is more of a superset of k8s vs. a fork. I don't think the situation is going to be as bad as you are implying.

[Full disclosure: I work for Red Hat as an OpenShift Consultant]

The truth is a bit more nuanced as Kubernetes and OpenShift are actually made up of dozens of projects and integrations. Our company contributes to (as upstreams) in support of our OpenShift Enterprise offering: Kubernetes, Linux kernel, HAProxy, Jenkins, Hawkular, Heapster, Cassandra, Elasticsearch, FluentD, Kibana, Jenkins, JBoss, Tomcat, Apache, Ansible, Go-lang, and probably many more. We do almost all of our work completely in the open (our docs, container images, templates, examples, blogs) via github and trello. In fact, you can run just about the same OpenShift (officially called OpenShift Container Platform (OCP or OSCP) or OpenShift Enterprise (OSE)) we sell by using our upstream project for it, OpenShift Origin [0][1]. If that looks complicated, you can try minishift [2][3] to start which also has an upstream Kubernetes project in minikube [4].

In terms of superset vs. fork: it's not quite a superset because almost everything we commit to OpenShift gets committed to Kubernetes and/or vicea versa. You can almost always say if it works in OpenShift, it works in Kubernetes; if it works in Kubernetes, it works in OpenShift.

It's not really a fork either (as we say often "Best idea wins!") and so our people (including management!) try to make sure we are adding value to Kubernetes so that our customers & the community can then extract that value. OpenShift/Kubernetes metrics is one place that affects me & my customers that we're following the community's lead on that and implementing new developments in OpenShift as Tech Previews when appropriate. Our code is not diverging from Kubernetes as much as you might think in supporting some of the "enterprise" features we've added.

So, I would say OpenShift is a Distro of Kubernetes in the same ways RHEL, SuSE, et. al., are GNU/Linux Distros. You might say Kubernetes provides the "kernel" for a modern Data Center (compute resource scheduling and management, internal/external data structures and interfaces to use such compute resources). OpenShift is intended to help provide everything else you expect your data center to do for you or to support your Application Development in Java, .Net, node.js, Ruby, Python, PHP, Perl, etc (UI & CLI management interfaces, simplified build and deployment processes (S2I), Jenkins integration, external logging integration, external monitoring integration, sample 12 Factor Applications, etc.). We partner with companies when they want help bringing on their storage systems, frameworks, databases, applications, etc., just like you'd expect when companies provide drivers for their databases, hardware, or storage systems for OS kernels.

[0] https://www.openshift.org/

[1] https://github.com/openshift/origin

[2] https://docs.openshift.org/latest/minishift/getting-started/...

[3] https://github.com/minishift/minishift

[4] https://kubernetes.io/docs/tasks/tools/install-minikube/

Re: Red Hat is pretty good at being Red Hat

#42
post #29

My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowled…

That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.

This is not how paid software development works (beyond maybe stealth mode/no customers start-ups- if you have no money then you do what you have to). If you have a going business, the trade-off is totally in favor of paying someone not at your company to do this sort of thing.

All up, even a new grad (= the cheapest you will find) in $NotSeattleOrSVButStillUS costs your company about one hundred fifty thousand dollars a year (more in SV or Seattle). You could have one of them spend several months coming up to speed on how to fix weird device driver issues necessary to get the latest kernel patches to run on your DB server, which costs you minimum 50k and gives you tremendous risk (what happens if a necessary security patch comes out while she is on vacation? If you train two people that's twice the costs.) Or you pay someone else to worry about that. Red Hat will charge you 2k for patches for a year for a standard server and if it doesn't work, will fix it.

If writing OS network stacks are a part of your company's core mission, go ahead and do it. If the one sentence description of where your companies money comes from doesn't mention anything in kernel land, having programmers spin up on that is a waste of their time and your money. You cut RH a check and get your programmers to write you something that does bring in money, because every minute they spend porting in patches is a minute they aren't earning you money.

As a side note, if your business plans for your developers to be working on a weekend you work for a terrible business and all the employees should leave and go to a place where they aren't exploited.

Re: Red Hat is pretty good at being Red Hat

#43

My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowled…

Thanks for this. Makes sure such feedback gets back to your TSM, SDM, PM, etc. Email, CSat, or otherwise. We at Red Hat REALLY, REALLY appreciate all feedback. It is how we improve our services and products.

Re: Red Hat is pretty good at being Red Hat

#44
I work for Pivotal as an engineer.

Red Hat was my first distro, back in '97. I'm grateful.

I wasn't around for the discussion about why Cloud Foundry originally standardised on Ubuntu, but if you're Red Hat, you're hardly going to bet on that. Red Hat's lifeblood is RHEL, anything which threatens it is existential.

And PaaSes threaten RHEL, unless Red Hat controls their own.

Red Hat deserve credit for making a big bet on Kubernetes so early on, when the picture was by no means clear. It's definitely put them well in the hunt against us as k8s picked up momentum. I think Openshift 3 plays to their historical strength, which is in packaging upstream and supporting or feeding back to the upstream.

The article mentions Kubo. We're adding PKS (based on Kubo), jointly developed with Google (Kubernetes, Kubo) and VMWare (Harbor, NSX).

In Labs, from the balanced product team up to the C-suite, we can transform the way you build software. A lot of companies come to us to learn how to thrive in the world of disruption.

So it would've been downright silly not to spot one happening to us and ... uh ... pivot.

(Disclaimer: Nothing in my comments should be seen as official comment by someone who decides anything of any consequence. Not forward-looking. Consult your lawyer, doctor, dentist and gardner before taking this comment as medication.)

Re: Red Hat is pretty good at being Red Hat

#45
post #35

I've been hearing the "boring" comment a lot lately, and I totally agree. I don't want the exciting filesystem (btrfs which just took me for a ride), or the exciting programming language/library that will strand me in 6 months with multiple man-years of work. No, what I want is boring. That means everything works as I expect it too, and it doesn't create drama every few months when the cool kids decide that the old w…

The thing that makes distributions like Red Hat and SUSE "boring" is not that we only do maintenance work, it's that we've effectively solved the problem of maintenance and release engineering -- though of course there's still improvements to be made (and on the SUSE side, openSUSE Leap and the plans for SLE15 are quite interesting developments). We do a lot of work on exciting and interesting projects, some of which…

I am super interested to see how the SUSE stemcell and rootfs work turns out, now that SUSE is contributing to Cloud Foundry.

Re: Red Hat is pretty good at being Red Hat

#46
post #39
post #31

Earlier quoted context omitted.

Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux, and has gotten a lot of work in recent years. eBPF (both for seccomp and tracing) is also quite exciting in terms of its applications. User namespaces are also allowing for developments such as rootless containers. There's also some interesting stuff for trusted computing that are happening with IMA and TPM developments…

CRIU looks amazing, live-migration of LXC containers :)

There are rough edges to be worked out before we arrive at solidly productionised systems, but I believe Red Hat and Docker are both heading in that direction.

Mind you, ask yourself: why do you need it?

If it's for apps, isn't the point of these platforms to not need to care about individual instances?

If it's for data, don't you have an existing way to manage HA or parallelism?

Re: Red Hat is pretty good at being Red Hat

#47
post #29

My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowled…

That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.

> but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.

They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares.

Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write our own operating system kernel / database / programming language / HTTP server / CPU architecture / web framework".

I also think it's a bit rude to assume that Red Hat has hundreds of brilliant engineers just phoning it in. I work for Pivotal and we are flat. out. every. day. writing this stuff, because it turns out that this stuff is a lot harder than it looks from the outside.

And the reason it looks easier is because we did the hard work for you.

Re: Red Hat is pretty good at being Red Hat

#48
post #31

Earlier quoted context omitted.

Out of curiosity, what are the exciting developments happening in the Linux ecosystem these days?

Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux, and has gotten a lot of work in recent years. eBPF (both for seccomp and tracing) is also quite exciting in terms of its applications. User namespaces are also allowing for developments such as rootless containers. There's also some interesting stuff for trusted computing that are happening with IMA and TPM developments…

> Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux

DragonFlyBSD has had process checkpointing for more than 10 years.

https://www.dragonflybsd.org/cgi/web-man?command=checkpoint&...

While the functionality is admittedly & unfortunately quite limited, there are no technological reasons this couldn't have been furthered in the meantime given sufficient funding/dev time, etc.

Re: Red Hat is pretty good at being Red Hat

#49
post #30

Earlier quoted context omitted.

Kubernetes owes its success largely to Openshift and Redhat's efforts. Without Openshift, Kubernetes would just be an interesting POC. Google doesn't dog food Kubernetes. Openshift has since the beginning, and contributed significantly to K8s as a result of actual production usage. Just take a look at the top contributors and you can see the kind of contributions of the Redhat guys. While I sort of agree with you on…

> Kubernetes owes its success largely to Openshift and Redhat's efforts. Without Openshift, Kubernetes would just be an interesting POC. How did you arrive at this conclusion. Curious to know more about redhats role in this.

Red Hat have done a lot of the productionising and packaging and got it running at a lot of companies.

I don't fully agree that Red Hat has more ownership of the success of Kubernetes, though. They may have been necessary, but by no means sufficient. The aura of Google has probably had far more importance in the momentum to date.

Re: Red Hat is pretty good at being Red Hat

#50
post #29

Earlier quoted context omitted.

That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend.

> but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend. They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write ou…

> They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares.

yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..

Post reply on HN