Why did I choose Fedora Server?
I thought it would be a good idea to share my experience implementing servers for personal use. It wasn’t easy to know the best fit for my workload and it has been a moving target, so it was critical to understand and update my needs before taking one route or another.
There are plenty of articles discussing which OS is more appropriate, some will warn against Fedora Server or even CentOS Stream regarding stability, but all it comes down to the use case. So the context is what makes the difference.
RHEL is predictable with Insights as a bonus
I started using a RHEL (developer license) to implement my services. At the time it was the obvious choice, because I needed a predictable package versioning. I implemented various services using PHP and Databases which needed a consistent versioning of dependencies.
RHEL also gave me the additional bonus of Insights which is a convenient tool to see CVE’s, patches, and other interesting data. But apart from the initial hype while learning its capabilities, I stopped using it almost completely because my server was always up to date, and there wasn’t anything to see in the dashboard. I concluded, therefore, that despite the potential of Insights, it wasn’t something I really needed.
CentOS Stream brings you upgrades ahead of time
RHEL versioning helps cases where staying in one minor version for a long time is paramount to keep applications working. But it wasn’t my case. I was always upgrading through minor versions as soon as they were available. So I looked at CentOS Stream as an appealing alternative. It would give me the same stability with the additional benefit of getting the upgrades ahead of time. I made the move and migrated to CentOS Stream.
I was reluctant to use containers, in those days, thinking that having my workload installed directly in the server was more efficient. The presumption was that I was running Apache, MariaDB, Postgress, PHP, etc. only once. But there is a caveat with this simplified view because some of those services fork different instances to support the various requests anyway.
Moving services into containers
A realization came when one of the services needed a newer PHP version which wasn’t available in the standard repo. So I reverted to Modules to install the newer version. Unfortunately, I encountered some issues with dependencies on EPEL that wouldn’t work with some of the newer PHP packages. Also, not all my services worked well with the latest PHP, and so on, and so forth. Long story short; I scraped all services and implement them as containers.
It was like being born again. Each service running in their own optimized environment happened to be the perfect solution and I just kept Apache Server as reverse proxy.
I run my server in the cloud so resources were pretty limited. Surprisingly, the CPU and RAM consumption didn’t jump as I thought they would meaning that I didn’t have to upgrade my cloud service plan.
Fedora Server turned out to be the best fit
Everything was good until I started using Quadlet to implement my containers. Quadlet is an amazing tool that replaces the deprecated podman-generate-systemd to create systemd units to handle containers’ lifecycle.
Quadlet is available starting with Podman 4.6, but it is limited to single containers. The implementation of Pods will be only available starting with Podman 5.0. The plan is to include Podman 5.0 in Fedora 40 which in turn will branch out CentOS Stream 10. This means that if I stay on CentOS Stream, I will need to wait approximately 8 months to enjoy this new feature.
I was also looking for DNF5, but unfortunately it didn’t make on time to Fedora 40. This means it will only be available on CentOS Stream 11 in another 4 years. Who knows what other cool upgrades I may be missing or will miss in the future.
After the move to CentOS Stream, I came to another realization. I didn’t need a server with a predictable package versioning anymore. So you see where I’m going. On one hand, I’m not getting any particular benefit running CentOS Stream (or RHEL), because all my workload is containerized. On the other hand, I’m missing the latest software to make my life easier and more enjoyable. So moving to Fedora Server is a no brainier.
Another factor I didn’t think of before is the upgraded workflow. Staying with CentOS Stream doesn’t guarantee a pathway between major versions, so it is likely that I will need to do a fresh install. Whereas using Fedora Server guarantees a pathway and workflow to move between major releases.
So, all and all, the change makes so much sense for my use case. And I’m assuming this is a common scenario.