Although we will look at patching and maintenance in much greater detail later in this book, it deserves a mention here as it dovetails nicely into the discussion on commonality and deviations.
If nothing else, you are going to have to patch your Linux environment. For security reasons alone, this is a given and good practice, even in an air-gapped environment. Let's say that your environment is made up entirely of virtual machines and that you decided to standardize on CentOS 7.2 some time ago. You built a virtual machine, performed all of the required configuration steps to turn it into your SOE image, and then converted it into a template for your virtualization environment. This becomes your gold build. So far, so good.
However, CentOS 7.2 was released in December 2015, nearly 4 years ago at the time of writing, and if you were to deploy such an image today, the first thing you would have to do is patch it. This would, depending on the build definition (and the number of packages included in it), possibly involve downloading a gigabyte or more of packages to bring it up to the latest standard and ensure you were running with all discovered vulnerabilities patched, and all of the requisite bug fixes in place.
Obviously, if you are doing this at scale, this is inefficient—each new server is going to pull all that data down over the network (or worse, the internet, if you don't have an internal mirror), and then consume a great deal of I/O time and CPU time applying the patches, during which the server can't be used for anything meaningful. If you only deploy one server every few months, you can probably put up with this. If you deploy them on a more regular basis, then this is going to waste a lot of valuable time and resources.
Hence, as well as performing ongoing maintenance of your environment itself, it is important to perform ongoing maintenance of your standards. In 2019, it makes sense to update your CentOS build to 7.6. At the very least, your ongoing maintenance schedule should involve updating the gold build regularly.
We will go into much greater detail on how this might be performed later in this book. However, for those who are eager to know now, this might be as simple as booting the virtual machine image up, performing the updates, sanitizing it (for example, removing SSH host keys that would be duplicated when the template is cloned), and then creating a new template from it. Obviously, if any other changes to the SOE have been made since the last maintenance cycle, then these can be incorporated too.
You should expect your SOE to evolve over time—it would be easy perhaps to labor this point—but there is an important balance between creating and maintaining standards, and being overly rigid with them. You must accept that there are times when you will need to deviate from them as we discussed in the previous section and that, over time, they will evolve.
In short, SOEs should become a part of your regular IT processes; if employed correctly, they don't hinder innovation— instead, they actively support it by giving back time to those working with them and ensuring they spend less time performing mundane, repetitive tasks and hence have more time for evaluating new technologies and finding better ways of doing things. This, after all, is one of the key benefits of automation, which SOEs support directly.