We often tell our stakeholders that Orchestration is a general term, and we need to clarify what are the different types of Orchestrators available to apply in their network architecture.
In this blog, I will give an overview of various aspects of Orchestrators, since not all are created equal.
This can help decision makers choose what works for their organizational needs.
So what do orchestrators do?? In short, they perform things like:
Next comes the scope of Orchestration functionality. This can be simplified into Day-0 or Day-N management. Some Orchestrators (typically the ones used on public clouds) usually perform only Day-0, which is to spin up the required resources for the operation of the function (Infrastructure, network functions, etc.). If any changes need to be made during the life of these resources (e.g., they need to be reconfigured, either manually or based on some configurable policies), there is no mechanism for doing so. The latter functionality is known as Day-N orchestration/management, also referred to as LCM (Life Cycle Management).
This itself has two distinct functions -- monitoring and taking actions (open loop or closed loop). Either the Orchestrator performs both of these functions, or it relies on other tools/utilities to monitor, and can simply perform corrective actions, such as the reconfigurations. In the virtualized world (VNF/CNFs), the reconfiguration could also include healing, scaling-in, scaling-out, etc.
Scalability is another important factor in choosing the Orchestrator. If your use cases need to be run on Edge networks (Enterprise Edge or Cloud Edge, also known as the New Middle Mile), it needs to be a lot more scalable compared to Cloud scale (those confined to few public cloud locations and clusters). The number of Network services and Applications (including the vendors) is also an order of magnitude more in case of Edge networks (1000s as opposed to 10s).
There is another twist to this tale -- some Orchestrators may be vendor or cloud-specific, which work well for the proprietary vendor or cloud resources, but obviously cannot be used for other vendor products or clouds. So if your environment is multi-cloud/multi-vendor, this option may not be suitable for you.
Independent of the above (but somewhat related in reality) is the openness of the Orchestrator implementations -- whether they are closed source implementations (proprietary) or open source based. In theory, the Orchestrator could be working with proprietary target functions but could be open source based (or vice versa). But in practice, they go hand in hand.
Lastly, some orchestrators may be specific to a particular domain (e.g., 5G Core, Transport or RAN). O-RAN Service Management and Orchestration (SMO), as the name implies, is an example of an Orchestrator that is specific to the RAN domain.
There is another category of vendors who offer Cloud Networking, which are also sometimes referred to as Orchestrators. But their functions are typically meant for specific networking use cases such as SD-WAN, MPLS Replacement, etc.
Regardless of their specific functions (which includes any of those mentioned above), there is another nuance to the way the solution is offered, which could be either as a Technology provider or a Service Provider. The former provides a level of customization that may be necessary for specific use cases or environments, whereas the latter (though well-packaged) is typically a fixed function.
With so many variations and nuances, users need to think through their specific organizational needs (present and future) before deciding on which solution to choose from the choices available.
I hope this sheds some light on the topic and gives some clarity on how to go about choosing a vendor. At Aarna Networks, we offer open source, zero-touch, orchestrator, AMCOP (also offered as a SaaS AES) for lifecycle management, real-time policy, and closed loop automation for edge and 5G services. If you’d like to discuss your orchestration needs, please contact us for a free consultation.
