The Next Generation Platform as A Service: Composition and Deployment of Platforms and Services

: The emergence of widespread cloudification and virtualisation promises increased 14 flexibility, scalability, and programmability for the deployment of services by Vertical Service 15 Providers (VSPs). This cloudification also improves service and network management, reducing the 16 Capital and Operational Expenses (CAPEX, OPEX). A truly cloud-native approach is essential, since 17 5G will provide a diverse range of services - many requiring stringent performance guarantees while 18 maximising flexibility and agility despite the technological diversity. This paper proposes a 19 workflow based on the principles of build-to-order, Build-Ship-Run, and automation; following the 20 Next Generation Platform as a Service (NGPaaS) vision. Through the concept of Reusable Functional 21 Blocks (RFBs), an enhancement to Virtual Network Functions, this methodology allows a VSP to 22 deploy and manage platforms and services, agnostic to the underlying technologies, protocols, and 23 APIs. To validate the proposed workflow, a use case is also presented herein, which illustrates both 24 the deployment of the underlying platform by the Telco operator and of the services that run on top 25 of it. In this use case, the NGPaaS operator facilitates a VSP to provide Virtual Network Function as 26 a Service (VNFaaS) capabilities for its end customers. 27


Introduction 30
5G is expected to be the ubiquitous fabric to provide reliable, low-latency and high-speed 31 connectivity for a wide variety of services (IoT, mobile, Industry 4.0, automotive, etc.). However 32 current network architectures are not yet able to provide these characteristics, mainly due to their 33 monolithic nature which limits their flexibility, scalability, and programmability. To facilitate the 34 adoption of 5G, the consensus in the industry is to utilise technologies and workflows from the field 35 of Information Technology (IT), such as the cloudification and virtualisation of services [1]. This way, 36 network services that previously comprised dedicated and monolithic hardware appliances (e.g. 37 Firewalls) will now be virtualised instances in commodity servers in the cloud. Doing so is expected 38 to offer a much higher degree of flexibility, scalability, and automation to service providers, as they 39 will be able to modify the virtual setups dynamically and programmatically. 40 To fully reap the benefits provided by virtualisation and cloudification, the deployment and 41 management of services must be decoupled from the underlying computing and networking 42 infrastructure. A paradigm that can facilitate this requirement is the Platform as a Service (PaaS), as 43 it provides a centralised and reliable environment, with high degrees of agility and automation, on 44 which services can be deployed and managed. The benefits provided by the PaaS model can be 45 further enhanced, by incorporating the paradigms of Software Defined Networking (SDN) and 46 Network Function Virtualization (NFV). The scope of SDN would be to facilitate the control and 47 programmability of the network infrastructure while of NFV to allow for the efficient virtualisation 48 and management of services on commodity servers. 49 In contrast with IT services, 5G services are more diverse and stringent in terms of their network 50 and computing requirements. These requirements imply the need for a more flexible and 51 customizable PaaS model [2], than the currently available non 5G oriented solutions. One such model 52 is the Next Generation Platform as a Service (NGPaaS) [3] [4], which is built around the principles of 53 micro-services, modularity, and build-to-order. In short, NGPaaS allows for the deployment of 54 custom-built platforms and services, on a diverse set of infrastructure technologies, using automated 55 and technology agnostic workflows. Through the same workflow, any Vertical Service Provider 56 (VSP) (e.g. Telco provider, IoT provider) can deploy either a custom platform on the available 57 infrastructure or services on top of an existing platform. 58 The content of this paper is structured as follows. At first, a study of related work is presented 59 in Section 2. Section 3 presents the implementation of the requirements and architecture of NGPaaS, (VNFaaS) capabilities to a VSP. In addition to describing the use case and the components that 66 comprise it, this paper also details the process of how these components were made NGPaaS-ready 67 in Section 5. Later, in Section 6 a brief description of another use case targeted by NGPaaS (5G Public 68 Safety) is provided Finally, Section 7 provides a critical conclusion of the presented work. 69

