Author: Aaren DeJong


I will admit the title is a touch sensationalized, but let me elaborate before you jump to something less “click-bait”-ey. In the past 6-8 months or so (the time span may actually be longer) I have noticed a number of newly built projects that rely on an underlying COMPLETE O/S and select a non-RHEL base. They are starting up in Ubuntu, Fedora, Arch, or even custom spins or distros based on Debian or Fedora. Let me be clear - there is nothing wrong with this! This is great for the Linux and open source O/S community as a whole!

When I started in this industry Linux was reserved for labs and web servers, and I’ve been very happy to see it mature into a Mission Critical data centre grade O/S. However, as mentioned, I’m seeing somewhat of an alternate trend in faster moving cost-conscious organizations. Where it becomes somewhat troublesome, is that I fear the decisions of the base O/S might sometimes be stemming purely from fear of the unknown.

Essentially, I’d like to make 2 point in this blog:

  1. RHEL 7.5 has some exciting features coming, and;
  2. Developers should give RHEL a second chance

So why is this a concern? There is a section of the market that isn’t established enterprise, but rather startup or medium size businesses. There are also many shops that start with Ubuntu for its “closer to the edge” software availability (media houses, game developers, etc.). It’s in those startups where it seems that RHEL gets tossed to the back-burner as the O/S of choice. Sometimes this happens due to lack of features, but often the desire to maintain the “free” aspect of using open source.

To quickly address the costs, consider downloading the free RHEL Developer subscription (This blog details it well). Developers get access to an incredible suite of repositories from Red Hat, as well as the latest RHEL of course, and all they ask for is that you have or create a Red Hat portal account.

As the Linux-bound industry progresses, I believe gradually there will be larger gaps between the popular and unpopular Linux distributions in all types of businesses using Linux. RHEL will soon demand more presence because of how much it permeates the tools Linux shops want to use. In the cloud we don’t see RHEL 100% of the time, but where it is, there’s a lot of image customization going on, to accommodate specific needs.

  • AWS has their own minimal instance flavour of Linux,
  • Azure has RHEL, but it’s not identical to uploading a RHEL image
  • Digital Ocean offers several non-supported Linux, and no RHEL at all
  • GCP has RHEL, but it’s also not identical to uploading a RHEL image
  • Packet.net (doesn’t explicitly offer RHEL, but) offers several non-supported Linux

In most cases we can upload a custom image (i.e., RHEL direct from Red Hat) and while this is convenient and even sometimes a ‘best-practice’ I’m sure there are a number of users who simply use what’s provided in cloud marketplaces, rather than going through further motions over a measly O/S. Developers who have options that aren’t Linux-Ops-savvy, but understand they need a Linux environment might go the path of least resistance and use what’s typical or provided. Those are the cases where I would argue that RHEL deserves a shot! These are some considerations for selecting an O/S for practically any business use:

RHEL Atomic

code

If you’re familiar with project atomic, all our favourite enterprise Linux now have container-platformed O/S flavours. RHEL Atomic, CentOS Atomic, and Fedora Atomic are all available. In recent lab testing, our team has found an ever more expedient and convenient Openshift buildout using RHEL Atomic. This is a good sign for wanting RHEL Atomic to popularize in cloud and community. Personally, I wish I had started getting to know the Atomic distros sooner!

CoreOS & Red Hat

code

We are all aware of the recent Red Hat acquisition of CoreOS. This brings a lot of container related talent closer to the RHEL platform development community. Similarly bringing a lot of technology into Openshift, possibly RHV (RHEV), and potentially even OpenStack. We would be smart to assume that there is going to be a ripple effect from the RHEL O/S platform, because it permeates all of Red Hat’s products. As for choice this time, if your use-case works with CoreOS or RHEL (and its derivatives), then they’re both excellent choices, given their tech will likely intertwine due to the acquisition.

VDO (from Permabit)

permabit

Red Hat also recently acquired Permabit, which is bound to cause further ripple effects. VDO for storage, in nearly any use-case, brings resource-inexpensive deduplication, zero-block omission, and live compression. Putting this underneath the Red Hat ecosystem products allows a sudden vast reduction of storage consumption. Think about it…12 VMs with the same O/S, living on a VDO based volume in a hypervisor - that’s 12-to-1 deduplication where common blocks of data exist. Here, our choice is going to be any O/S that either bakes-in VDO (RHEL, Fedora, then later CentOS) or any distro for those that are fine with building in VDO from source, and then it depends on your support needs.

The Ecosystem Effect!

ansible awx

The fantastic bonus of the above is, as we’ve seen in the past, Red Hat open sources everything they acquire into upstream or downstream projects! Ansible Tower was even released as Ansible AWX for open source. RHEL’s open source upstream is CentOS. I simply can’t wait to see the CoreOS and VDO feature sets merged into RHEL and also CentOS or some other form of open-source delivery format.

Now, more than ever, the underlying O/S can be a significant differentiator. Red Hat has the opportunity to become THE recommended Linux distribution for enterprise grade functionality AND fresh development projects.

I am looking forward to presenting about VDO at the next Toronto RHUG meetup on April 4th, 2018. Drop by, take the first step, and let’s discuss the future of Linux!

Tagged:



//comments