Why should I standardize my operating system?

"Was it yum?"

"Maybe it was apt-get."

"Oh wait, no… What operating system am I using again?!"

Sound familiar to anyone? As a systems administrator, supporting Windows, Unix and Linux systems wasn't uncommon. Not to mention, I would be faced with running Ubuntu, CentOS Linux, Red Hat Enterprise Linux (RHEL) and those weird appliance distros that loosely represented a distribution. Then don't get me started on the various major versions that would be in production at any one time!

This problem, even a decade later, is still a very real issue. Distribution sprawl has probably gotten worse. Now we have cloud providers where anyone with a corporate credit card can spin up a system in minutes, anywhere they like, running whatever distribution they want! Add that to the existing sprawl of physical and virtual systems, and you end up with…well, a mess within a mess.

Why should I standardize?

Not to be too direct, but you should standardize to avoid what the scenarios described above! Resources are limited: time, hardware and budget, not to mention the patience of those who manage your infrastructure.

Learning a new skill or habit takes time; it takes consistent, repetitive effort to ingrain it into our intellectual muscle memory. The problem that many of us face is that our disparate servers are "not-quite identical." 

I was a sysadmin when RHEL and others transitioned from init to systemd. Later, I worked with systems as they began to introduce Network Manager. These changes introduced some strife as I had to 1) learn the new technology and 2) keep straight in my head which environments utilized which subsystem.

Standardizing your infrastructure breeds efficiency. Using the same tools and commands across your environments makes it easier to duplicate tasks (even easier if you automate them).

Standardizing decreases error. If you change a network configuration, you run less risk of implementing the wrong protocol or using the incorrect syntax.

Standardizing also decreases time to market. One of the greatest inventions of all time has proven to be the assembly line: Create a whole bunch of parts precisely the same way and put them together. The same can be true of our operating systems.

What can I do to manage the sprawl?

I highly doubt that doing a Control+A Delete (keyboard shortcut for selecting all and deleting it) will be an acceptable solution to anyone, so instead, we have to think strategically. Ask yourself a couple of questions:

• What are my most important applications?
• What are my oldest (read: at risk) applications?

This process can't be a numbers game; it can't be about migrating all 100, 1,000 or 10,000 servers in one go. Target the most critical and the most at-risk workloads. Plan to address these systems in groups: database servers, web servers and utility servers.

Pro tip: Systems administrators pretty much always have some "jump boxes" or "utility servers." These are usually low-priority, low-impact servers. They make excellent test beds for migrating or rebuilding onto the new standard.

Overall, you'll likely need to:

• Convert RPM-based systems to a single operating system 
• Manually migrate workloads from non-RPM systems onto your new standard build
• Perform in-place upgrades to bring your fleet onto a reasonable build level
• Manually rebuild whatever is left

Luckily, today, we have automation tools, image builders and concepts like Infrastructure as Code that can help ease this process.

How do I standardize with Red Hat?

I know I am a bit biased because Red Hat pays my salary. However, even if I were a sysadmin today, I couldn't think of a better platform to standardize my operating systems.

Red Hat has several tools that makes this process easier than ever:

• Red Hat Enterprise Linux: RHEL has a predictable life cycle and supports multiple major versions anytime
• Image builder: You can use either the self-hosted or our service-based image builder tool to create standardized images pre-populated with users, file system layouts, packages and configurations
• Convert2RHEL: Use our conversion tool to migrate from RHEL-like, RPM-based systems onto RHEL-proper
• Leapp: RHEL carries with it an in-place upgrade utility that helps to save you time and effort when moving between major versions
• Red Hat Insights: Provides high-level monitoring of CVEs, patch levels, configuration drift and over 15 other services to help manage your RHEL environment
• Red Hat Satellite: Helps you maintain local repositories and manage patches and your server lifecycle
• Red Hat Ansible Automation Platform: Allows you to create standardized job templates, define system profiles and proactively deploy and maintain your servers with Ansible Playbooks

Why should I standardize now?

In the coming months, we're going to see a considerable shift in the enterprise Linux ecosystem:

May 31st, 2024

• CentOS Stream 8 will reach the end of the builds
• RHEL 8 starts maintenance (leaves full support)

June 30th, 2024

• CentOS Linux 7 will reach the end of its life
• Red Hat Enterprise Linux 6 will reach the end of Extended Life Cycle Support (ELS) 
• RHEL 7 will reach the end of maintenance

There is no better time than today to start the journey towards a standardized environment. Don't push this off, it will only become more complicated from here.

If you want to dive deeper into the idea of standardization, check out this article recently published by Jerone Young, one of our amazing architects here at Red Hat!