Information about CentOS Stream 10 has been trickling in since ISOs first became available in June. CentOS Stream 10 will be based on Fedora 40 and released sometime ahead of RHEL 10, but the current images are still in testing/development and could very well change between now and the actual release. 

So what do we know about CentOS Stream 10? Our expert weighs in and offers considerations for enterprise teams considering CentOS Stream for production workloads.

CentOS Stream Project Update 

CentOS Stream has an interesting history, with some notable developments in the past few years. After announcing in 2020 that CentOS Linux would be discontinued in favor of focusing on CentOS Stream, last year Red Hat ruffled more feathers by announcing that CentOS Stream would become the sole repository for RHEL source code. CentOS Stream 8, the first release, reached end of life in May 2024; CentOS Stream 9 has been out since 2021. 

On June 6, 2024, the CentOS Project posted links to the CentOS Stream 10 compose images, install ISOs, and container images with the following message: “Please note the compose is still taking shape. Packages are still being added and even removed at this point. Not all packages are fully onboarded to gating, so just some updates are landing. Packages are being moved between repositories. Comps groups are being updated…” Developers were encouraged to test and share feedback.

In other words, much is still to be determined. New ISOs have been made available periodically since the June announcement (as of this writing, the last batch dropped on October 22, 2024). 

Back to top

CentOS Stream vs. CentOS Linux

The main difference between CentOS Stream and CentOS Linux is that CentOS Stream is upstream of RHEL, with packages planned for upcoming releases, and CentOS Linux is a rebuild of the current RHEL release.

Another key difference is how updates are made in the two distributions. For CentOS Linux, new minor versions consist of large batches of updates, with smaller updates between versions. Rather than batch updates, packages in CentOS Stream are updated as they are ready, in a continuous stream, and there are no minor versions. 

Before all versions reached end of life, CentOS Linux had a community support lifecycle of ten years, like RHEL and many other Enterprise Linux distributions. CentOS Stream has a shorter lifecycle of five years, with EOL based on when the corresponding RHEL release leaves Full Support and enters its Maintenance Phase (security updates only). 

Back to top

How Long Will CentOS Stream 9 Be Supported?

CentOS Stream 9 will be supported until May 31, 2027, when RHEL 9 leaves Full Support.  

Back to top

CentOS Stream 10 Release Date

CentOS Stream is upstream of RHEL and all signs point to the RHEL 10 GA release sometime in the first half of 2025, so the CentOS Stream 10 release is anticipated in late 2024 or early 2025. 

Back to top

Notable Changes in CentOS Stream 10 

• Kernel: CentOS Stream 10 will be using a 6.11-based kernel, rather than 5.14 that CentOS Stream 9 used.
• Programming language support/compilers: CentOS Stream 10 has GCC 14.2.1 (instead of GCC 11.5), and Python 3.12 (instead of Python 3.9).
• CPU compatibility and capabilities: one user encountered a warning message that that x86_64-v3 will be required at a minimum in the future, but as of now it is just a deprecation warning.
• Performance: Phoronix ran some benchmarks, and a thorough comparison of performance is available here. That is for Arm64 instead of x86_64, but should still be comparable.

Back to top

Using CentOS Stream in Production

There is some debate over whether enterprises should use CentOS Stream in production. Some say the rolling release model makes it too unstable and that it’s more of a ” beta testing ground” for features, or a preview of the next version of RHEL (though not everything in Stream may make it into RHEL). Red Hat explicitly says that CentOS Stream “is not designed for production use in enterprise environments” and recommends using RHEL as a CentOS alternative.

However, depending on your use case, using CentOS Stream for production workloads may not present any issues. Some teams like that Stream gives them access to bug fixes and new features before they become available in RHEL. The notion that CentOS Stream is fundamentally less stable or reliable than RHEL is not really accurate, as everything in Stream undergoes QA and testing, and has been accepted for the next minor RHEL release before being merged into Stream.  

The main difference between RHEL and CentOS Stream comes down to commercial support and services that RHEL provides to its paying subscribers.  

Still, a lot depends on your particular use case and infrastructure to determine whether or not CentOS Stream is the right fit. 

Back to top

CentOS Stream 10 Migration and Upgrade Considerations