Related Work 70
As mentioned in the introduction, most telco-grade platform environments have originated 71 from existing IT-based cloud technologies (e.g. OpenStack, Kubernetes), but have been extended with 72 new features to be suitable for telco environments, such as edge, access, and core networks. The scope 73 of this section is to contextualise telco-grade platform solutions with recent PaaS and NFV related 74 work. 75 The most prominent standardisation effort in the NFV platform area is the ETSI NFV

The Next Generation PaaS: Architecture, Concepts, Processes, and Workflows 154
The scope of this section is to provide the reader with an understanding of the NGPaaS. More 155 specifically this section introduces the overall NGPaaS architecture, the concept of RFBs, how RFB 156 graphs can be composed via the RDCL 3D tool and finally introduces the workflow through which 157 platforms and services can be composed and deployed in NGPaaS. 158

The NGPaaS architecture 159
NGPaaS consist of a multi-layer architecture, with each layer being responsible for a specific 160 functionality. In total, six layers are defined, 1) The Business Registration Layer, 2) The Business as a 161 Service (BaaS) Layer 3) The Business and Operation Support System (BSS/OSS) Layer, 4) The Dev-162 for-operations Layer, 5) The Platform as a Service (PaaS) Layer and finally 6) The Infrastructure as a 163 Service (IaaS) Layer. The details and scope of each of these layers can be found in Table 1

Business Registration
Registers all stakeholders that participate in NGPaaS (VSPs, Vendors, etc). It also includes the resolution of access and execution rights.

BaaS
A customizable catalogue from which to order service or platform workloads.

BSS/OSS
Responsible for inventory registration, global supervision, and deployment of services and platforms on their execution environments. In our prototype, the BSS/OSS role [12] is fulfilled by the RDCL 3D tool.

Dev-for-Operations
An environment to support the innovative NGPaaS Dev-for-Operations model -an evolution of the existing DevOps model to facilitate new types of interaction and development methods between multiple stakeholders. This environment is where staging and development are performed to bring new PaaS or service components into NGPaaS [13].

PaaS
PaaS components are deployed on the available (declared) infrastructure. These PaaS components form the framework to manage the VNFs included in the requested services. More than one PaaS instances can be active and managed at the same time by the OSS/BSS.

IaaS
This layer relates to the cloud infrastructure available to the NGPaaS operator.

Reusable Functional Blocks 170
RFBs are a core concept of NGPaaS, as they have a significant influence in its architecture and 171 workflows. RFBs are a logical representation of functions that can decompose a complex system into 172 simple sub-functions. Machines (or Containers) in traditional cloud infrastructures. RFBs can also be paired with metadata 179 during their composition, which allows for high degrees of configuration, with reduced complexity. 180 Figure 2 illustrates the RFB concept. Additionally, NGPaaS is a higher-level orchestration framework 181 when compared to ETSI NFV, as it facilitates the deployment and management of multiple 182 heterogeneous platforms. For example, it could be the case that an Open Source MANO (OSM) 183 platform, a reference implementation of ETSI NFV, is deployed and managed by NGPaaS. A detailed 184 comparison between the ETSI NFV and NGPaaS proposal is also provided at [3]. The figure shows how an RFB parent is decomposed into two RFB children, each of which is mapped 188 to the deployment of a micro-service into the execution environment. For these RFBs to be properly 189 configured, they are each paired with some metadata. The NGPaaS RFB model supports inheritance 190 from an RFB parent to its children; this means that, unless overwritten by an RFB child, metadata 191 from the parent will be propagated to all its children. 192

