If you have ever worked as a system administrator, you are familiar with developers constantly wanting to use the latest toolchains even to the point of wanting to roll their own packages. Of course, the challenge is, if you are running a production environment, introducing change is always risky. If the change being introduced is from an unknown source, the risk is even higher. As a result, many admins rely on companies like Red Hat to provide them some assurances regarding the quality of the components underpinning the applications. However, a company like Red Hat also has an interest in only supporting tools that are known to be stable and fault-free (as much as anything can be). Sometimes this doesn't meet the developers' needs. As a result, Red Hat has introduced (currently in Beta) the Red Hat Software Collections bundle to try to find a happy medium.
All that being said, and arguably said before in press releases and the like :), there is another interesting use case for the software collections concept. Specifically, what about when the developers and the business have essentially abandoned an application? In other words, the application delivers on its promises to customers already, and, at this point in time, there is no desire to invest further resources in the application. Well, what does that mean for you System Admins? Well, generally, it means you get caught holding the bag having to maintain an older toolchain just to support the application.
As a simple example, (prior to Software Collections) RHEL 5 supports Python 2.4 and RHEL 6 supports Python 2.6. Let's suppose that the application that supports your company's partner program was a website written in Python 2.4. Unfortunately, the partner program never generated the revenue the business was hoping for. However, it is still important that your company display an interest in partnerships. So, no new investment, even QE, will be made into the partner website. In theory, the application will, probably, run on RHEL 6 with Python 2.6 but, do you want to take that risk? Or, invest your weekend in testing? Not really. As a result, the production team gets to keep running RHEL 5 and Python 2.4 until forced to upgrade because RHEL 5 EOLs.
Now, enter a software collection. What if, instead of writing the application against the native Python 2.4 stack in RHEL 5, the development team had developed the application against the (imaginary) Python 2.4 Software Collection? And, let's just say, a company like Red Hat had provided that collection? With support? Well, wouldn't that be interesting? Because, you would imagine, the company would support the Python 2.4 Software Collection on RHEL.next (in this hypothetical case, RHEL 6). If that were the case, then, you could migrate the application from RHEL 5 + Python 2.4 Software Collection to RHEL 6 + Python 2.4 Software Collection and it should, "just work" (and, if it doesn't, there is a vendor you can call to get it fixed :) ).
What does this all net out to? Well, Software Collections can free you, the system administrator, from the vagaries of the development lifecycle. Freeing you to upgrade (or not) the operating systems of the servers in your environment independently of the development team's ability/time/whatnot to modify their application(s) thereby giving you the best of both worlds, meeting the ever changing needs of the developers while still providing supported, stable infrastructure in your data center. So, next time, when you want to roll out that fancy new hardware that is only supported in the latest and greatest version of RHEL, you can do so with impunity (well, mostly :) ).
Next I'll write about how this also can get you "into the cloud" or maybe it is just QED.
Last updated: April 5, 2018