As the Big Data landscape has changed, comparing Apache Hadoop vs. Cloudera and their commercial platform is a worthwhile exercise. Do enterprise teams still need Cloudera for their Big Data stack management or can they save by independently managing their Apache Hadoop implementation?

In this blog, we’ll take a close look at the value of the Cloudera platform’s software bundle, proprietary tools, and cloud-hosting services. We’ll also explore Cloudera alternativesfor organizations that would prefer to not migrate to the cloud and want the freedom to decide where and how to manage their data infrastructure. 

Note: In this blog, references to the Cloudera platform are meant to encompass both the Cloudera Data Platform (CDP) and the legacy product, Cloudera Distribution of Hadoop (CDH).

Apache Hadoop vs. Cloudera: What’s the Difference?

Apache Hadoop is a free, open source data-processing technology that uses a network of computers to solve large data computation via the MapReduce programming model. Cloudera offers a commercial, Hadoop-based platform that is available via paid subscription.

The Cloudera platform is based on Apache Hadoop and various other software packages that, by and large, are part of the broader Apache Hadoop ecosystem. Therefore, many of the features and functions of Cloudera’s platform are available for free via the collection of those foundational open source software packages. 

When customers pay for a Cloudera subscription, they are essentially paying for:

• A curated bundle of the open source software packages and specific versions that have been validated and proven to work together.
• A couple of proprietary (not open source) applications that provide conveniences intended to help adopters manage an implementation of these disparate open source software packages.
• A hosted managed services provider that unites it all in a controlled environment with the promise of stability, availability, and carefree maintenance.

While valuable for some enterprise use cases, these benefits come at a price — particularly the last one, as cloud migrations can be expensive. Because the Big Data landscape is continuously evolving with new solutions coming on the market all the time, it is a good practice to regularly evaluate the return on investment of those features against the cost of managing an equivalent open source stack. 

In the next few sections, we’ll dig deeper into the three bullets mentioned above and compare them to the free equivalents in Apache Hadoop.

Back to top

1. Cloudera’s Curated Bundle of OSS

When the Hadoop Ecosystem was an emerging technology, it was beneficial to have a leader in the space like Cloudera piecing together and testing a set of immature open source technologies that were under active development. Cloudera made it so individual companies did not have to dedicate development resources to keep pace with many independently evolving software releases and ensure there were no breaking changes at all the integration points. This can be particularly painful for early adopters, as there are rarely standards or best practices in place to allow product features to evolve independently. Without standards, the products are more tightly coupled and implementations must be more closely managed. 

The situation today, however, is very different. For example, many products now rely on JSON or YAML as the agreed-upon data exchange formats, but those were not in place 20 years ago. Data formats like Parquet and Avro take this a step further. Likewise, there are best practices around RESTful API versioning that many products now implement — and the list goes on. So what would have been very burdensome and resource-draining when Hadoop first emerged is considerably more feasible these days because standards and best practices have caught up. 

This is not to say a controlled and validated environment isn’t a good thing. It just might not deliver as much ROI for organizations as it once did. Furthermore, one must reevaluate being locked into a bundle vs. having flexibility now that more innovative and impactful technologies are available. Specifically, there are a couple of foundational areas where Apache Hadoop has made considerable advancements compared to what you get with the Cloudera implementation of Hadoop, and that’s what we will cover next. 

Execution Services: Oozie vs. Airflow

At a time when more modern organizations are moving toward Apache Airflow for workflow, Cloudera is still shipping with, and relying on, Apache Oozie. Apache Oozie workflows are tied to the Hadoop ecosystem and require unwieldy XML-based definitions. In contrast, Apache Airflow is a more modern, flexible, and scalable workflow and data pipeline management tool that integrates well with cloud services and various systems beyond Hadoop. It has a friendly user interface, a strong community, and advanced error handling. 

Security Services: Navigator & Sentry vs. Atlas & Ranger 

Modern Apache Hadoop implementations use a combination of Apache Atlas and Apache Ranger. Both of these products achieve significant improvements over the legacy Navigator and Sentry. Atlas will be covered again later when highlighting data governance. Apache Ranger has a more user-friendly web-based interface that makes it easier to create and manage security policies. Unlike Sentry, Ranger includes built-in robust auditing capabilities for tracking events and activities across the platform, even outside of Hadoop proper.

To be fair, Cloudera is migrating to these improved options as well, but they are not there yet — leaving CDP implementers saddled with the complexity of a combined solution but unable to benefit from the full set of new features.

Back to top

2. Cloudera’s Proprietary Tools for Cluster Management, Cluster Administration, and Data Governance

Cloudera ships two proprietary applications, Cloudera Manager and Cloudera Navigator, to provide implementors with a toolkit for managing and administering their Hadoop Cluster. These applications are essential in offering a cohesive, professional, and useful Hadoop-based Big Data platform. 

However, there are open source alternatives that meet or beat the features available in these proprietary tools. In fact, the most predominant open source versions of these tools were originally developed in the open and handed over to the Apache Foundation by Hortonworks — a company that was purchased by Cloudera in 2019. 