RFB Description and Composition Languages Design, Deploy and Direct tool 193
To fully exploit the RFB concept, NGPaaS is utilising the RDCL 3D tool: a web-based framework 194 that allows the composition of RFB graphs. By composing graphs comprising multiple RFBs, it is 195 possible for a VSP to define complex platforms and services for deployment. Apart from composing 196 RFB graphs, the RDCL 3D tool is also responsible for "shipping" them to an RDCL agent. Every 197 RDCL agent is tied to an execution environment (e.g. an infrastructure or a platform) and its role is 198 to deploy the services/platforms composed by the graph into this execution environment. To facilitate 199 this action, each RFB leaf in an RFB graph is mapped to an Ansible-based [22] workflow which is 200 executed onto the execution environment of the RFB by the agent. By selecting different execution 201 environments for different RFBs of an RFB graph, it is possible for a deployment to span multiple 202 execution environments. For example, a platform deployment can span across a public and private 203 cloud infrastructure. For the RFBs to be executed in the desired order, a priority mechanism is used 204 in which each RFB is assigned a priority value. The RDCL 3D tool was initially developed in the 5G-205 PPP Superfluidity [11] project but has been heavily extended to meet the requirements of NGPaaS. platform using an RFB graph; this comprises of RFBs from the catalogue of RFBs made available by 212 the NGPaaS operator. The RDCL 3D tool provides a full separation between platform and service 213 deployments by assigning each RFB to either a service or platform category. Then when composing 214 a service or platform graph, the VSP will be only presented with the corresponding RFBs. Once the 215 composition of the RFB graph is completed, the VSP selects an appropriate RDCL agent (In this case 216 the service agent of IaaS A). The RFB graph is encoded as a JSON string and is shipped to the agent. 217 Once the agent receives the deployment request, it initiates the execution of the corresponding 218 Ansible roles, each mapping to an individual RFB leaf of the RFB graph. Finally, these Ansible roles 219 are executed into the appropriate execution environment (Platform A in this case) and the desired 220 service is provisioned. Figure 3 also illustrates the possibility to control multiple RDCL agents, via a 221 single RDCL 3D instance. 222

Processes and Workflows 231
The ability to deploy, in a modular way, both platform and service components is one of the key 232 features of NGPaaS. This allows the creation of an eco-system where telco operators can easily 233 cooperate and integrate with multiple software vendors. By using an aligned descriptor format 234 between the vendor and operator side, such as the RFB model, it becomes easier to share both service 235 components and their related execution environments (PaaS). The processes defined in this section, 236 enables the deployment of a customizable set of PaaSes and service components, empowering the 237 support of many use-cases. The most critical processes between layers mentioned above are 238 illustrated in Figure 5 and also analysed in Table 2. 239

Infrastructure registration
A generic provisioning process to support the broad spectrum of available infrastructure technologies. According to the use-case and the required services, the appropriate infrastructure nodes are leased and registered in the OSS.

PaaS orchestration
Refers to the deployment of selected PaaS components on the appropriate IaaS. The PaaS could be Kubernetes, CORD, or any other platform. The PaaS components can be aggregated flexibly and modelled as RFBs. This capability could not be implemented using ETSI MANO which is focused only on VNFs and assumes the platform is already deployed.

Service orchestration
A service is provided by deploying VNFs as sets of RFBs. The target execution environment of each VNF is included in the metadata of the related RFBs, which also specify the runtime aspect: VM, container, Unikernel, FPGA Bitstream, etc. The execution environment of a service component is a predeployed PaaS which supports the runtime aspects of the RFB.

Onboarding new components
The design rule in NGPaaS is "everything is an RFB" (VNF, ancillary services like orchestration, SDN controller, etc.). Therefore, all the components could be updated, upgraded, swapped, etc. This can be done through the usage of the Dev-for-Operations processes.

241
Before requesting any platform or service deployment, (1) the required Infrastructure for the VSP 242 must be reserved by the NGPaaS operator. Once the appropriate infrastructure has been registered, 243 then, (2) the VSP can request the deployment of the desired service. This is done by the composition 244 of two RFB graphs, one for the underlying platform (if not already present) and one for the service 245 itself. Once the RFB graphs have been composed then PaaS (3), or service workloads (4) can be 246 orchestrated on their corresponding execution environments. A relatively similar workflow (5)-(8) is 247 also available to software vendors through their dedicated Dev-for-Operations layer, which allows 248 them (5)-(7) to test new software components that can be later (8)

