Red Hat is pretty good at being Red Hat
redmonk.com
Red Hat is pretty good at being Red Hat
1–10 of 81 posts
Re: Red Hat is pretty good at being Red Hat
#2My 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' knowledge and clout.
Red Hat is making a very strong play in the microservices/container space. Openshift is a pretty dang good k8s distro, and they're also doing a lot in the API space (especially with 3scale).
Re: Red Hat is pretty good at being Red Hat
#3I'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 way of doing things isn't cool and rewrite a library i've based my application on or change the syntax of the compiler so my code doesn't work.
A few years ago, I started challenging people at work when they were trying to pull in the latest language/library/toolkit, with a simple question. "How does that help our customers". Sure, I got plenty of the 2/3rd order arguments about how making the dev team happy/more productive would result in better feature development/etc. But I've seen these kinds of changes enough to know that usually these 2nd order affects are crushed by the unseen problems that _ALWAYS_ seem to crop up after your already committed to that new technology. Its truly rare to have a new technology that is so much better than the last that the cost of switching pays for itself. That doesn't mean it doesn't happen, it just means that the immature crap everyone is yammering about is likely not that technology. Give it a couple years and if it turns out to still be around (and people are still actively switching to it) then its probably good. This mindset has produced a long list of "successful" products that pay the bills and make people happy without making a lot of noise and crashing/burning regularly.
Bottom line, I will take the old "cruddy" technology with the long list of known problems, to the new cool one with the long list of unknown problems. At least part of that seems to be what RH provides for the opensource community. The old guys that actually fix the bugs, rather than switching to some cool new product.
Re: Red Hat is pretty good at being Red Hat
#4I'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…
Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter?
Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new stuff like this at a risk to your revenue. No can do. But it may be worth exploring side or 20% projects specifically dedicated to building stuff from scratch. Get their itch scratched on non-revenue projects that serve as potential useful on-the-job training and tech evaluation, while possibly getting something of value out of it.
Re: Red Hat is pretty good at being Red Hat
#5OpenShift 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 their Linux kernels. It's exactly why you RHEL has been such a terrible platform to run Docker on. Because RedHat is only pulling in some of the upstream changes into their kernels rather than upgrading everything.
This sort of merging is slow, error prone and costly. If you use anything that they've added that isn't in the upstream it creates vendor lock-in. Sure OpenShift's Route code is open source, but you can't take that to any other vendor without building everything yourself. Want that new feature in the latest Kubernetes release, you better be prepared to wait.
As time goes on it will become harder and harder for them to maintain this fork. If OpenShift doesn't become the dominate Kubernetes distribution then RedHat may lose interest in it and then you'll lose your maintenance of that fork. For that matter, if RedHat loses the maintainers as employees they may lose their ability to maintain this fork.
It's my opinion that anyone buying OpenShift is playing with fire.
The fact that RedHat has failed to get their modifications integrated upstream and have to maintain themselves is a massive failure on their part. This sort of thing was understandable in the past, but we really should expect more of them now.
Re: Red Hat is pretty good at being Red Hat
#6Redhat might be doing well but many open source projects clearly aren't. There are routine SOS posted here about projects in dire straits. So how much of this revenue does downstream see?
Something as critical as Gnupg was recently in trouble and got funding from Stripe and Facebook.
Companies like Redhat acquire projects or hire project leads for influence but few really seem to 'support' open source. Docker is a VC funded company that was entirely built on open source and has made many acquisitions so they had the money but how much support did they give the LXC project, Overlayfs, Aufs and all the other open source projects they use/used?
Github uses Redis but let alone support they never even bothered to tell the author. Do they even support Git in any meaningful way?
If open source is used to provide free software to startups who them promptly forget about it we will get more SOS and interesting projects will dry up.
We will then be left with companies like Redhat and others building open source software requiring large teams which cannot be easily replicated by the open source model.
Re: Red Hat is pretty good at being Red Hat
#7OpenShift 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.
Re: Red Hat is pretty good at being Red Hat
#8OpenShift 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.
A fork can imply many things, but all supersets are forks. I realize that RedHat doesn't like calling OpenShift a fork, but it fundamentally is. The only people that will maintain their additional functionality is RedHat themselves.
If you manage to avoid all of their added functionality then you can avoid the vendor lock in. But you can't avoid the delays in getting upstream features/bug fixes.
If Kubernetes was super stable and you weren't likely to want any of that stuff I would agree it probably wouldn't be a big deal. But it's not. Significant improvements are coming in every single release.
RedHat is managing a decent pace in keeping up with Kubernetes for now. But all that it takes to upset that apple cart is for something to get added in a way that breaks their additional functionality.
If RedHat doesn't have the clout to get their improvements in upstream, why should I presume they have the clout to avoid their additions won't be broken by other changes?
Re: Red Hat is pretty good at being Red Hat
#9I'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…
Also people don't remember how the old proprietary Unixes were very boring
Few things changed between versions and they would tell you exactly what would change between versions so you could be prepared.
(however I have much less trust in a distro running SystemD, it is not stable or reliable)
Re: Red Hat is pretty good at being Red Hat
#10I'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…
Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter? Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new…
The burning desire to build from scratch is simply because it is easier and because it tend to be more verbally valued by management then working on older product which tend to be snarked at as merely maintennance.
The moment management praise also people working on less new and gives them appropriate salaries and autonomy, burning desire changes - except in few people who are truly naturally like that. It is win win, because the remaining people tend to be trully better in cutting edge tech problems.