As usual, you will want to test thoroughly before upgrading important systems. The new kernel version may not support older hardware, and with x86_64-v3 coming in the future, some older hardware may not work at all. Information about glibc-hwcaps can be found here. RHEL 9 did the same with x86_64-v2 and a simple test under Proxmox using x86-64-v2-AES produced a kernel panic during just an install, but x86-64-v3 succeeded.

With a new kernel, glibc, gcc, Python, and other changes, some existing software may not have library versions available to run the older version. Containers or VMs could mitigate the problem, however.

Back to top

What to Expect from Future CentOS Stream Releases

In future CentOS Stream releases, you can expect continuous upgrades of packages, with new versions, security patches, and performance improvements. Future releases may introduce new features, such as updated kernels, newer versions of programming languages, and support for emerging hardware or software trends.

Back to top

Final Thoughts 

CentOS Stream 10 gives us insight into what is likely to be included in the next version of RHEL — the first major release in four years. As to whether CentOS Stream 10 is a viable alternative to CentOS Linux or the best Linux distro for your organization, I recommend checking out this CentOS Stream checklist for guidance. 

It’s always a good idea to have technical support for your mission-critical workloads, and ideally, to work with experts who have full stack expertise to troubleshoot issues with updates and integrations. If you decide to use a FOSS Linux OS, it’s wise to pair it with commercial support from OpenLogic so you always have immediate access to Enterprise Architects. 

Apache Kafka issues, especially for enterprises running Kafka at scale, can escalate quickly and bring operations to a halt. The open source community may be able to offer assistance, but in some situations, you need a resolution fast. 

While some organizations partner with OpenLogic for ongoing, SLA-backed Kafka support, our Professional Services team gets involved when a customer who does not have a support contract needs a consultation or help troubleshooting an issue with their Kafka deployments. These engagements can last anywhere from a few days to a few weeks, depending on the scope and complexity of the project. 

In this blog, we present four Kafka case studies with details on what the Kafka issue was and how OpenLogic solved it. 

Case Study #1: Large Internet Marketing Firm

Background: This customer was tracking clickstream events to measure ad campaign success. Their large bare metal implementation contained 48 nodes, and was processing roughly 5.8 million messages per second with 1-2 second end-to-end latency.

The Issue: LeaderAndIsr requests were failing during rolling restarts, resulting in multiple leader epochs with stale zkVersions.

The Solution: OpenLogic identified an existing bug that had not been fixed in the version of Kafka they were using, which had a higher likelihood of occurring during resource contention on the Zookeeper instance co-located on five of the Kafka nodes. They recommended upgrading the Kafka cluster and running Kafka on Zookeeper on independent nodes, which fixed the issue. 

Length of Engagement: 5 days 

Case Study #2: Large South American Bank

Background: This customer was currently utilizing IBM MQ and not hitting the performance metrics they desired. They were having to deal with large messages at high volume.

The Issue: Due to slow response times with end-to-end latency and total throughput with large messages, the customer wanted to move to Kafka to have a streaming-focused messaging bus.

The Solution: OpenLogic provided architecture using the Saga pattern with Apache Kafka and Apache Camel for managing long-running actions, such as crediting a payment on a loan from cash deposited at a branch. They also provided architecture for using Kafka with log shipping and the ELK stack, as well as for bridging events from IBM API Connect Cloud to Elasticsearch index behind the firewall using Apache Kafka. Finally, OpenLogic led a 5-day Apache Camel training to a team of 15 people so they could learn how to create Kafka consumers and producers.

Length of Engagement: 27 days 

Related Video: Apache Kafka Best Practices 

 

Case Study #3: U.S. Aerospace Firm

Background: Originally this customer wanted help with Rancher and moving from a VM-based Kafka cluster. They were utilizing a web socket server that was responsible for collecting satellite location data in real time. The web socket server could not talk directly with Kafka, and so they had developed a Camel-based system for their original Kafka cluster. They did not have any metrics collected on the existing cluster and could not identify the root cause for message delays and lag. 

The Issue: Performance issues with pub/sub relay application that consumed from websockets from domain-specific appliance and published to Kafka queues.

The Solution: OpenLogic implemented Rancher clusters dedicated to running the Strimzi operator and serving Kafka clusters. They were also able to improve throughput dramatically by moving existing Java code to Apache Camel with vertx driver. 

OpenLogic created metrics with Prometheus and Grafana in both the Camel websocket relay application and the Kafka brokers to determine replication and processing lag, and put monitoring in place to alert on topics that didn’t meet SLAs. Once metrics collection with Grafana and Prometheus were put in place, existing bottlenecks became identifiable and addressing them drastically improved end-to-end performance.