Virtual Network Function as a Service, Overview 253
The scope of this section is to illustrate the operation of the NGPaaS workflow, via a 254 demonstrable use case. It outlines a service scenario called "VNF-as-a-Service" (VNFaaS), which is 255 based on the CORD platform. More specifically, this section highlights the composition of both the 256 platform and services as RFB graphs and their subsequent deployment in their corresponding 257 execution environment (IaaS for CORD, PaaS for the services). 258

The Telco PaaS Use Case: Virtual Network Function as a Service (VNFaaS) 259
In the Telco PaaS use case, the NGPaaS operator (e.g. a Tier 1 Telco operator) hosts VNFs on 260 behalf of a Service Provider (the VSP). These VNFs could be virtual Routers and Firewalls, which the 261 Service Provider can configure accordingly depending on the desired service (business VPNs, 262 Internet access, etc.). In a "pre-NGPaaS" NFV architecture, the on-boarding of VNFs, to be made 263 available in the service catalogue, is done by the Telco operator (based on the preferences of the 264 Service Provider). 265 Using the NGPaaS workflow,, the Telco operator instead utilises a PaaS-oriented approach 266 instead. While the Telco provider still deploys the platforms, the Service Providers can onboard and 267 administer specific VNFs on their own (e.g. vRouter, vFirewall) and also enable Value-added Service 268 (VAS) capabilities. These VASs could be Telco-grade enhancements to the basic service (e.g. 269 monitoring, healing, policy-based network control, etc.). This way, a pre-existing "VNF App Store" 270 can be supplemented by allowing the Service Provider to onboard new VNFs via direct interactions 271 with preferred vendors, resulting in a more diverse set of capabilities than could be obtainable with 272 the pre-NGPaaS model. There many benefits associated with the adoption of the VNFaaS use case 273 for both the VSP and its end customers. Most of these benefits are due to the nature of the VNFaaS 274 use case, for example, the Service Provider does not need to ship hardware to the premises of its end 275 customer allowing for a more flexible and scalable business and service model. 276

The VNFaaS Proof of Concept 285
To validate the NGPaaS workflow through the VNFaaS use case, a Proof of Concept (PoC) 286 scenario was designed and implemented. To be considered successful this PoC must be able to 287 showcase both the provisioning of a Telco-grade platform and the provisioning of services related to 288 the VNFaaS use case. 289 has been granted access to the RDCL 3D tool by the NGPaaS operator. Using this tool, the Service 291 Provider is then able to compose and deploy service graphs of virtual routers and firewalls, which 292 will provide the desired service to the provider's end customers. Through the NGPaaS workflow, 293 these service graphs are then translated to platform-specific APIs and passed down to the platform 294 orchestrator. Since a service graph request will usually comprise both compute and network 295 resources, the platform orchestrator will translate the request to API calls targeting both the 296 underlying VIM and SDNC components of the platform. The VIM will then provision the required 297 virtual computing resources and the SDNC will provide the required connectivity. It should also be 298 possible for the service provider to monitor its deployment for specific KPIs. At the same time, an 299 alerting function should continuously check the collected data and trigger automated healing 300 workflows, when the state of a deployed service is undesirable. The next couple of sections will provide more details on how this PoC was developed. More 304 specifically, the technologies that comprise it will be detailed (e.g. Platform of choice), together with 305 the steps required to integrate them into the NGPaaS workflow. 306