Cloudera Manager vs. Ambari

Cloudera Manager is an administrative application for the Cloudera Data Platform (CDP). It has a web-based user interface and a programmatic API, and is used to provision, configure, manage, and monitor CDP-based Hadoop clusters and associated services.

Apache Hadoop implementors use Apache Ambari (a project with Hortonworks origins) to accomplish what is offered through Cloudera Manager on CDP Hadoop implementations. Apache Ambari has a web-based user interface and a programmatic REST API that allows organizations to provision, manage, and administer Hadoop clusters and associated services.

To take a deeper dive and learn more about the nuanced differences between these tools, see my previous blog: Apache Ambari vs Cloudera Manager. 

Cloudera Navigator vs. Apache Atlas

Cloudera Navigator handles data governance. It offers a wide range of features for auditing and compliance, from organization policy creation and tracking to regulatory requirements like GDPR and HIPPA. It also includes data lineage tracking to look back upon data transformation and evolution, as well as metadata management for tagging and categorizing data to assist in searching and filtering.

Apache Hadoop implementors use Apache Atlas (also originally developed by Hortonworks) to implement data governance and metadata management. Cloudera Navigator is only applicable to CDP, whereas Apache Atlas works across a broad range of Hadoop distributions and data ecosystems. It is extensible and integrates with other packages, like Apache Hive and Apache HBase.

Apache Atlas logs creation, modification, access, and lineage information about each data asset. It tracks who has accessed or modified data to provide an audit trail for compliance and monitoring purposes. Policies can be defined in Atlas to manage role-based access control (RBAC), attribute-based access control (ABAC), and data masking. To enforce these policies, Atlas integrates with Apache Ranger (another open source package in the Hadoop ecosystem).

Back to top

3. Cloudera’s Cloud-Hosting Environment and Managed Services

Measuring the value of where the infrastructure resides will likely be more of a policy question for most organizations. Most organizations have a preference or a requirement that dictates whether they host services in public, private, on-premises, or hybrid clouds. So the real assessment here lies more in the value aligned with the managed services offered by Cloudera. For organizations that are not required to manage and own their own infrastructure, and don’t mind paying for these managed services, this may tip the scales in Cloudera’s favor. 

However, organizations that don’t want to be forced to the cloud should consider whether they have the talent, motivation, and capacity to own and maintain an Apache Hadoop implementation. The maturity of the Hadoop ecosystem and the availability of standardized cloud resources make this a viable alternative to Cloudera — but only if you have the internal resources or a partner like OpenLogic with deep Apache Hadoop expertise.

Back to top

Other Considerations 

We outlined some key differences in cluster execution services, cluster security, cluster administration, and data governance between Apache Hadoop and CDP. However, there are a number of other features and functions that are nearly identical for both of these platforms that will require installation, configuration, care, and feeding. These include products like Zookeeper for cluster coordination, and a number of data services that can be applied to meet various needs of an organization. These include, but are not limited to, HDFS, MapReduce, Yarn, Apache Spark, Apache Kafka, HBase, Hive, and Hue.

Back to top

Final Thoughts

There was a time when it was easier to associate a clear value for the dollar spend on Cloudera. They were pioneers in Big Data and offered the first commercial bundle of Hadoop. They were the Hadoop provider for many of the Fortune 500 firms. The Cloudera Platform could speed time to market, providing a clear path to a stable Big Data environment that allowed implementers to focus on creating domain-specific applications that leveraged their data — rather than juggling between managing a data platform and making use of their data.

However, nearly two decades have passed since the first incarnation of Hadoop. Cloudera has been involved for over 15 years, and a lot has changed. Hadoop has matured dramatically, and the supporting ecosystem has grown. New open source solutions are being developed all the time, as well as new commercial offerings around Big Data services and support. While there is still an appetite for hands-off, fully managed Big Data platforms like the one that Cloudera offers, the price has driven demand for lower-cost alternatives. For some organizations, using Apache Hadoop and avoiding a costly cloud migration is priceless.  

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.

Planning an Apache Tomcat upgrade (or migrating to the latest version of Tomcat) can pose challenges to unsuspecting enterprises. But Tomcat migrations and upgrades are key to maintaining security and to unlocking the potential of newly-supported features and improvements found in later versions of Tomcat.

In this blog, we look at how to prepare for your next Tomcat upgrade, with details on the Tomcat community support lifecycle, considerations like how often enterprises should be upgrading/migrating, and the basic steps of performing an Apache Tomcat migration or upgrade.

Editor’s Note: This blog was originally published in 2022 and was updated in 2024.

Understanding the Apache Tomcat Lifecycle

There are two active branches of Tomcat at the time of this writing: 9 and 10. Tomcat 8.5 reached end of life (EOL) on March 31, 2024. The Tomcat community typically does a good job of communicating end of life at least a year in advance for versions going EOL. These EOL announcements are typically accompanied by news regarding the next major version; the Tomcat 8.5 EOL date was announced around the same time as information about Tomcat 11 first emerged.

Ultimately, which branch you choose is likely based on what version of Java you’re using along with it. The Tomcat website has a reference chart to help you figure out what versions of Java work with what versions of Tomcat.

