OpenStack has been gaining a lot of news coverage recently, which means that a lot of people in your company are already thinking about it, so here are some tips to try to sort out the hype from reality.
As a Service Provider, you are probably already implementing (or at least forming) cloud plans and you may be wondering how to fit OpenStack into them.
OpenStack is at the top of the hype curve at the moment, which means it is gaining coverage to the exclusion of almost all other cloud systems. This doesn’t mean it’s the best option at the moment, just that everyone is talking about it.
One of the problems of this type of hype bubble is it sucks the air (and sometimes even the investment) out of other competitive systems, causing OpenStack to act as a disrupter to a lot of companies who are producing cloud management platforms (CMPs); they will be struggling internally to decide what to do about OpenStack and that struggle may spill over into product plans.
So, what should service providers do with OpenStack today? Is OpenStack the right platform for the services and workloads you want to enable for your customers? Let’s separate the hype from the reality and evaluate options to move forward with OpenStack from a Service Provider perspective.
The first thing to consider is should you as a Service Provider be looking at OpenStack to be your CMP? This is one of the hardest questions to answer because it depends on your capabilities from an administration and technical point of view, so we’ll try to look at general guidance based on some hypotheticals.
Because OpenStack is on the hype curve, it is pulling in a significant amount of money and development talent. This certainly makes it the best resourced CMP project on earth. In fact, Parallels has recently become a corporate sponsor of the OpenStack Foundation and is working within the community to help optimize OpenStack orchestration for the service provider industry. It is reasonably certain, barring some type of project implosion, that with this wealth of resources, OpenStack will eventually deliver on the hype in some form.
However, it is important to remember that OpenStack, like most Open Source projects, is being built by developers for developers and it’s currently evolving rapidly as resources pile into the project; just to bring this point home: it is not currently possible to upgrade easily from last year’s Grizzly release to the current year’s Havana without a lot of manual intervention.
This means two things. Firstly, the level of stability and maturity available from the Open Source repositories is not high, and secondly it’s not at all easy to deploy or administer and not all the features that a Service Provider would need are currently present. If you are looking to set up and export an end user-facing cloud based on OpenStack, the features and maturity issues would make it a very risky proposition at the current time (and would necessitate developing some components, like billing, in-house).
A more viable plan might be to use OpenStack to manage an internal cluster of nodes from which you could export SaaS services to the outside world by way of your existing hosting system. The advantage of doing it this way is most of the rough edges are hidden, you can continue to use your current billing system and it gives your staff hands-on learning about what OpenStack can and cannot do.
Of course, it still requires that you have the necessary technical and administration resources available to manage this internal cluster, which makes it viable only for large Service Providers who have a stable of experts on hand.
If you are a Service Provider who cannot afford the dedicated resources to tackle your own installation, the next best plan for at least playing with OpenStack is to turn to one of the canned distributions (Ubuntu, Mirantis or Red Hat spring instantly to mind, but a web search will turn up about a dozen others).
Using a distribution should allow you to get a pre-packaged installation which will get you over most of the deployment problems. However, the price of using a distribution is that you are now tied to whatever the distribution provides and the internal API instability of OpenStack makes it all but impossible for you to download the cool X module and just try it out.
If you’re a small enough Service Provider that you’re starting to worry even about this expenditure of resources, you should probably wait a bit until at least the upgrade and some of the installation problems are solved before trying OpenStack in anything other than a laboratory test environment.
The final thing to consider, going back to the “developed by developers for developers” point is this: unless you have considerable internal resources and open source expertise, you’re going to find it difficult to influence the OpenStack community to add features that you as a Service Provider need.
This means you will have to pick a trusted partner who is involved in the OpenStack community as part of their business and who will be attuned to your needs, so they will, in their own business interests, proxy your requirements to the upstream community and apply the correct influence or code development pressures to get them attended to.
So, in conclusion, OpenStack is not mature enough today to deploy customer-facing services; it is getting the most resource input of any CMP which does promise to make it the most comprehensive platform and thus you should be considering how you might make use of OpenStack. However, now is definitely the time to be garnering OpenStack expertise and experience and picking the correct partner or software provider rather than rushing to premature deployment.