The world of open source software consists of tens of thousands of projects that have been created because “someone had an itch and decided to scratch it” and others decided to join in to help move the vision forward. This is the true value of open source – it enables disparate teams of developers to come together to work on a solution for a problem. The drawback is that there is a corresponding trait of open source that if a problem is worth solving, it is worth solving at least twice.
So, we have two primary open source desktop environments – Gnome and KDE, with a few more less widely used – XFCE, LXDE, Cinnamon, … Is there a reason that we need all of these? Probably not, but different developers have to scratch different itches. Sometimes a new project is started because the author wants to use a different language or programming framework: Ruby vs Python vs Java (there are usually valid technical reasons for the choice but sometimes it is nothing more than the developer wanted to learn something new).
What ever the reason, the number of open source solutions is greater than the number of problems. The value that this delivers to the end customer in terms of rapid innovation and choice is considerable, but creates a secondary problem of making choices when developing or deploying an IT system becomes much more complex. And the complexity can rapidly become an exponential issue as most IT systems require multiple different point solutions to deliver the entire system, eg. database + app server + language + load balancer.
If you are responsible for running an enterprise IT shop, you don’t have the time, inclination, or perhaps even the skill needed to make all the decisions, so there have been some “standard” solutions such as a LAMP stack which delivers customers a web server consisting of Linux, Apache HTTP server, MySQL database and PHP for server side programming.
So far so good, if you want to stand up a web server, just use LAMP. The next questions are which version/release of each package do you use, how do you ensure they are configured to work with each other, and finally, if I need help resolving an issue, who will do it?
For the last 20 years, enterprises and open source companies have evolved a solution to this: the open source software vendor selects a set of packages at a specific version level, configures them to work together easily and delivers that to the end customers. The analogy I use is to a museum curator. Just as a curator selects from a number of museum pieces to create a coherent show, the open source software vendor selects a set of packages and puts them together into a coherent product – or distribution.
In the case of a Linux distribution, this consists of selecting a specific version of the Linux kernel, a particular release of the GCC tool chain and a set of products from among the 10,000+ options and configures them to work together. By using a distribution, the end customer has high confidence that all the components will work together.
The customer obviously loses some level of choice and control, but there are additional benefits: First, by selecting a subset of the universe and configuring it to all work together, the open source vendor can cost-effectively offer to support the end customer and address problems that arise with the installation and use of the software.
In addition to just addressing issues, the enterprise also wants a level of stability that most open source projects do not provide. Open source projects are frequently revised on 6-month cycles or faster and support from the community becomes unavailable within 18 or 24 months. This is frequently too fast for the enterprise customer that wants to deploy solutions that run for 5 years or more. By restricting support to fewer packages, the open source vendor can afford to maintain packages for these longer time frames.
This long term support not only means fixing problems that crop up, but also adding features from later releases of packages in a way that maintains the consistency of a customer’s deployed systems. This is especially prevalent with the Linux kernel and associated tool chains where it is not uncommon for a software provider to provide new Linux features on top of a distribution 5 years or more after first shipping the product.
SUSE has been delivering a fully supported Linux distribution for 20 years and currently provides 10 years of support for each major release, during which time application interfaces are maintained while bug fixes and security patches are delivered. We also work with hardware vendors to deliver and support a wide range of device drivers and software vendors to have them support their applications running on SUSE Linux Enterprise Server.
To summarize, we would say that the value of a Linux distribution is that it pulls together a limited set of open source packages (that provides the functions and features customers need), configures them to work together, fosters an ecosystem of hardware and software vendors to add value, and includes ongoing support, maintenance and test (if package A is updated, make sure that package B doesn’t break). Most distributions (including SUSE Linux Enterprise Server) also include scripts and a user interface to simplify installation and customer specific configuration during the installation.
Illustration 1: OpenStack Components shows the what is needed in addition to the OpenStack packages. The parts that are outlined in the box “Cloud” are what is needed just to configure and run OpenStack. Customers can choose to download the OpenStack packages, select an OS and hypervisor, install the database and message queue, and configure everything to work together. While perhaps not as complex as a full Linux distribution, most customers will not do this any more than they download and configure the components needed to run Linux themselves.
The reasons are two-fold:
1. It is complicated. With OpenStack Havana, there are over 1200 different parameters that need to be defined. You also need to make sure that you have the correct version of various packages so that they will work together seamlessly. We have heard of installations taking weeks to just set-up a basic cloud because of this complexity.
2. Support. Once a customer decides to go into production, they typically want to have a 3rd-party from whom they can get guidance and fixes in the event that something breaks. They also want a process that enables them to get access to the latest updates and security patches, preferably automatically.
A distribution addresses both of these problems. The distribution provider makes the decisions around which OS, database and message queue to use and configures all packages to work together. Larger distribution providers will also work with hardware vendors to make sure that drivers, or in the case of block storage and networking, adapters, are configured. Based on this up front work, the distribution provider can also provide support far more cost effectively because they have reduced the number of variables the customer needs to deal with.
In addition, an enterprise distribution will add management capabilities to simplify installation and operation. These can either be provided directly by the distribution vendor, or by leveraging the APIs in OpenStack to develop an ecosystem of certified partner solutions.
In summary, just as customers have learned over the years that a Linux distribution lowers the risk and overall cost of deploying Linux, they will see the same value in an OpenStack distribution.