The Telco PaaS Platform: Central Office Re-architected as a Datacenter (CORD) 307
The selected platform for the Telco PaaS use case is CORD and the current prototype uses 308 version 6.0 [6]. The primary reason for selecting CORD was that it was designed to provide edge 309 network access, by acting as a virtualised Central Office. This implies that the core functionalities of 310 the CORD platform could be effectively reused to fit the needs of the VNFaaS use case. For example, 311 other platforms (e.g. OSM), have a more generic implementation which would make their integration 312 into the VNFaaS use case a more complex task.  prototype. As part of the experimental set-up, we use commercially available router and firewall 328 VNFs. The Router VNF is an enterprise-class router designed to run on x86 standard servers but 329 comprising all the same features as equivalent hardware routers [15]. Similarly, the Firewall VNF is 330 a virtual appliance aimed at enterprise-level security deployments [16]. The implementation of both 331 VNFs is based on virtual machines and in the presented prototype their running instances are hosted 332 by OpenStack. proprietary VMs, thus deploying monitoring probes internal to the VNFs is not feasible. To overcome 340 this limitation the probes in the Telco PaaS are deployed in a side-car fashion, externally to the target 341 service; but can poll the target service for the required using the available interfaces. For this 342 prototype, we rely on the SNMP protocol and REST interface to monitor the router VNF and ONOS 343 SDNC respectively. More specifically, SNMP is used to poll the virtual router for its CPU utilisation, 344 while REST is used to poll ONOS for network traffic information regarding the virtual interfaces of 345 the deployed VNFs. 346 As an enhancement to baseline monitoring, this prototype also provides Alerting and Healing 347 capabilities. The ELK stack can map trends in the CPU utilisation of monitored VNFs to predefined 348 anomalous behaviours. Once such an anomaly is detected, a Healing function is called, which 349 redeploys the anomalous VNF with more resources (e.g. more virtual CPUs or RAM). All healing 350 actions are performed, by the Healing rule, via the RDCL 3D tool, thus ensuring alignment between 351 the state of the deployment and the view of the tool. Figure 9 shows the operation of the monitoring 352 VAS in detail. As mentioned before, monitoring, alerting, and healing are complementary services 353 provided selectively to VSPs. As a result, upon deployment of a VNF, the VSP can set a flag in the 354 RDCL 3D metadata to trigger or not the monitoring capabilities for this VNF. CPU utilisation of all monitored VNFs. In addition, this segment is configured with three predefined 361 thresholds (50%, 80%, and 90%) -when any of these thresholds is reached a corresponding alert is 362 shown to the administrator. In the provided example the critical threshold of 90% has been exceeded 363 (94%); exceeding this threshold triggers an automated healing workflow that will re-provision the 364 VNF with more virtual resources.  In addition to monitoring/alerting/healing, the Telco PaaS supports one more VAS, namely 371 policy-based network management. This is achieved with the integration of an SDN-based network 372 policy framework [18] to the ONOS SDNC. By acting as a layer of abstraction between the network 373 infrastructure and the VSP, the network policy framework allows for simplified control over the 374 network infrastructure. Also, the network policy framework follows an entirely modular 375 architecture, consisting of a Policy Manager and multiple separate Policy Type applications, thus 376 allowing the VSP to add support for new policy types on demand, without affecting the runtime 377 operation of the policy framework. Figure 12 illustrates a (simplified) example operation of the policy 378 framework. There an administrator has deployed the policy manager with two policy type 379 implementations (Firewall and NAT). Subsequently, the administrator issues a request to create a 380 Firewall policy instance that will drop traffic between hosts H1 and H2. Upon receiving the request, 381 the policy manager will validate it for correctness, and if successful, it will then request the Firewall 382 Policy Type implementation to enforce the policy in the network. This will result in the Firewall 383 Policy Type to install flow rules in the switches adjacent to H1 and H2, which will block traffic 384 between the two endpoints.

Virtual Network Function as a Service: Component RFBization 388
The scope of this section is to highlight how the different platform and service components that 389 comprise the Telco PaaS use case, have been mapped to individual RFBs and RFB graphs. 390