Length of Engagement: 3 days 

Case Study #4: Global Financial Services Company

Background: Customer came to OpenLogic with a security concern with Kafka Connect that violated PCI compliance as well as internal security standards.

The Issue: Sensitive information was included in stack traces with Kafka Connect.

The Solution: OpenLogic created a test harness, which was sanitized so that customer information was not present, that reproduced the bug. They filed a bug against the project and attached the test harness – and wrote the code that resolved the bug. OpenLogic then submitted the code to the community and worked with community to modify the PR to meet the community’s standards. Finally, they informed the customer when the bug was accepted and estimated which release was likely to include the fix for it. As a result, this K.I.P. was produced from the engagement.

Length of Engagement: 20 days 

Final Thoughts

Apache Kafka is an extremely powerful event streaming platform, but when things go wrong, they go wrong at scale. These Kafka case studies illustrate the benefits of having direct access to Enterprise Architects with deep Kafka expertise in those moments when every minute counts. 

Understanding the differences between community open source, open core, and commercial open source software is important when making choices that lay the foundation for systems and applications, as these decisions can have cascading effects on costs and flexibility for internal users and/or downstream customers.

In this blog, we break down the key differences between these three categories of open source software, and we’ll share some important considerations for teams deploying OSS both internal and external to the enterprise.

Editor’s Note: This blog was originally published in 2019 and was substantially updated and revised in 2024.

What Is Community Open Source Software?

Community open source software, also known as Free and Open Source Software (FOSS), is source code owned by a group of volunteers that have organized around a shared problem. Community open source projects are free and open to the public, and they’re bound by a permissive or restrictive license.

Related resource:How Does Open Source Licensing Work?

Open source communities bring people with shared interests together to collaboratively build something. Some of the most popular and widely used community open source projects are backed by nonprofit foundations such as the Apache Foundation, Linux Foundation, or Cloud Native Computing Foundation. Foundations add an air of legitimacy and garner inherent trust among users who might otherwise worry about adopting software built by a disparate cohort of individual contributors.

There are millions of FOSS projects but in the 2024 State of Open Source Report, respondents mentioned Linux, Jakarta EE, Apache Server, Docker, Kubernetes, PHP, WordPress, Python, PostgreSQL, MySQL, Kafka, and Eclipse IDE as among the most business-critical for enterprise. 

Back to top

What Is Open Core Software?

Open core is a commercial model of software delivery where a company creates (or contributes heavily) to a “core” version of open source software, allowing users to freely adopt, adapt, and distribute it under an open source license, and then wraps that core version with advanced features, extensions, or enterprise-level scaling and availability under a proprietary license.  

This approach allows a company to leverage the collaborative nature of open source to build a community around the free version, which benefits from diverse contributions and widespread adoption. At the same time, they generate revenue by monetizing premium features aimed at larger organizations. This sometimes quickens time-to-market for a more commercially sustainable product.

Examples of open core software include Cloudera Data Platform, Oracle Linux, SUSE Linux, Redis, Grafana, Confluent Kafka, MongoDB, and GitLab.

Back to top

What Is Commercial Open Source Software?

Commercial open source vendors provide professional services for fully open source software. All features and functionality of that software remain open and freely available, and the company generates revenue through consulting, hosting, and support. 

Like open core, the commercial open source software approach benefits from the community-built software as a foundation. Although COSS companies likely contribute to the software, they don’t license their contributions separately. Instead, they provide value to their customers by professionalizing the implementation and adoption phases. 

RHEL and Rancher by SUSE are examples of COSS.

Get the Latest State of Open Source Report

The State of Open Source Report includes insights, analysis, and trends from a global survey of OSS users working in industries like finance, technology, retail, manufacturing, government, and more.

Download

Back to top

A Note About Open Source Definitions

The above definitions draw clean lines for the purposes of comparing and contrasting open source models; however, some companies employ multiple models across their portfolio. As companies grow and add products, this gets more prolific. In some cases, the lines drawn between these models (particularly COSS and open core) become progressively more gray.

A good example would be Red Hat Enterprise Linux, which is sold under a proprietary license; however, it is made up of code from two upstream open source products (Fedora and CentOS Stream). In this case, it borrows from the open core model, but there isn’t a true single free version that it extends.

