# The Next Generation Platform as A Service: Composition and Deployment of Platforms and Services
## 2 Related Work
Autonomous healing actions in reference [21] are based on pre-defined workflows developed by experts. The primary idea behind the adopted approach is to transfer the current expert domain knowledge and manual action triggers into a rule-based self-healing solution. Moreover, in reference [22], it is shown that deep learning can be used to identify anomaly events from NFV system logs reliably. A technique using a supervised machine learning method for online classification of anomaly states based on similarities between anomaly type-specific density grid patterns is presented in reference [23]. The detection is done by analysing CPU, memory and network usage; the procedure used, the density grid mapping, is inherited from the theory of grid-based clustering. Operational procedures such as healing combine techniques from various research areas and gather information from a wide range of data, implying the integration of a diverse set of tools and libraries. The above-described references show that the PaaS should cater for quick and easy upgradeability, in order to incorporate the rapid evolutions happening in the NFV area and to allow easy customisation for a Telco or other use-case. The platform should follow a modular approach, and a relevant PaaS architecture for this method is advised in reference [3]. Later, in Section 4, we exemplify this modular setup by showing how we implemented in NGPaaS the functional blocks of the orchestration mechanism, network control, monitoring framework and the analysis of VNF anomalies to trigger healing actions. According to reference [24], a unified PaaS interface can be derived from existing PaaS Application Programming Interfaces (APIs), or put another way, a common set of functionalities regarding service instantiation and configuration can be grouped under a standard API. This allows for a unified interface for application deployment and management, among different cloud platforms, avoiding technology lock-in effects. Unfortunately, considerable effort is needed to maintain and translate the unified API to the proprietary PaaS APIs; a common trade-off between the overhead and benefits of using an API abstraction layer. In contrast to reference [24], NGPaaS adopts a workflow-based orchestration mechanism [3], hence the API or descriptor format of the targeted PaaS or infrastructure manager is addressed natively in the workflow and thus minimises the effort required to integrate support for new APIs. The NGPaaS architecture is innovative in the sense that both PaaS and service components are considered as the same module type, using the same generic orchestration mechanism based on the RFB model. As argued in reference [25], if software suppliers adopt the generic RFB descriptor model, DevOps-based integration strategies will be greatly facilitated. The NGPaaS framework, therefore, facilitates customisation and the creation of a custom PaaS solution, with functionality targeted at specific use cases. Given the vast range of possible services, it can be challenging to integrate all existing options into a one-size-fits-all platform solution. NGPaaS implements the complete service lifecycle using build-ship-run actions: (1) What is needed in terms of service offering (build), (2) How the service can be deployed (ship) and (3) Where the service should be deployed (run). These fundamental design questions facilitate the mapping of the right PaaS technologies to the available IaaS and the requirements of the service that should be executed. Each PaaS can be enhanced with unique features related to network state, Quality of Service, high availability, auto-scaling or SDK toolsets [25]. The deployed set of PaaS features is then customisable and use-case dependent. Before exemplifying this through the Telco PaaS use case, we first elaborate on the different processes and workflows which enable this modular NGPaaS framework.