Genie in a Network (GIN) – Service Orchestrator

CCI’s Genie in a Network (GIN)™ service orchestrator is one of the key components of its comprehensive next-generation GIN network lifecycle platform.

The GIN service orchestrator is a TOSCA-based service orchestrator that addresses the challenges of handling increased need for automation, being cloud native, and dealing with infrastructure on which it runs. It can handle a comprehensive model of a service including resources, workflows, policies, and analytics it depends on – all defined in one location. The GIN orchestrator supports the basic principles of a SOA with the implementations of a service domain provided by a related set of microservices. The GIN Orchestrator comes with a rich set of APIs that allow it to be independently integrated into other management platforms. GIN shields the complexity of discovering, registering, managing, and routing its API calls behind an API gateway. It employs Apache APISIX as an API Gateway for its platform. It is an opensource cloud native API gateway based on NGINX and etcd and comes with a GUI dashboard. The cloud native nature of the orchestration solution automatically makes available all the resources and capabilities of such an environment. It includes key infrastructure features such as scaling up/down individual components based on usage for more efficient use of infrastructure, load balancing and resiliency of components, configuration and state data storage, portability across heterogeneous environments, etc.

It adopts a number of core foundational principles to tackle the complexity of modern network deployments:

Declarative – A declarative approach reduces complexity. It focuses on the “what” rather than the “how”. The automation platform translates the declarative to the imperative.

Model-Driven – A model-driven approach provides a consistent set of models used by all platform components. It helps automation by using the meta-model or “modeling language” to define the automation functionality associated with the modeled components.

End-to-End – Service designers and network function designers can design all aspects of the service in one place. Service and network function deployment packages support all aspects of Day 0 design, and Day 1 deployment, including service assurance.

Comprehensive – End-to-end automation systems must not only handle lifecycles and assurance of services and network functions, but also the infrastructure on which network functions are hosted.

Cloud-Native – A cloud-native system helps facilitate a loosely-coupled event-driven architecture over tightly-coupled monolithic systems. It allows us to dynamically scale network management functions and make them easily distributable all the way to the edge.

Open and Extensible – The architecture supports open interfaces (APIs) to integrate with existing management systems and to support addition of custom management functionality.

These foundational principles allow true automation without adding complexity.

The key features of the platform can be summarized as follows:

Consistent TOSCA based models for Day 1 orchestration and Day 2 operation, removing the need for subdomain orchestrators like APPC, VNFC, and SDNC.
Inferred workflows from relationships defined in the service model
Explicit workflows can also be specified in the TOSCA model. No separate definition required in an external workflow engine.
Policies can be specified in the TOSCA model. No separate definition required in an external policy framework/engine.
Monitoring and analytics designed in conjunction with services and service components, and bundled with Service Models.
Multi-cloud deployment for a model can be declared in the model using the TOSCA substitution mapping feature
Persistence storage for the model and resources built on TOSCA entities, that requires no changes to the schema for new resources or components.

While GIN is inspired by ONAP, GIN adopts a fundamentally different architecture which allows it to address the many shortcomings of ONAP as will be highlighted in this document. The main areas of the architecture of GIN are presented in detail in the remaining sections of this document.