-
Notifications
You must be signed in to change notification settings - Fork 13
Y1 SP Demo Scripts
This page summarises the SP's demo scripts.
It is assumed that:
- Catalogues started as being empty before the SDK's demo;
- SDK's demo ended with
son-pushpushing a validpackagethrough the interface with the SP.
From now on, we will demonstrate the work done during the first year of the project, in the Service Platform. This Service Platform has the following physical architecture.
José: Show supporting slides, SP Infrastructure at a glance, explaining them.
We are now going to demonstrate the usage of the platform. Felipe will be at the commands, while I will talk about what is happening, with the help of this presentation here.
So, this demonstration picks up where the SDK one left: with a package containing one service and two functions that has been submitted to the SONATA's Service Platform.
Felipe: In the GUI, show packages, services and functions.
This can be seen in the Service Platform's GUI. Please note that the package is really an 'aggregator' of services and functions for the Service Platform. Packages are only relevant within the Service Platform's realm, and not apart from that. Package on-boarding is made in the Gatekeeper, the Service Platform's entry component that validates, decomposes and stores the package content. Let's se this in detail:
José: Show the demo slides related to the Package On-boarding.
Services that are part of the Service Platform's provider Catalogue can be made available to the Business Support Systems (BSS), for End-Users to instantiate them.
Felipe: In the BSS, show Available services;
From these available services the End-User can choose the one that he/she wants to instantiate. So let's instantiate the only one that we have available for the moment.
Felipe: In the BSS, request a service instantiation.
Felipe: In the BSS, show Requests.
Ok, the request has been done from the BSS to the Service Platform, and while it is INSTANTIATING, let's see in more detail how that really happens.
José: Show supporting slides, Instantiating a Service.
Let's see if the service has been successfully instantiated...
Felipe: In the BSS, show Requests (status should be READY)
It is. We can see the service instantiation status as being READY. As I have shown you previously, a consequence of this is a Network Service Record (NSR) and a VNF Record (VNFR) to be generated and stored in the Repositories.
Felipe: In the BSS, show Network Services Instances (status should be normal operation)
Let's check what happened in terms of the Infrastructure.
José: Show supporting slides, Infrastructure Abstraction
Monitoring is one of the crucial processes for the Operations (the Ops, on DevOps). And monitoring in highly dynamic environment, such as the ones related with NFV/SDN, must be at least as dynamic.
As we have told you before, one of the consequences of a successful instantiation of a service is the notification to the Monitoring sub-system.
Felipe: In the GUI show monitoring of both VNFs (vTC and firewall)
As you can see, both functions are working fine.
José: Show supporting slides, Monitoring a service
When the developer wrote the NSD, he/she has included in it a monitoring rule that will make the monitoring system send an alert whenever the CPU load is higher than 85% for a number of consecutive seconds. Let's use the service a bit and check that Ops related flow.
Ok, now we will use the service. We can get the IP addresses that have been given to these functions.
Felipe: In the GUI go to the Monitoring > VNFs > vTC menu option and look for the IP address.
We can now start using the vTC.
Felipe: Start generating some traffic
Felipe: In the browser, access the vTC dashboard
As you can see, traffic is passing through the vTC function.
Felipe: Start generating even MORE traffic
Now, imagine the service user starts stressing the service, with a series of downloads. We can see it here, in the number of bits hitting the service. The platform operator can also see it in the GUI: in this case, it is the firewall VNF's CPU that is having the highest load.
Felipe: In the GUI go to the Monitoring > VNFs > firewall menu option and show the CPU load
All this must have fired an alarm in our monitoring subsystem, as you can see in the GUI.
Felipe: In the GUI go to the Alarms menu option and show the alarm
The Monitoring sub-system sends an email to the developer, describing the alarm.
José: Show supporting slides, Email Alert.
The developer therefore possess the information about the performance of his/her service which, in this example, is not very good. Therefore, he/she develops a Service Specific Manager (SSM) to address this.
Specific Managers, for both Services and Functions, are one of the key innovation of this platform. Through them, developers can more adequately provide different kinds of managers to their services and functions.
A SSM can be developed and packaged (in a container). A new version of the service can then be elaborated, with its NSD now referencing this container. This new version can the be submitted to the Service Platform.
A new version of a service must have a new version of it's NSD, which produces a new package, which is submitted to the Service Platform in exactly the same way the previous one was.
Felipe: In the GUI, show packages, services and functions.
As expected, we now have two packages, two versions of the same service and the same two functions as before. This is important to note. In this example, we are reusing functions, that is, no new functions are being provided. But the updated service could introduce new functions, or new versions of the existing functions.
Ok, so now that we have a new version of the service, we offer the End-User the possibility of updating the currently running instance to the new version.
Felipe: In the BSS, show Network Services Instances
Now that there is a new version of the service, the End-User can request it's update. So, let's request it.
Felipe: In the BSS, request the update.
While the service instance is updated, I'd like to show you what is happening behind the scenes.
José: Show supporting slides, Update a Service
Let's see if the service instance has been updated, now having its new SSM.
Please remember the developer introduced this new SSM because an alarm was fired about the excessive CPU load his/her service was producing. So let's check the firewall VNF, was this was happening.
Felipe: In the GUI go to the Monitoring > VNFs > firewall menu option and show the CPU load
As you can see, the SSM did its work, lowering the CPU load.
This slide summarises the key takeaways from the SONATA Service Platform demo.
- Fast time-to-market: From 'concept', through 'deploy', to 'usage' (and even trough 're-deploy'), and although this was a simple service we have demonstrated, we've shown that is possible to have very short cycles -- this is one of the 5G KPIs, to have a service deployed in minutes instead of days;
- Specific Service and Function Managers: A Service Platform that must be prepared to work with 3rd party services and functions can not manage all those services and function in the same way. From the 'classical' service and function management perspective, this 'case-by-case' management need might feel ineffective and inefficient, but SONATA provides this Specific Manager approach to address this issue in exactly the opposite way, effective and efficient;
- Reuse of already defined functions: a new or updated package may contain references to already existing services and packages, thus
- Openness, by using REST-based interfaces, in JSON or YAML: by publishing the Service Platform's interfaces and using common technologies and languages, like the ones mentioned, we lower barriers to adoption of the SONATA Service Platform by the Open-source community;
- Flexibility, with a plugin- and message-based architecture: no Service Platform provider can ever anticipate ALL the needs of the developers that will use it, so the flexibility of a plugin- and message-based architecture is crucial. A plugin that can be developed and deployed to address a specific issue of a concrete service is really powerful;
- Scalability, by using microservice-based architecture: the exact scalability issues any system might pose can only be known after it is deployed and has a significant load. The adopted micro-services architecture allows for different components to be scaled within different time-scales, thus providing the adopters of this Service Platform to add capacity as the platform is being used. Therefore, there is no need to add significant capacity up-front, increasing the costs of adoption of such a solution.
©SONATA, 2015-2017