Sometimes when deploying a service, a particular software version is needed. Let's take the example of a web application that runs on PHP. Now, suppose that your particular enterprise has, for historical reasons, standardized on CentOS 6 (or RHEL 6). This operating system only ships with PHP 5.3, meaning that if you suddenly take on an application that only supports PHP 7.0 and above, you need to figure out how to host this.

One apparently obvious solution to this would be to roll out a Fedora virtual machine image. After all, it shares similar technologies to CentOS and RHEL and has much more up-to-date libraries included with it. The author has direct experience of this kind of solution in several roles! However, let's take a look at the bigger picture.

RHEL (and CentOS, which is based upon this) has a lifespan of around 10 years, depending on the point at which you purchased it. In an enterprise, this is a valuable proposition—it means that you can guarantee that any servers you build will have patches and support for up to 10 years (and possibly longer with extended life cycle support) from the point at which you built them. This ties in nicely with our previous points around security, reliability, and supportability (in the following section).

However, any servers that you build on Fedora will have a lifespan of somewhere in the region of 12-18 months (depending on the Fedora release cycle)—in an enterprise setting, having to redeploy a server after, say, 12-18 months is a headache that is not needed.

This is not to say there is never a case for deploying on Fedora or any other fast-moving Linux platform—it is simply to state that in an enterprise where security and reliability are vitally important, you are unlikely to want a Linux platform with a short life cycle as the short term gain (newer library support) would be replaced in 12-18 months with the pain of a lack of updates and the need to rebuild/upgrade the platform. 

Of course, this does depend very much on your approach to your infrastructure—some enterprises take a very container-like approach to their servers and re-deploy them with every new software release or application deployment. When your infrastructure and build standards are defined by code (such as Ansible), then it is entirely possible to do this with a fairly minimal impact on your day-to-day operations, and it is unlikely that any single server would be around for long enough for the operating system to become outdated or unsupported.

At the end of the day, the choice is yours and you must establish which path you feel provides you with the most business benefit without putting your operations at risk. Part of standardization is to make sound, rational decisions on technology and to adopt them wherever feasible, and your standard could include frequent rebuilds such that you can use a fast-moving operating system such as Fedora. Equally, you might decide that your standard is that servers will have long lives and be upgraded in place, and in this case, you would be better choosing an operating system such as an Ubuntu LTS release or RHEL/CentOS. 

In the following section, we will look in greater detail at how an SOE benefits the concept of supportability in the next section.