Back to top

How to Choose Between Community Open Source, Open Core, and COSS 

All these options are based on the open source model, so they all have the potential to benefit from the power of a collaborative and transparent development process. When compared to proprietary internal development or purchased vendor software, all these OSS models can fundamentally reduce cost and time-to-market, while increasing security, stability, and innovation.

With each of these open models, there are costs. The cost of commercial options, either open core or COSS, are more obvious, and come in the form of license fees, maintenance contracts, hosting costs, support subscriptions, and consulting services. However, Free and Open Source Software (FOSS) also has associated costs that are more hidden. Adopting FOSS requires organizations to dedicate internal staff and infrastructure to hiring, acquiring, and maintaining the skills necessary to install, configure, upgrade, and contribute to sustainable development of the free-to-use software. It’s important to not forget about these shadow costs when considering FOSS for enterprise use cases.

The “F” in FOSS stands for free as in freedom, not absence of cost.

Knowing there are costs associated with all options may help organizations focus on the value and predictability of each of those costs. 

Here are some questions that can help steer an organization toward a defensible return on the investment:

• What features are included in the commercial edition? Do I need those features? Are there alternatives that can achieve the same result?
• What license(s) are associated with the software? Are they permissive, restrictive, or proprietary?
• Does my organization have the skill and bandwidth to implement, maintain, and support the product?
• How mature is the product and the backing community or commercial support vendor?
• Is there a single commercial vendor that can serve all my open source software needs?

The table below illustrates, at a high level, some of the benefits and drawbacks worth considering: 

Back to top

Final Thoughts

The decision to choose community open source software vs. open core or commercial open source software comes down to the depth and breadth of the projects, budgets, and use cases, as well as the scale of the environment(s).  There are situations where it makes sense to invest in commercial backing for open source development and other times when it might be better to implement a community-based solution. The three models outlined in this article layout a spectrum options that cover most needs.

Perhaps the most fundamental consideration is whether to:

1. Spend valuable internal staff time on the installation, configuration, troubleshooting, training, maintenance, and support of the OSS that lays the foundation for the applications needed to deliver value to the business or downstream customers
   or
2. Engage a vendor to ensure the organization has a secure, stable, and performant platform that enables internal staff to focus their time and energy on developing and maintaining domain expertise in delivering top quality applications needed to drive value for the business or downstream customers.

The Enterprise Linux landscape has experienced no shortage of shakeups in the last couple of years. Now after CentOS 7 EOL, many teams are looking into CentOS alternatives and weighing the value of commercial Linux distros like RHEL, which comes with technical support included, to community-backed free alternatives like Rocky Linux. 

Since they are functionally very similar, Rocky Linux vs. RHEL really comes down to differences in cost and support. In this blog, our expert compares the two distributions with consideration for not just upfront costs, but ongoing maintenance, and discusses why it’s wise to pair Rocky Linux with third-party support to reduce your risk.

Rocky Linux vs. Red Hat Enterprise Linux (RHEL)

The main difference between Rocky Linux vs. RHEL is that Rocky Linux is a community-developed, free alternative to RHEL, which is a commercial solution requiring a paid subscription.

Any discussion of Rocky Linux vs. RHEL should also consider the entities behind the projects: Red Hat, an IBM subsidiary since 2019, is the creator of RHEL, whereas Rocky Linux is owned by the Rocky Enterprise Software Foundation (RESF). RESF describes itself as a “self-imposed not-for-profit” company; while they are not a 501(c)3 or 501(c)6 nonprofit organization, they maintain that their designation as a Public Benefits Company (PBC) is to prevent any one corporation, individual, or group of individuals from having too much influence or control over the project.  

It’s also worth mentioning that one of the founders of Rocky Linux is Gregory Kurtzer, who was also a founding contributor of CentOS Linux. When Red Hat acquired CentOS Linux and then discontinued it in favor of CentOS Stream, Kurtzer created Rocky Linux as a free alternative to RHEL, which is what CentOS had been.

Back to top

Is Rocky Linux Still 1:1 Compatible With RHEL? 

In terms of functionality and features, Rocky Linux and RHEL are virtually identical. Rocky Linux formerly used the RHEL source code to build their own packages (as did AlmaLinux, Oracle Linux, and many others) but Red Hat’s move to restrict RHEL source code access changed the method by which they maintain compatibility.