RFBization of the CORD platform 391
In previous versions of the CORD platform (<6.0), there was a very tight integration between the 392 different components of CORD, since the majority of them were executed either as native services or 393 as standalone containers and virtual machines. This translated to a very rigid deployment process, 394 with little to no flexibility. However, in the latest version (6.0), the deployment of CORD is now 395 managed via higher-level tools like Kubernetes [21] and Helm [17]. Through these tools, deploying, 396 managing and versioning the different CORD components is easier, more flexible and robust than 397 before. This new deployment approach greatly facilitated the process of RFBizing the CORD 398 platform, mainly due to the central point of management offered by the Kubernetes and Helm tools. 399 Deploying CORD via the RDCL 3D tool requires the definition of several RFBs, each of which 400 implements a specific functionality during the CORD deployment process. However, despite their 401 differences, all RFBs can be placed in one of three categories Pre-deployment configuration RFBs, 402 Deployment RFBs and Post-deployment configuration RFBs. Table 3 provides details these 403 categories. 404

Pre-deployment Configuration RFBs
Responsible for configuring the target infrastructure node for the subsequent deployment of the CORD platform. An example is the cloning of remote source code repositories so that CORD can be later built from.

Deployment RFBs
These are the core RFBs, that when executed will provide with a functional CORD deployment on the infrastructure node. The majority of them are tied to the deployment of groups of containers, through the Helm tool. An example is the deployment of the XOS orchestrator or the ONOS SDNC.

Post-deployment configuration RFBs
These configure a CORD deployment for a specific use case or resolve possible issues that might have risen during the deployment of the CORD platform. An example is the registration of the CORD compute node to the ONOS SDNC.

406
To reduce the complexity of the graph, only the Deployment RFBs are graphically illustrated by 407 the RDCL 3D tool, while the rest is passed to the agent as metadata. Figure 13 illustrates the RFB 408 graph that composes the CORD 6.0 platform in the RDCL 3D web interface. 409 410 Figure 13: RFBization of the CORD platform via RDCL 3D

