How Can I Justify Using Red Hat When CentOS Exists? 666
Bocaj writes "I recently spec'd out a large project for our company that included software from Red Hat. It came back from the CIO with everything approved except I have to use CentOS. Why? Because 'it's free Red Hat.' Personally I really like the CentOS project because it puts enterprise class software in the hands of people who might not otherwise afford it. We are not those people. We have money. In fact, I questioned the decision by asking why the CIO was willing to spend money on another very similar project and not this one. The answer was 'because there is no free alternative.' I know this has come up before and I don't want to beat a dead horse, but this is still a very persistent issue. Our CIO is convinced that technical support for any product is worthless. He's willing to spend money on 'one-time' software purchases, but nothing that is an annual subscription. There is data to support that the Red Hat subscription is cheaper that many other up-front paid software products but not CentOS. The only thing it lacks is support, which the CIO doesn't want. Help?"
Why? Simple, lack of security updates (Score:2, Informative)
CentOS went three months without a single security update earlier this year, who in their right mind would touch it given that history?
Re:Update & security responsiveness (Score:2, Informative)
The only updates Red Hat is ever prompt with are security updates. Until recently, I was forced to use RHEL for a number of servers (yes, it could have been much worse, Windows, etc.) but I spent a good deal of time rebuilding RPMs from Fedora just to get current libraries. And I'm not talking weird drivers for esoteric hardware, I'm referring to core language support for Perl, Ruby, Python, etc.
One option you could look at is using Ubuntu. The product is free but Canonical offers paid support for the LTS releases. So you could deploy on it now, and if attitudes change, you can add support later. I've never purchased support for an existing install, there may be a consultancy fee for them to make sure you're not trying to buy support after the fact for a system that's already borked... but it's an option worth exploring.
Re:Support them from your own money (Score:4, Informative)
Re:Update & security responsiveness (Score:5, Informative)
Before I came to Red Hat I had a similar opinion. When I worked in Silicon Valley I thought "Why would anyone want to pay for Red Hat, I can't afford it so that means it's expensive." However after being at Red Hat for over a year my opinion has changed, and that has been because of some things I have witnessed.
Support is one of the first things people think about, however there is a little more than meets the eye here. Let's start with the packages. Let's say there's a major exploit in SSHd, you will likely see a fix from Red Hat within a few days, which will then be available via RHN. The source to the rpm will also be available at ftp.redhat.com due to the GPL obligations. (More on the GPL and RH later.) At this point in time RH customers have the patch available, in this fictitious scenario let's say it took RH 3 days to release the patch from time of exploit publication. CentOS users still don't have the fix, plus CentOS operates somewhat as a "Black Box." You will get the fix when they get around to it, let's say that takes two weeks before it's released (Could be more could be less). That means your systems are vulnerable for about two weeks, in some shops that's an acceptable risk, in other places it's not.
* Support from people is the other thing that people think about. Have you ever had to call RH support? If yes have you ever talked with an idiot? In the many times I have called RH support I have not dealt with anyone who I felt was sub-standard. Most often the problem I have seen is when the clients I'm working with do not present RH support with the information required in a timely manner. When the answers come back they often link to other knowledge base articles and have clear steps to either solve the problem or to better understand some of the complexities. When a solution is found and there is not a KBase article I understand (I may have heard wrong here) that there is an obligation to write a KBase article. I know that tickets are reviewed after they are closed. One ticket I opened regarding Satellite for a customer is getting discussion amongst the Satellite developers about how to best handle the same scenario in the future.
* Support from Articles, this I feel is a real hidden Gem of RH. Nobody knows about it until you have a subscription, and then everyone is so used to using Google for their answers they forget to start here first. The KBase articles from RH are phenomenal! I had a customer ask me how to rebuild the RH ISO image to include their own KS script. I could Google and find 10 articles talking about much of what I'm looking for or search the KBase and find one article that has every step needed for modifying a RHEL disk to have the KS script on the disk.
* Training. Having been through a few RH training classes I can say they are all very good. Yes there are some areas where I have questioned the need to know some things, but that is normal, but I'm never left feeling like the class was a waste. I have always walked out having learned many things which I can use later.
* Consulting. Yes there are many open source consultants who can come onsite and help implement a solution or fix something, however how many of them have access to the people who wrote the Distro or maintain the upstream project? RH has an internal list just for technical questions, many of the engineers are on this list and very technical answers are delieverd. Often SAs (Solutions Architects) and Consultants will post questions their clients have asked. I have yet to see a response of "Why would you want to do that?" or "RTFM."
* Additional products. Red Hat takes upstream projects and repackages them to integrate tightly with RH. Satellite is one example, it comes from Spacewalk and is designed to help keep internal systems up to date and patched according to their channel assignment. Could you use Spacewalk to manage your CentOS machines, yes you can! However let's say you have a problem getting Spacewlak to work right, or there's a bug, what kind of support
Re:Support them from your own money (Score:4, Informative)
Red Hat's share price is at a 5 year high, and I believe their revenues are at an all-time high. If they are being crushed, it is in some wierdly subtle way that shows up on the balance sheet as strong revenue and profitability.
Re:Give Em A Call (Score:4, Informative)
A salesperson who does not bend the truth is far and away the exception. Good on you. But more good on your employer who doesn't structure your pay to essentially require you to compete with your colleagues (on a quarter by quarter basis, not over time) who all DO bend it. Because if they did, you'd get let go if you fell behind, so you'd be similarly dishonest or let go. That's how the vast majority of sales organizations are structured.
Re:Support them from your own money (Score:5, Informative)
There are two reasons why I am speccing RedHat over CentOS, and neither have to do with support:
1: Application support for production systems. Yes, it shouldn't make a difference, but if I call in for support on an application that specifies the list of supported operating systems, and its not RedHat, there is a good chance I'll get laughed off the phone with "sorry, no app support until you have a supported OS".
2: FIPS, Common Criteria, and other certifications. These can mean the difference between "due diligence" in IT versus bad faith when it comes to an audit. Yes, this is pure legal eagle stuff, just like the requirement that the 64 CPU POWER7 box in the rack has to run McAfee, but it means the difference between passing an audit, or perhaps getting a contract terminated.
This doesn't mean CentOS is bad. It just means that having the certificates that come with the commercial version of RedHat may mean success or failure when the CPAs and the JDs are done extracting their pounds of flesh.
Re:Update & security responsiveness (Score:4, Informative)
By and large the CentOS team do an excellent job with the distribution - but it's a volunteer effort and there have been some notable times lately when important or security updates which have been shipped by Red Hat run late with CentOS, sometimes by a considerable amount of time.
You could also use Scientific Linux instead of CentOS. SL has the backing of CERN behind it, and as a result it has been much more responsive to that sort of thing. SL 6.0 and 6.1 came out much sooner than the CentOS team could port (hell, I think we're still waiting for CentOS 6.1). SL is pretty much otherwise identical in spirit to CentOS... pretty much a white-box clone of RHEL. Sure there are a few minor improvements [scientificlinux.org]. And there's a LiveCD!
CentOS itself was apparently launched by a diskless clustering company [infiscale.com], which has since started primarily developing on Debian. So I kinda anticipate SL becoming the premier RHEL clone.
Most places I've worked for would develop on CentOS, then swing for the RHEL license when they deploy to clients (probably so they can bill it and markup a "handling fee").
There is a movement to migrate everything to RHEL for security reasons (mainly so you have someone else to blame if your server gets hacked for any reason, I suppose if you're running CentOS you basically might have to suck up the blame).
I would like to support Redhat financially, but I'm more of a Debian guy, and the RHN is more or less broken on the RHEL6 licensed VM that work bought for me due to some certificate error :-P
Re:Support them from your own money (Score:4, Informative)
Where I am working at the moment runs Centos on many of their servers. Why? Because they are a consultancy and many clients are using RedHat. Centos allows them to develop against it with relatively high confidence it will work the same on RedHat (as well as you could expect developing against RedHat on a development network and then shipping a product to be deployed in a different environment at least). I don't see the client base changing to Centos for deployment - they need / want the support blanket.
Re:Linux is free if your time is worthless. (Score:4, Informative)
His point is that the cost of a RHEL license is only a tiny component of the TCO of a server. After that, if anything goes wrong, then the question is: is the price you pay for RHEL support less than the time it would take you to handle it yourself? Also, as someone else pointed out, RHN adds configuration management and faster patches. Time to set up some other system to management system configs; time to repair or replace hacked boxes because a centos patch was too slow... In the grand scheme of things, those may not be worth it. For example, in a fully-loaded 12-core system being used for virtualization hosting with a 4:1 cpu overcommit, RHEL only costs $.0019 per vm-hour.
Also, long term support is a big deal in enterprises. A lot of times large enterprise projects are built over the course of years. Having Red Hat means that when some change to a piece of hardware firmware causes some inexplicable OS crash 5 years after deploying. It may be very specific to your environment and your hardware and software. You can call up Red Hat, and if it hasn't been fixed, they will go in and fix the source code in order to fix it for you. There are cases where the systems and their function is worth hundreds of thousands or millions of dollars; having Red Hat able to "stand behind" Linux is worth paying for, for some people.
Re:Support them from your own money (Score:4, Informative)