OpenStack, Then and Now, 2013 to 2015

We’ve just entered 2015, and we’re working with OpenStack Juno, eagerly awaiting OpenStack Kilo, which will be out on April 30 of this year.  The trendy thing would be to talk about how OpenStack has grown and evolved over the last year, 2014, but let’s dig a little deeper. Come with me into the OpenStack time machine, and let’s see where we were two years ago, in January 2013.

Blast From the Past
Two years ago, in January 2013, OpenStack Folsom was the current release, having come out in September 2012.  When we deployed OpenStack Folsom, we deployed features like Swift (Object Storage), Cinder (Block Storage), Nova (Compute), Glance (Image Service), Horizon (Dashboard), Keystone (Identity), and Quantum (Network Service…what?).  In fact, it was in Folsom that Quantum, or Networking became a core project.  If you’ve started with a later release of OpenStack, you’ve probably never even heard of Quantum, which later became OpenStack Neutron.  According to OpenStack, there were 6,990 commits, and 368 developers.

The Future is Now
Now, let’s fast forward to today, and take a look at OpenStack Juno.  We’ve got all the above programs (in the last two years, we’ve stopped referring to them as projects, and started referring them to programs), plus a slew of new additions.  We’ve welcomed Celiometer (Telemetry), Heat (Orchestration), Trove (Database Service), and Sahara (Data Processing, which also had a bit of an identity crisis, and was previously know as Savanna).  That’s a new addition of four major programs over the last two year, and doesn’t account for anything currently in incubation or anything external.  There were 18,992 commits, and 1,433 developers.

In just two years, commits have increased by over 171%, developers by over 292%, and projects by 57%.  You may take a look at the increase in projects, and think the number is low, but remember, programs are first incubated for a release cycle, and then become an official program.  There’s also hundreds of programs that are still external programs, and haven’t yet made it to incubated status.

So what does this all mean?  Well, numbers don’t lie, and it is easy to see how much steam has come out of the OpenStack in the last two years.  If we hop back into our OpenStack time machine and get it up to 88 miles per hour (also known as going to stackalytics.com, and selecting commits), we can see just how much contributions have increased.

(stackalytics.com is a great way to see how the involvement in OpenStack has grown over time)

So what does this momentum mean for everyone exactly.  Sure, it means more people are working on it, using it, and therefore find it an interesting concept, but what does this mean for the architects, administrators, and CIOs out there?  It means it is time to take a look at OpenStack.  Notice, I didn’t say it is time to deploy OpenStack, which is a decision for each individual organization to make.  It is time to look at OpenStack, and decide if it is right for you now, or may be right for you later.  If it isn’t a fit for you right now, it may mean it is at least time to kick the tires in your lab, to get a better understanding of OpenStack’s features and functionality, and what they mean to the business your IT organization supports.  Or, you may take a look at OpenStack, and decide you’re not going to deploy it anytime in the near future, or maybe even never.

The reason I say it is time to look, is that while some of the concepts are the same, after all, OpenStack is a cloud operating system, it isn’t the same as deploying a platform for virtualization.  If an organization isn’t virtualized, but converts everything in sight to a virtual sever, they can be rather successful.  The organization will still see power and cooling benefits, a reduced data center footprint, and operational efficiencies, even if they don’t change a single thing about their current operating model.  This would still be considered a successful virtualization deployment.

If you deploy OpenStack, and don’t change the way anything is done, sure, it will still work, but you may not see all the benefits.  One of OpenStack’s strong suits is the ability to deploy a complete application stack quickly and efficiently.  If you don’t have a streamlined process in place for that application to start with, it may be difficult to do in OpenStack.  If you don’t have streamlined development cycles, you may not even see the benefit of deploying an application quickly and easily in a repeatable fashion.

That’s why it is time to start kicking the tires.  It is time to put this in our lab, and get a sense on how things work.  While we do that, it is also time to start looking at our processes and procedures, to see how they can benefit from orchestration and automation, or maybe just to get them down on paper to start with.

Melissa Palmer

Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security.  She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.