One of the most overused phrases in the industry is orchestration. This is the case now, it was the case in the past, and it probably will continue to be in the future. It seems to be everyone’s answer to everything. Every vendor that has an “orchestrator” will promise you they can do anything you want, and this is true if you give them enough time and pay them enough money. You can “orchestrate” anything.
So what is orchestration and why should you care about it. An orchestrator automates and “arranges”, to borrow a musical term, the various parts and pieces of your environment. This can mean cloud components, OSS systems, network elements, BSS systems, and even manual tasks that may be required to make the entire thing work. The danger of overuse of this term is that a vendor can sell you on an orchestration story that covers a very specific use case, but leave you with the impression that anything and all things can be accomplished. The result is the purchase of multiple orchestrators that each perform well in their little world, but who is to orchestrate the orchestrators?
In the ETSI NFV model you have a few layers of orchestration to consider. There is the traditional, end-to-end orchestration that the OSS ecosystem brings, as well as the specific orchestration functions of the NFV Orchestrator, the VNF Manager and the VIM itself, which has to orchestrate the various components that make up the infrastructure. In most vendor solutions there is some cobbled together collection of tools that attempt to fulfill these roles. This is certainly not a mature space at this time, but it is getting there. There are a few vendors that are close, among them are NetCracker’s orchestration solution and an emerging offering from SeaStreet called StratOS.
The approach both of these take is to create a model based layer atop the orchestration that can work with underlying systems, even lower level orchestrators, to be an orchestrator of orchestrators. NetCracker uses standards based modeling such as YANG and TOSCA, while StratOS utilizes a patented modeling technique that goes beyond simple modeling and into full life cycle management of a service offering. Due to the approach they use, SeaStreet prefers not to refer to their product as an orchestration solution which is actually pretty refreshing…see “overused” comments above. This approach is somewhat embraced by NetCracker, as well as some of the other up and coming solutions out there.
The bottom line on how to proceed in this area?
- Consider the solutions you already have in place.
- What automation does it offer that can be leveraged by an orchestrator of orchestrator northbound? If it has most of the functions you need, maybe you don’t need that northbound solution…
- What can it do beyond what you use it for that could offset purchase of an “orchestrator”?
- Create an architectural vision of where you want to go, with no products listed. Only list functions you need to provide for your environment.
- Understand that you likely already have multiple “orchestrators” in place
- Understand that you likely already have a solution that can be leveraged in some way to mostly solve your issues
- Understand that it is OK to have point orchestration solutions, such as a cloud orchestrator and a network device orchestrator, that can’t go away, but can be integrated into a greater solution
- Understand that you don’t necessarily want a single “orchestrator” owning the entire process of talking to your Billing system all the way down to configuring a PE router in a MEF based service
- Understand that it is OK to have a “Best of Breed” environment, not all from one vendor, of “orchestrators” each doing what they do best, managed by a single entity that may be a custom middleware implementation that is orchestrating it all
- Overlay your vision with the existing products that you own and can perform each of the functions.
- Consider which existing solutions you can retire if you see lots of duplication.
- Consider the gaps in current functionality.
- Can you expand a current system?
- Are their solutions available that can fill all gaps, or at least multiple ones?
- Write RFP(s) specific to the gaps you have.
- Insist on new solutions giving a plan on how they will leverage existing functions and expose their capabilities in new ways for northbound systems.
- Consider existing systems that can go away with the new solution.
As always, the secret is to just methodically work through each step in evaluating solutions, AFTER you have defined in great detail what you need. Not such a secret, really.