Rocky Linux still maintains 1:1 compatibility, but in a different manner than AlmaLinux and Oracle Linux. In a statement from July 29, 2023, Rocky Linux said it obtains the “source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMS.” 

The table below illustrates how Rocky Linux and RHEL compare when it comes to factors like licensing, security, package management, and support.

Back to top

Rocky Linux vs. RHEL Cost

At a glance, this is an easy one: As a community-managed distribution, Rocky Linux is free to install and run, so theoretically the cost is zero. RHEL is a commercial product sold by Red Hat, so users pay annual fees that are based on the number of servers (close to $400/server per year as of this writing). 

Calculating the Total Cost of Ownership is a little less straightforward, since it encompasses things like commercial support, hardware costs, complexity, and personnel required to maintain.

Back to top

Rocky Linux vs. RHEL Packages

Rocky Linux’s goal is to be completely compatible with RHEL, like CentOS was. The packages are all compiled from the same sources and patches. One of the few differences is branding. The redhat-* packages are replaced with rocky-* packages, and branding has been changed so that Rocky is present instead. Other than that, anything that can be installed and run on RHEL will be able to be run on Rocky with no changes.

Back to top

Rocky Linux vs. RHEL Release Cadence and Lifecycle

Rocky Linux releases closely follow RHEL releases, usually by days or weeks. These brief delays are due to the rebuild process and community-driven development. For example, RHEL 9.3 was released on November 7, 2023, and Rocky Linux 9.3 was released on November 20, 2023.

Get the Decision Maker’s Guide to Enterprise Linux

Explore the top Linux distributions for enterprise in our recently updated guide. Includes in-depth comparisons of the top distros including RHEL, Rocky Linux, AlmaLinux, CentOS Stream, Oracle Linux, Debian, Ubuntu, and more. 

Download White Paper

Back to top

Rocky Linux vs. RHEL Licensing

Rocky Linux and RHEL have distinct licensing models. Rocky Linux is a community-driven, open source project. It is released under the BSD 3-Clause license, which allows free use, modification, and distribution. There are no licensing or subscription fees associated. 

RHEL is a commercial product from Red Hat and requires a subscription license to use. This is generally based on the number of systems and the level of support needed.

Back to top

Rocky Linux vs. RHEL Support

Rocky Linux and RHEL offer different levels and types of support.

Rocky Linux doesn’t offer paid support itself. It has community support through forums and documentation. You can also purchase support through third-party vendors like OpenLogic. 

RHEL comes with commercial support directly from Red Hat. This includes technical assistance, access to Red Hat Knowledgebase, and dedicated support channels.

Back to top

Migrating From CentOS to Rocky Linux

Migrating from CentOS to Rocky Linux is relatively easy, at least from version 8 or 9.  There is no Rocky Linux 7, so you would have to upgrade CentOS 7 to 8 first, then migrate.

There is a conversion script available from Rocky Linux called migrate2rocky.sh. This will migrate from CentOS 8 to Rocky Linux 8. There is another one called migrate2rocky9.sh for migrating from CentOS 8 to Rocky Linux 9.

This script does a bunch of things, but mainly, it replaces the CentOS repos with the equivalent Rocky Linux repos, then replaces a few specific packages, such as replacing centos-release with rocky-release.

CentOS Stream may have some higher package versions than the point releases due to it being a rolling distribution. The script saves the newer version, but disables the repos so any updates come from the current repos. A later point release should replace those as well.

Back to top

Migrating from CentOS to RHEL

Red Hat has a similar tool called convert2rhel. You do have to have a valid RHEL subscription to do this, though. There is even an instruqt lab that you are able to run that demonstrates migrating a CentOS system to RHEL. It will convert from CentOS to a current fully supported version of Red Hat.

Back to top

Choosing Between Rocky Linux and RHEL

There are several factors to consider when choosing between Rocky Linux and RHEL. Cost and support are probably the two biggest considerations. RHEL is not free, but the license includes 24/7 technical support from Red Hat, along with updates and patches.

Updates and patches for Rocky Linux are provided by the community, but without enterprise-grade, SLA-backed support. The community does not have SLAs, for example, so you may not get a fix or support for a problem in a time period that works for you or your customers. This is why some organizations may find it necessary to pair Rocky Linux with a commercial support offering, to ensure that any issues are addressed quickly.