This is probably not what a lot of the technology vendors want you to know. They want you to keep thinking that the secret is that new controller they offer, or maybe containerization of their cool new VNF. All of those things, and more, do indeed matter, but they are not what is going to make or break your NFV implementation.
An article the other day by Scott Raynovich on SDx Central points this out, and does a pretty good job of backing up the core message we at Itential have been trying to preach for the last couple of years. Traditional management tools aren’t going to cut it. So what are we supposed to do?
We have partnered with many companies that are focused on operationalization of your network. From the pre-Cisco days we have been working with Tail-f and the NSO product. That partnership has continued on with the Cisco acquisition and is producing some very cool results when it comes to upgrading the legacy network to a programmable state that positions service providers for the move to SDN and NFV. Not only is this operational tooling efficient and capable on top of the legacy network, but it is fully capable of managing your NFV/cloud infrastructures as well.
We also have partnered with Mirantis, one of the leading OpenStack distributions, to supply the base layer for NFV infrastructure implementations. Mirantis is the top contributor to the OpenStack code base as of right now, and they are committed to that continuing. Their core message is a “pure play” OpenStack environment. There are some good NFV focused things in the works with them as well. We also work with other distributions of OpenStack, of course.
On the controller side we recently partnered with Inocybe, which also focuses on the “pure play” approach, but in this case for OpenDaylight. There are implementation and operational tools brought to the table with Inocybe that allow us to focus on the operational areas key to engineering teams on a day to day basis. This equals faster success for our customers.
Those are some of our core partners, but not all. I am not trying to turn this into an Itential commercial, so I will get to the point.
The point is that you need a toolset that is:
- Fully integrated
- Easy to use
- Has a Federated view of:
- Configuration Data
- API functionality
- Service and Device (virtual and physical) Models
- Automates common activities across southbound systems
- Fills the gaps that legacy OSS usually ignores
Without the toolset above being in place NFV is going to bring nothing more than the same headaches you have experienced for years and years with legacy technologies. The secret sauce of NFV is that it results in a network that CAN be programmed. The secret sauce of success with NFV is having the tools in place to DO the programming of that network. Until those tools exist NFV will likely never be more than a lab experiment for much of your network needs.
The good news? These tools do exist, and are maturing more and more every day. I’ll toot the Itential horn a little and mention Pronghorn, but Pronghorn alone isn’t the answer to all your prayers. We would never presume to be the end all, be all of solutions. What Pronghorn does is consume APIs in order to expose southbound functionality to applications used by the ops folks northbound of our platform. What Pronghorn does is federate sources of data for service models, device models, inventory, configuration data…and does all of this regardless of if you are using legacy physical technology or virtual. Our apps focus on the gaps that other systems do not cover, and automating those activities to the point that you can have a junior resource watch over and conduct them via an easy to understand GUI, keeping your senior engineering resources free to focus on the real issues and new projects. We preach that list above, and we practice it every day in how we work to help service providers move into this new virtualized environment. It is our DNA.
THAT is the secret sauce. THAT is what we, and our partners, do. Want us to discuss how we can do this for YOU? Contact Us…