Welcome to the Software-Define Stack Series, this will be an extensive series, exploring the software-defined aspects behind OpenStack and digging deeper into the structure of OpenStack and its internal anatomy.

Before I start to talk about OpenStack specifically, let me explain why this series is called the “Software-Defined” series. The term Software-Defined was first used to describe networks which follow these following patterns:

With time many vendors started adopting the term software-defined and mapping it to different technologies such as storage and compute, along the line, another school of thought emerged, the “Automation” school that is.

What we will be looking at in this series is how OpenStack really applies the Software-Defined paradigms (i.e., abstractions, decupling, and automation) from the different schools of thought. Without further ado, let’s start!


What is OpenStack?

You probably have read about OpenStack somewhere before you come here, but what is it really?!  I consider OpenStack a very big abstraction. The whole idea behind OpenStack is to bring together different components (e.g., networking, storage, and compute) under the same roof and allowing smooth communication between these components. The nice part here is that these components are built by different vendors.  Actually, vendors contribute huge amounts of code to OpenStack in order to rise and shine, at the end; it is all about meritocracy though. With OpenStack you get A LOT of choice on how to build your own IaaS or PaaS.

Every six months, OpenStack spins out a new release fixing bugs, adding new features, etc. The names of these releases are Alphatical (e.g., Austin, Bexar, Cactus, Diablo, Essex, Folsom, Grizzly, etc). The current release of OpenStack is Liberty (released October 2015), please refer to [1] for a complete list of release names.  Furthermore, many projected are developing within OpenStack each providing a distinct function, these projects include Horizon, Keystone, Nova, Cinder, Swift, Neutron, Glance, etc. We will be targeting each one individually in other episodes of this series, however, just to maintain a level of understanding, each service represents a function (e.g., storage, compute, networking, identity management, etc)


The OpenStack architecture is plugin-based, by default OpenStack comes with reference architecture for each of its services, however, the default settings can be easily be replaced In accordance with the use-case.

Why OpenStack?

The answer is dead-simple. It is because of the “Open” part in  OpenStack. Additionally, the DIY option.  Some (not all) the customers fancy building their own infrastructure from scratch, they feel more comfortable this way, so why put restrictions? With OpenStack we have many options; customers can do everything in-house OR can make use of a boxed solution which is wrapped around OpenStack with a lot of engineering around it. In both cases, OpenStack provides more flexibility, and that’s why it is appealing.

What’s next?

In the following episodes, we will be looking at the OpenStack architecture, the components, how they interact, and also looking at how OpenStack applies a Software-Defined patterns to provide everything-as-a-service.

Stay tuned!


[1] https://wiki.openstack.org/wiki/Release_Naming