411
As can be observed in Figure 13, the RFBs have been grouped into five major categories, as 412 children of the root RFB; depending on the role of the component they are responsible for deploying. 413 These five categories are 1) Message Brokers, 2) Storage Mechanisms, 3) Virtual Infrastructure 414 Managers (VIMs), 4) Orchestration and 5) Service Models. Additionally, the VIM group of RFBs is 415 also comprised of sub-groups, namely 1) Kubernetes 2) OpenStack and 3) ONOS. While this grouping 416 does not serve any functional role, it can significantly simplify the composition of RFB graphs. All 417 the remaining RFBs are leaf RFBs, meaning that they are directly mapped to the 418 execution/deployment of a micro-service. It can also be observed that all leaf RFBs are associated with 419 a priority value, ensuring that their deployment in the execution environment is done in a preferred 420 order.  environment of CORD and 2) Network RFB, which deploys networks in the Neutron environment of 434 CORD. Using these two RFB types, complex deployment scenarios can be expressed by the VSP. 435 Figure 14 illustrates an RFB graph comprising of three RFB groups 1) Router 2) Firewall and 3) Probe 436 and 5 RFB leaves 1) Router Instance 2) Firewall Instance 3) Probe Instance 4) Data Network and 5) 437 Monitoring Network. Following the associations between the different RFB groups and leaves, this 438 RFB graph will provide a service chain of a Firewall and Router VNF (through a commonly shared 439 data network), in addition this graph also expresses that out of the two VNFs the Router is to be 440 monitored by a probe, via the monitoring network. The side-car probes of the monitoring/healing 441 infrastructure have been RFBized, while not available at this point, it is also possible to RFBize the 442 remaining components (e.g. ELK stack, Healer). 443 Additionally, the service provider can deploy service instances, networks and connectivity 444 requests agnostically to the underlying technologies. It is the role of the NGPaaS OSS/BSS to translate 445 these requests to the technology-specific APIs. More specifically for the case of the deployment of 446 Figure 14, each of the leaf RFBs will be translated to a TOSCA recipe and then published to the 447 TOSCA endpoint of the XOS orchestrator. Then XOS will decide how to serve this request best and 448 translate this set of TOSCA recipes into API calls to OpenStack and ONOS. The API calls to 449 OpenStack Nova will create the VM instances that will hold the router and firewall VNFs, while API 450 calls to OpenStack Neutron will create the monitoring and data networks. Finally, through the 451 dedicated REST API, XOS will instruct ONOS to populate the network with the necessary OpenFlow 452 rules to facilitate connectivity between the VNFs. 453 In the Telco PaaS, the VM images used to instantiate the VNFs have all been preconfigured with 454 an SSH channel, which provides access to their CLI interface. This way any entity with access to the 455 deployed VNFs (e.g. VSP, end user) could interface with them and configure them on demand, 456 without the need to re-provision them. However, if more virtual resources are required (e.g. more 457 vCPUs), then a new VNF deployment will be necessary using the NGPaaS workflow. The network policy framework has also been RFBized, thus allowing a VSP to either deploy 461 policy type implementations in the policy framework or request for the enforcement of policy 462 instances in the network. With regards to deploying the components of the policy framework only 463 one RFB needed to be defined, namely the ONOSapp RFB. Deploying RFB graphs comprising of 464 ONOSapp RFBs will result in the desired ONOS applications to be installed and activated on the 465 ONOS SDNC of the CORD platform. In Figure 15 (left), an RFB graph that requests the deployment 466 of three ONOS applications is illustrated. These applications include the Policy Manager of the policy 467 framework and two policy type implementations (Firewall and NAT). Once this RFB graph has been 468 deployed, then the VSP can request the enforcement of Firewall and NAT policy instances. Following 469 the example of Figure 12, the right side of Figure 15 illustrates an RFB graph that requests the 470 enforcement of a Firewall policy instance. To facilitate the creation of RFB graphs of this type a 471 collection of RFB types is available, one for each supported policy type (e.g. Firewall Policy Instance). 472 Same as with the deployment of the service graph of Figure 14, the deployment of network 473 policies through the RDCL 3D tool is also technology agnostic. The service provider need only 474 provide the necessary metadata with the deployment request (e.g. endpoints to block with the 475 firewall policy). It is the role of the RDCL 3D tool and agent to translate this request to a JSON string 476 and ship to the ONOS SDNC. After that, the policy framework within ONOS will validate the policy 477 request and install the required OpenFlow rules in the network. As discussed, because the NGPaaS workflow is based on the concepts of build-ship-run and 482 build-to-order, it allows for the deployment of a wide-range of platforms, services and technologies.  This paper highlights some of the inherent complexities and challenges associated with service 505 and platform deployment in cloud-based environments, as required for the successful adoption of 506 5G technologies. This complexity can be mainly attributed to the broad spectrum of available 507 infrastructure and platform technologies, each of which brings their own interfaces and 508 communication protocols. As a possible solution to this problem, this paper introduced a novel 509 workflow for the composition and deployment of platforms and services in multi-cloud 510 environments. The proposed workflow follows the NGPaaS concepts of build-to-order and Build-511 Ship-Run, by utilising the RFB model and the RDCL 3D tool. Build-to-order implies the possibility 512 to define custom platforms and services agnostically to the underlying technologies, based on 513 customer demand. Build-Ship-Run implies the possibility to deploy this platform or service 514 compositions on a wide range of execution environments, through a centralised environment (RDCL 515 3D tool). By following the NGPaaS workflow, platform and service deployment is simplified greatly 516 and facilitated, since most of the underlying technologies are abstracted through generic blueprints 517 and APIs. Finally, this paper successfully validated the proposed workflow by presenting a proof of 518 concept scenario (Telco PaaS) that includes the composition and deployment of both a platform and 519 a set of diverse services. The Telco PaaS use case is based on the CORD platform and represents a 520 VNFaaS scenario, in which a VSP offers VNF services to its end customers, together with many value-521 added services (monitoring, healing, policy-based network management). Finally, to showcase the 522 flexibility of the NGPaaS workflow, a second use case is also, presented herein.