CentOS and Red Hat Enterprise Linux have the same functionality. The biggest difference is that CentOS is a community-developed, free alternative to Red Hat.Review a comparison below.
CentOS and Red Hat Enterprise Linux have the same functionality. The biggest difference is that CentOS is a community-developed, free alternative to Red Hat.
Review a comparison below.
There are a couple of ways to look at the cost. Right now, we’ll consider upfront monetary cost vs. long-term monetary cost. CentOS, the operating system itself, costs nothing. It’s “free” in so much as there is no cash moving between hands at any point in time, no matter how many systems you install or how many cores those systems have.
Red Hat Enterprise Linux (RHEL), on the other hand, can vary between $99/year per installation (RHEL Developer Suite – Self-support) and $18,000/year per installation (RHEL for IBM System Z – Premium Support). There are developer subscriptions that are free but are for development only (self-support).
*Where the difference is negligible between “RHEL” and “CentOS”, I will refer to them collectively as Enterprise Linux, or EL.
Since CentOS is built from the same source code as RHEL, the upstream packages are the same, the libraries are the same, the kernels are the same and both systems are binary compatible with each other.
To comply with open source licensing, Red Hat publishes the source code, including their in-house modifications to the CentOS git servers, so when I say it’s the same source code, it isn’t just that the package versions are the same, it is exactly the same source code (with a few caveats I’ll mention below).
The lifecycle of CentOS matches that of RHEL, also. For example, with EL 8, this means that updates will continue to be published for 10 years; 5 years of full support (bug fixes, security fixes, and feature enhancements), and 5 years of maintenance support (urgent bug fixes as well as critical and important security fixes). Both RHEL 8 and CentOS 8 will receive the same updates until May 2029!
With many of the core folks who are responsible for CentOS are Red Hat employees, the developers are even the same. This isn’t to say that there aren’t any non-Red Hat employees working on CentOS, though. The CentOS community is vast!
CentOS remains locked to the upstream RHEL source as far as bug fixes, too. If you open a CentOS ticket reporting an issue, unless it is particular to CentOS (which very few issues are), you’re likely to receive a response along the lines of, “Please open a RHEL ticket at bugzilla.redhat.com. If/when they resolve the issue, we will inherit the fix from them.”
For the most part, branding is the major difference between RHEL and CentOS. Much of the work done for a CentOS release is removing the Red Hat licensing, branding, and URLs from the source code and replacing them with CentOS the equivalents.
Both RHEL and CentOS licensing is primarily GNU GPL with some other FOSS licenses, but RHEL adds paid, commercial licensing for the end-user.
One of the benefits of some of RHEL’s commercial licensing options is support. All RHEL installations can be “self-supported”, which means the system administrator has access to software updates and web-based content (articles, knowledgebase, etc), but no direct support from Red Hat. Other support subscription options include standard (8x5) and premium (24x7) support, which includes direct phone and online support avenues. Red Hat also offers extended support which provides support for RHEL versions which have exceeded their normal support lifecycle.
Add-ons are a big thing with RHEL. Many of the RHEL add-ons are the same open source solutions that you can deploy on CentOS but are bundled with support and may include some RHEL-customized or proprietary configurations and utilities. Things like centralized system management, high availability, and clustered file systems are offered in this manner.
CentOS has no paid support options available directly via the CentOS maintainers, and the price happily reflects that. CentOS, like many open source projects, is community supported, bringing the knowledge and experience of thousands of die-hard CentOS (and RHEL) users together for the greater good. Some of the downsides of community support is that you don’t have anyone to contact and there are no guaranteed response time or SLAs, but CentOS support is available from companies likes OpenLogic. Not only are these commercial support options usually at a much lower rate than Red Hat charges, but they can also be bundled with support for other OSS packages running on your systems to provide a single point of contact for all of your OSS software support requirements.
Without that direct revenue stream from the subscription model, CentOS does not endeavor to obtain the same level of hardware and security compliance certification as RHEL. As we’ve discussed, CentOS and RHEL are almost identical, so CentOS should also meet all of the same requirements if configured the same way, but, without the expense of the actual testing, CentOS doesn’t share the actual certifications.
There’s also the matter of 3rd party software vendor support. Many commercial vendors will specify that they support their software running on RHEL, but many don’t mention CentOS. That isn’t to say that the vendor’s software won’t run (or won’t run well) on CentOS, it’s just not a supported configuration according to that particular vendor.
If this is the case with any of your commercial software, check with your vendor and see if they’ll support their software equally on both CentOS and RHEL; some don’t care which EL the software runs on… but some want a particular version of RHEL.
CentOS doesn’t come in “flavors” as RHEL does. Red Hat offers variations of desktop, workstation, developer and server installations, and also virtual host/guest options. The included software, add-ons, and typical support level are different for each one.
CentOS offers LiveCD ISOs which is something that RHEL does not do, even though their mutual ancestor, Fedora, does. LiveCDs are bootable CDs/DVDs and are great for rescuing a misconfigured/damaged system or for testing things out without the need to install the OS onto a hard disk.
To access the RHEL software repositories, you have to have a current, active RHEL subscription. Thus, your subscription lapses, you can no longer obtain package updates or install new software. The CentOS software repositories are public, do not require a subscription or login credentials, and are mirrored at many locations around the world.
Speaking of repositories, there is a repo difference that some consider important. RHEL publishes metadata about packages that describe the security issue or bug report addressed by the updates. This can be useful if you wish to only apply security-related updates or to limit the updates installed to only those that address a particular vulnerability.
This information is not published by CentOS but is available through 3rd parties. Of course, you can perform these steps manually, also. The reason that this difference is often overlooked is that, if you keep all of the packages installed on your systems up to date, you’re going to have all of the available security patches and bug fixes installed on your system anyway.
With RHEL, it is possible to test out release candidates a few months before the full GA (General Availability) release. While running your production systems on a beta release is not a good practice, early testing of your applications on the release candidate in a lab environment can alert you to possible issues sooner.
CentOS does not make beta releases available but does offer a CR (continuous release) repository that is populated with the packages that will make up the next point release. The CR repo is available for a couple of weeks before the GA release.
The CentOS 7 releases were publicly available about 2-4 weeks after the equivalent RHEL release and ongoing package updates were released very shortly after the RHEL updates; security updates usually only seeing about a 1-day delay.
With EL 8, the entire CentOS build system had to be reconstructed, adding quite a bit more initial delay. CentOS 8.0, for instance, released about 4 months after RHEL 8.0. CentOS 8.1, though, was released about 2 months after RHEL 8.1. This has increased the delay for package updates a bit.
Each company and every customer have different requirements around their operating system and the type and level of support they need. Outages can occur and have hidden costs too. Your reputation could be damaged, you could lose future business, a loss of in-house confidence can make progress grind to a halt, etc.
You need to weigh all of the things that we’ve discussed to determine how much you need to invest in your OS infrastructure.
If you can self-support, CentOS may makes more sense than paying Red Hat to let you do that same self-support. If you’re mostly self-sufficient but need some support “insurance”, or you want to outsource the bulk of your CentOS support, a support contract with OpenLogic may be the best option.
If you’re locked into using RHEL by a 3rd party software vendor or have other business need that make RHEL the only viable option, Red Hat will be happy to take your money. OpenLogic support contracts typically save our customers over 50% when compared to RHEL support subscriptions.
CALCULATE YOUR SAVINGS
CentOS Developer, OpenLogic by Perforce
Rich has over 19 years of experience in the IT industry, specializing in CentOS-based and OpenWRT-based Linux systems as well as microwave point-to-point and point-to-multipoint RF engineering. Rich holds a degree in computer science and is a certified master Linux administrator as well as a certified Aperto technician.