Cisco MSX Service Interface
The Cisco Managed Services Accelerator (MSX) service interface captures the service intent of the customer and requests service to Cisco Network Service Orchestrator (NSO). The Service Interface is composed of two subsystems-the web portal (front-end) and the back-end.
The web portal is designed as an all in one web-based solution GUI. Based on the user login type, the user will be presented with one of three service interfaces: administer, operator, or user. With a successful authentication, the user is directed to the web interface, based on the predefined role of the username.
The Service Interface, based on the user role, will allow the Service Provider administrator to provision tenant space for end users, while the Service Provider operator can view the status of all services running, and lastly the user role is for the Service Provider end-customer to order the service based on their requirements.
Figure 16 MSX Service Interface: Login Screen
Using this portal provider administrator can create and manage tenants (end customers).
Figure 17 MSX Service Interface Administrator: Welcome Screen
Through the Service catalogue in the portal, end customers or tenants can order, manage, and monitor their services. Using this portal an operator or an administrator can also view service status and statistics for the deployed services.
Figure 18 MSX Service Interface Administrator: Manage Tenant Screen
The back-end is the composition of micro-services that together communicate with various components in the MSX Solution. The back-end processes the service intents that you input via the web interface or self-service portal, and creates parametrized service requests to be sent to the MSX platform NSO.
The MSX Services that are available through the portals are dependent on the Service Packages made available by the Service Provider; currently MSX provides the vBranch, SDWAN, and Managed Device service packages. The MSX Service Interface utilizes an OpenAM ID system to determine customer identity.
The Service Interface back-end communicates with the web portal through a REST API Gateway. The interface portals of the web portal rely on back-end micro-services to process user data entered in the various interface portal screens. Dependent on the type of interface portal and data entered, the information will be sent to/from the back-end API and delivered to/sent from the micro-service responsible for processing the incoming data. The back-end micro-services are responsible for multiple functions listed below; individual micro-services communicate with MSX modules or other OSS modules to fulfill their functions.
The portal subsystem is built on a micro services framework. Differnet types of microservices are listed below:
■Business functions microservices
–Identity Management provides authentication and authorization. (Authorization is the component that defines what you have access to. Federation with other identity engines is possible, but requires integration.)
–Manage (Service Provisioning and Life-Cycle)
–Monitor (Service Status and Metrics)
–Orchestration (NSO RFS Integrations)
–Notification (Email Templates)
–Scalable, swappable and extensible (DevOps Enablement)
–Each service can be deployed independently of other services - easier to deploy new versions of services frequently
–Each microservice is relatively small (Easier for a developer to understand)
–Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected
–Each service can be developed and deployed independently
–Eliminates any long-term commitment to a technology stack
■Robust and well documented REST APIs to enable custom app development
–Use our out-of-box UI or build your own
■Supports heterogeneous identity providers (IDM)