Organizations that have been successful with OpenStack in production are those that possess significant technical sophistication. Service providers, like Comcast (News - Alert) and Rackspace, and carriers, like AT&T, are great examples.
Enterprises, by comparison, do not invest in the same kinds of in-house technical skill sets. To be sure, there are some exceptions, such as Fidelity. But, most enterprises want to consume products, not projects. They want someone else to take responsibility for making sure the stack functions as expected, with toothy SLAs that give them some assurance that everything works as advertised.
Like any open source software project, OpenStack is not a product. It’s not a cloud operating system. Rather, it’s akin to the Linux kernel – a set of critical and capable core components one can use to form the framework of a cloud operating system. This is the core reason why you’ve not seen a great deal of enterprise adoption of OpenStack yet. Products built on OpenStack are only now maturing to the point that enterprises can reliably and confidently consume them to achieve specific business goals.
Let’s take a closer look at the two models of OpenStack deployment. Neither is right, and one is not necessarily better than the other. Each has advantages and disadvantages. It is critical that you contemplate the differences and select the option with the highest probability of leading you to success in production.
DIY OpenStack works great if your IT team is culturally committed to a few open source projects already. If your team contributes code and speaks at open source conferences, that’s probably a good sign.
If you need OpenStack to support a very specific workload that has unique infrastructure requirements, DIY might make sense. Also, DIY a good option if you really need to understand the code at an intimate level.
DIY is slow. Yes, you can download OpenStack and spin up a cloud quickly. But, if you want that cloud to scale and support anything other than evaluation scenarios and DevTest, you’re going to need more time… Possibly a lot more time.
Also, DIY means you’re building an island for yourself, and you’ll be responsible for maintaining the deployment through semi-annual OpenStack code updates. Your documentation has to be spotless, because the people who build your cloud are going to be tempted to take a better offer, as the OpenStack hiring environment is red hot.
Consuming an OpenStack-Based Product
Consuming an OpenStack-based product reduces risk and generally moves you into production faster. A vendor takes on the responsibility for adding all of the pieces to OpenStack necessary to build a complete cloud, and also commits to maintaining it as each update rolls out at six-month intervals.
Products require support and maintenance contracts. Since lock-in can be thought of as a continuum, there is some degree of commitment to a particular vendor, even if you hold the source code. Finally, choosing a product means making some compromises, since it’s unlikely you’ll find a product with precisely the combination of features you’re looking for.
Some enterprises split the difference: they take on a DIY project strictly to evaluate OpenStack and become better educated to know what to look for when they choose a product for production. There’s no wrong way to get going with OpenStack. But, you should fully evaluate the pros and cons of the two major deployment options before opting for one or the other.
Edited by Maurice Nagle