What to Consider Before Your Apache Tomcat Migration or Upgrade

If you happen to be upgrading in the same major branch versions, your configuration file will likely transfer easily in between versions. This means your testing of minor releases should be relatively pain free and not take a lot of time and resources from your team.

Migrating from a major version to another, however, requires that you rewrite your configuration based around all the major changes incorporated into the new major version. Testing for this will take a greater amount of time and resources due to the nature of there being significant changes between major versions of Tomcat.

Reading the release notes is going to provide you with an overview of what to expect. Because of this, we advise you pick the newest version of Tomcat that you can, so that you get the longest range of time of support from the Apache community.

How Often Should You Upgrade Tomcat?

Some apps function so smoothly, we set them out in production and they do their job so well, that touching it becomes almost out of the question because if it isn’t broken, does it need fixing? That is a complicated question, because the answer can be circumstantial. If the app and infrastructure around it are all working soundly, you may not see any reason to do a minor upgrade. But then one day, you hear from the community that there is a CVE or more relating to a version that you’re currently using. Now, there’s a motivating factor to remediate the security issue. Keeping up with the security of Tomcat is important for anyone using it in a production environment, and the longer you wait to upgrade or migrate, the less smoothly things are likely to go.

How Often Should You Migrate to a New Tomcat Version?

Migrating to a newer Tomcat branch is a trickier task, since bringing over your configuration from the previous branch will not work. Migration will require significant testing to verify that your code will work with the app server. The more moving parts in play the greater the risk of older apps not being fully compatible.

Knowing the EOL dates ahead of time is going to give your organization the necessary heads up of when they will have a greater need to migrate.

Tomcat’s website states that on average a major release of Tomcat is good for 10 years. This is a significant window by comparison to other known application servers, giving your organization time to plan accordingly. Apache has also written specific documentation for migrating.

Back to top

How to Prepare for Your Next Apache Tomcat Upgrade / Migration

The very first thing to do before migration is to take back ups of everything. Document what sort of changes you’re going to be making to the environment so that you have an accurate account for everything you’re going to do. Going over metrics of when the app is in use will allow you to know when the best time to perform the migration is. 

Step #1: Determine Your Migration / Upgrade Path

Determine which version of Tomcat you will be upgrading to, along with the required version of Java that Tomcat requires. Read the release notes to see what sort of major changes you’ll be dealing with, as it might also give you insight to the new features available as well.

Step #2: Complete a Test Install and Compare Configuration Files

Using the same OS that you will be deploying your app on, set up the version of Tomcat you will be upgrading to in a test environment. Testing is critical for migration and is still a good practice for upgrades as well. One of the tests that you can run is a git command that compares configuration files against one another. An example of this command would look something like:

git diff 10.1.0-M1 10.1.0-M2 -- conf/

Step #3: Configure Your Test Install and Deploy Your Application to Test Environment

Configure your Tomcat instance and see if you can deploy your application in the test environment. Once you have your app up and running, you’ll want to do some testing to make sure it can handle the standard work load it’ll be under in production. The method you use to generate traffic to the server will vary depending on the type of application you’re running. It’s advised you push your server past the point that it might hit in production to prepare for any upticks in traffic. 

Step #4: Bring Test Environment to Production and Gradually Transition Workloads

Once you’ve done thorough testing of workloads on the new server, you’ll want to schedule time to bring your environment to production. The best practice is to stand the new servers up alongside the production servers, allow traffic to the new environment while maintaining the older live environment. When you’ve established that the new servers can properly handle live workloads, you may then take down the older servers one at a time, making sure that the new live servers are able to handle the workload gradually.

Back to top

Final Thoughts

With enough planning — and a proper test environment and traffic tools — you should be able to properly plan a fairly stress-free Tomcat upgrade or migration. While Tomcat versions are good for roughly ten years, there are performance gains and new features to be had when you decide to migrate or upgrade to a newer version. Upgrading and migrating should be a regular part of every organizations maintenance plan and is also critical for preventing exposure to security vulnerabilities.

In this blog, we look at eight ways to improve your Apache Tomcat security hardening, ranging from basic best practices like not running your Tomcat as the root user, to more advanced tips like using realms to control resource access. At the end of the blog, we’ll wrap up with some final thoughts about how to secure Tomcat and then link to some related resources you should check out. Let’s dive in!

Editor’s Note: This blog was originally published on December 29, 2020 and was revised and updated with new content on September 3, 2024. 

Why You Need to Secure Tomcat

Apache Tomcat is a robust application server that includes many features available right out of the box. However, just because these features and settings are available right away doesn’t mean that your Tomcat server is ready for production. Before you go to production, you need to perform thorough tuning and security hardening to ensure your Tomcat server is secure.

Back to top

How to Keep Your Tomcat Secure: 8 Tomcat Security Hardening Tips 

There are many ways to improve Apache Tomcat security, and this blog is no replacement for a thorough dive into the possible ways in which you can do so. However, the tips below are a good starting point for people interested in hardening their Tomcat server deployment.