The benefits -- and drawbacks -- of the enterprise OpenStack evolution

chris - Fotolia


CTO: Our quest for agility led us to the OpenStack framework

Niel Nickolaisen's abiding mission is to make IT a nimble partner to the business. The OpenStack framework has helped.

Everything we do in enterprise IT should lead to improved agility. Why is that? Because the future is being defined by innovations in technology and those innovations come quickly and furiously. As a result, I need to ensure that my systems, processes, technologies and leadership are nimble and easy to change.

That leads me to today's topic -- OpenStack. The OpenStack framework has been around for a reasonably long time. Even more important, OpenStack was an early manifestation of an approach purposefully designed to help us deliver agility. In the years since the OpenStack framework became available, others have created alternatives to OpenStack, but they are all built to do similar things: leverage commodity hardware, open standards, virtualization and orchestration tools to deliver fluid, portable and complete services (compute, storage and networking). With fluid, portable and complete IT services, we can flex, scale, move around and revise our services as needed. These are capabilities we need -- no, must have -- if we are to survive and thrive in a technology-driven marketplace.

Why OpenStack

May I share our OpenStack story? A few years ago, we did a reality check on our technology products and services. Being honest with ourselves, we recognized that our IT services were difficult and slow to change and therefore expensive to use. Some of our customers had voted with their feet by finding alternatives to using us and our services.

Once we were confident that we were not about to make a tragic mistake, we plunged in and started the sometimes challenging process of redoing what we had in order to fit our lives into the OpenStack framework.

During this reflection, we set some aggressive goals. One of the goals was to get to the point where we could do a deployment every day. Before setting out, we asked ourselves a series of "what must be true" questions to reach this daily deployment goal.

One of our most obvious "what must be true" answers was that we needed to leverage an infrastructure as a service (IaaS) and platform as a service (PaaS) that would enable scalable, flexible IT operations. An important requirement of the IaaS and PaaS platforms was support for containers. In order to avoid vendor lock-in we selected OpenStack as the framework for our IaaS. (Cloud Foundry is the framework for our PaaS and Docker is our container technology.)

OpenStack + Cloud Foundry + customizations

Now, making a major architecture and platform change is not something to take lightly -- migrating from our legacy approach to the IaaS/PaaS philosophy implied a lot of work and refactoring -- and so we spent a decent amount of time researching our options and doing a number of proof of concept projects. In fact, we were cautious enough that we actually operated two competing PaaS technologies for a number of months, so that we could find out through our experience which one was a better fit to our goals and needs.

Once we were confident that we were not about to make a tragic mistake, we plunged in and started the sometimes challenging process of redoing what we had in order to fit our lives into the OpenStack framework.

We started with one of the available implementations of OpenStack/Cloud Foundry. (As with Linux, you can go entirely open source or you can choose a supported version from a number of providers). But, as our knowledge and experience of the OpenStack framework grew, we identified some gaps that created issues around segregation of duties (which is critical for SOX, SOC 2 and other compliance standards). We began modifying our way into our own version, which includes some technologies we created to better handle application-level security and data access controls.

'Lego' model

Please bear in mind that our adoption and adaptation of the OpenStack and Cloud Foundry framework was part of our master plan to become more agile and nimble. To be agile, we need a "Lego" model for everything we do, including a microservices/API-centric architecture for the software we write. And, yes, we made missteps along the way.

We made some technology choices that turned out to be too limiting (one technology created an API bottleneck); another one of our early choices was just not ready for prime time. But because we were using standards-based tools and frameworks that were loosely coupled, it was not too painful to recover and move forward.

Indeed, our quest for agility has gone well -- in fact, really well. We don't need to do daily deployments, but our ability to do so is a marker of our agility. We still occasionally look at the alternatives to the OpenStack framework but have not found a compelling reason to make a switch.

For those who have not yet taken the OpenStack plunge, my advice is to do a pilot and explore what the OpenStack approach might do for you -- the risks are pretty low and, if it works for you, the benefits can be significant.

About the author:

Niel Nickolaisen is a veteran IT leader, currently serving as the CTO at O.C. Tanner Co., a Salt Lake City-based human resource consulting company that designs and implements employee recognition programs. A longtime SearchCIO columnist, Niel is a frequent writer and speaker on transforming IT and on IT leadership.

Next Steps

Recent Nickolaisen columns:

Seven tenets to live by when adopting DevOps

The IT lessons learned in 2016 point my way in 2017

Watch Niel's video on the importance of project prioritization

Dig Deeper on Cloud computing for business