Before we delve into the definition of an SOE, let's explore the challenges of scaling a Linux environment without standards. An exploration of this will help us to understand the definition itself, as well as how to define the right standards for a given scenario.

It is important to consider that many challenges experienced by enterprises with technology estates (whether Linux or otherwise) do not start out as such. In the early stages of growth, in fact, many systems and processes are entirely sustainable, and in the next section, we will look at this early stage of environment growth as a precursor to understanding the...

Now that we've explored the reasons why an SOE is important to the enterprise and understood at a high level the solutions for these problems, let's look in detail at an SOE. We will begin by defining the SOE itself.

Let's take a quick look at this from a more practical standpoint. As we have already said, an SOE is a concept, not an absolute. It is, at its simplest level, a common server image or build standard that is deployed across a large number of servers throughout a company. Here, all required tasks are completed in a known, documented manner.

To start with, there is the base operating system—and, as we have discussed, there are hundreds of Linux distributions...

By now, you should have some idea of what an SOE is, and how it brings economies of scale and greater efficiency to a Linux environment. Now, let's build on that and look in more detail at an example of the importance of standardization.

To say that there are commonalities in a Linux environment is to say that the servers that comprise it all share attributes and features. For example, they might all be built upon Ubuntu Linux, or they might all have Apache as their web server.

We can explore this concept with an example. Suppose that you have 10 Linux web servers behind a load balancer and that they are all serving simple static content. Everything...

It would be easy to oversell the benefits of standardization, and they are certainly a requirement for automation to be effective. However, like anything, it can be taken too far. There is no point, for example, building servers on top of Red Hat Enterprise Linux 5.7 in 2019 simply because this was once defined as a standard (it is now End of Life and no longer supported or updated). Similarly, from time to time, software vendors will have qualified their product on certain specific Linux distributions or application stacks and will not provide support unless their software is run within that ecosystem.

These are cases when deviations from the SOE are necessary, but they should be performed in a controlled manner. For example, if a business has built up its Linux server estate on Ubuntu 18.04 LTS, and then a new software stack is purchased...

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...

SOEs are a valuable addition to technology processes in almost any environment. They require some time to be spent upfront on design work and defining standards, but this time is more than offset later on as it supports efficient and effective automation of the environments, and in this manner, actually gives time back to those responsible for the environment, giving them more time to work on evaluating new technologies, finding more efficient ways to do things, and being innovative in general.

In this chapter, you learned the fundamental definition of an SOE. You explored the benefits that they bring to just about any Linux environment where scale is important, how they support automation, and when and how to make deviations from the standards to ensure that they do not become overly rigid and hamper growth. Finally, you learned about the importance of ongoing maintenance...

1. What does the acronym SOE stand for?
2. Why would you choose an operating system with a long support cycle, such as CentOS, rather than one with a more rapid release cycle, such as Fedora?
3. Should you ever deviate from the standards you have defined for your environment?
4. List three challenges of scaling Linux environments up to enterprise scale.
5. Name three benefits that SOEs bring to Linux in the enterprise.
6. How does an SOE help to reduce the training requirements in an enterprise?
7. Why does an SOE benefit the security of your Linux environment?

• To learn more about SOEs from a Red Hat perspective, refer to this article: https://servicesblog.redhat.com/2016/11/03/standard-operating-environment-part-i-concepts-and-structures/.