One of the big trends discussed at the OpenStack Summit in Austin a few weeks ago was the idea of disaggregation. While traditional thinking in the network world has been to aggregate as much as possible; in the NFV world the dominant model is quite the opposite.
First you have OpenStack itself, which is a conglomeration of dozens of projects integrated together to create your cloud environment. Every executive I have witnessed when first seeing the details of what this really means has a bit of a freak out moment. The words out of their mouths are inevitably, “how are we going to manage all of that!?”
The various distributions help bring some sanity to this picture by bundling a subset of the projects into a single “package” for you to implement. The projects selected are often related to providing for a certain specific set of use cases. As such, depending on your use case, one distribution may be much more appropriate than another. Under the covers it is not really any different than rolling your own OpenStack from the open source code, but the support models offered by these companies along with the distribution help abstract some of that complexity away from the Service Provider or Enterprise putting this environment in place. Another advantage is that these companies usually test the chosen projects extensively to provide you a “production hardened” environment to implement.
The power that disaggregation brings to the picture here is the ability for those companies offering distributions to bundle not only different projects together, but also different versions of those projects. You may notice some distributions having one bundled project on Liberty while another is still at the Kilo version, for example. This flexibility allows for companies like Mirantis and Red Hat to put together the best possible “package” for their customers.
When you go into the full ETSI NFV model, and in this case beyond the VIM/OpenStack, you will see similar situations with NFV Orchestrators and VNF Managers. These components can be mixed and matched to come up with the best possible NFV environment for your specific needs. A very powerful concept similar to the “best of breed” approach to OSS from many years ago. The problem, as seen in the past with OSS, is this can lead to integration headaches that you just don’t want to deal with. In the OSS domain this blocked many company’s efforts to ever really reach the level of automation and efficiency they had targeted.
Standards in the NFV space will help alleviate this issue, but only to the extent that vendors involved are willing to adhere to those standards. Traditionally, the big vendors just can’t seem to stay out of their own way when it comes to this situation. They all eventually come to think that the only way to “protect their turf” is to get more and more proprietary with their technologies. Even with the predominant theme of “we want to avoid vendor lock in” in the market today, many vendors still seem to want to build solutions that require you to buy product B from them if you happen to have selected product A, also from them. On paper this seems to make a lot of sense, but in the NFV space the growing maturity of open source solutions is going to bite them in the long run.
This brings us to what I believe is the most difficult thing about this disaggregated environment, upgrades. With the complicated integrations in place for all of these disparate pieces, it becomes a nightmare to go into an upgrade cycle. What dependencies exist between system A and system B…and C, D, E, and F…with regard to compatible versions? What order should, or do I HAVE to, upgrade the pieces in? Which integrations am I going to break? Etc.
There is not an easy answer to this challenge, and the answer for your company is not going to be the same answer for your competitors or partners. On the integration front implementing something similar to our Itential Application Platform, or possibly a very robust middleware solution, can help ease the concern by having that layer to manage the shifting requirements and functionalities. Having a good partner that understands all of these pieces, and can help guide you through the process, is another important insurance policy you can put in place.
The bottom line is if you are in the process of implementing NFV, or even the cloud in general, you need to think of these things sooner than later. Don’t wait until it is time to do an upgrade before considering HOW you should do an upgrade…or any other key operational task. “Proper Planning Prevents Poor Performance” is something I have heard my entire life, and it has never been more true than it is in this new world we are moving to.
Tags: Cloud Networking NetOps