PHYSICS’s vision is to address the aforementioned challenges and empower application developers, platform owners and infrastructure providers (e.g. Cloud, Edge etc). For the former, the goal is to ease application development and maximize productivity through the reuse of ready-made and abstracted programming flows while incorporating the FaaS approach in their application structure, based on user friendly function flow programming tools (e.g. Node-RED).
The latter will also lower the learning curve for effectively utilizing distributed and federated services of diverse types. These flows will have a dual nature, initially acting as libraries of most common patterns offered through available repositories , that can be populated/instantiated with specific functions or executables inserted by the developer.
Furthermore, they will act as abstractions, hiding the details of strict platform specifications that are needed for the subsequent stages of deployment and execution. The created flow will be automatically translated to necessary deployment formats (with a need for adaptation to a widely used or standardized ones like Docker Compose, Helm Charts for Kubernetes etc) that can be utilized directly by the subsequent platform layer.
Available reusable flows will also include implementations related to security, data portability etc. that have a generic nature (e.g. encrypted communication channels setup, data format transformation etc.), aiding in fulfilling more practical functional and non functional requirements of distributed service environments in a more abstracted manner.
The overall functionality towards the application developer role will help significantly enhance the aspects of seamless and transparent access and usage of service environments as well as the transformation of the application logic towards the FaaS paradigm.
For platform providers/brokers the goal is initially to increase uptake of the platform layer through the aforementioned abstractions, which will minimize adaptation and integration of applications with platform frameworks. By obtaining these automated translations of application deployable artefacts, the platform providers can directly proceed with that deployment. However, in order to fully exploit and benefit from the diversity of resources and services types as well as locations, suitable selection and placement of application components on these resources needs to be performed. This feature will aid them to maximize their competitiveness since they will also aid application developers to better cope with their end users requirements. For this purpose, PHYSICS provides the necessary set of tools in order to guarantee a seamless and transparent functional deployment and execution on ubiquitous execution environments, while enabling local and global adaptation mechanisms in order to address non functional requirements (performance, service continuity etc) and practically investigate the concept of computational space-time continuum.
The PHYSICS toolkit will include the main gluing layer based on the Function as a Service paradigm. This layer will be based on a selected baseline platform (such as Openwhisk or OpenFaaS) that enables the incorporation of diverse resources in the execution substrate, hiding their differences. For example, Openwhisk uses containers and supports a variety of relevant orchestrators (Kubernetes, Mesos, Swarm etc). Therefore typical e.g. VM resources (including the PHYSICS platform toolkit) may be spawned in different providers and be configured to join the common container management framework dynamically, creating an abstraction and a defacto resource federation hidden beneath. They also support use of higher-level programming constructs like sequences to declaratively chain together multiple actions. Afterwards, relevant function flows and structures can be submitted and deployed, thus covering the main functional requirement of distributed and seamless deployment and operation. Such flow specifications will have been created from the flow programming environment described earlier and adapted to the supported format of deployment (e.g. Docker Compose) as well as function sequence. Another interesting aspect is that typically such layers may support a variety of programming languages for each separate element (for example Openwhisk supports NodeJS, Go, Java, Scala, PHP, Python etc), which enables easier incorporation of existing application components, while also enabling the incorporation of micro-service types of elements. These elements can be invoked synchronously, asynchronously, or on a schedule. Another benefit of this approach is that the platform layer now also has knowledge of the application graph (through the defined function flow), therefore it can use that knowledge to optimize application management in following stages.
In order to dictate the distribution of functions to available global resources, a Global Continuum Placement layer needs to exist to achieve functional as well as optimized placement. This activity initially needs to determine whether functionally a given resource or service may be used by a given component (e.g. storage service type compatibility) and if so, how beneficial this would be. For example, assigning a multicore processor on a single-threaded component is not expected to enhance its performance. In that effort PHYSICS will define and make use of advanced semantic models targeting at describing both hardware capabilities of a specific resource or service as well as application needs or features. Further aspects such as used version of component, necessary arguments etc may be included. These two semantic aspects may then joined in order to infer whether a given application on a given resource will fully exploit the underlying nature. For the computational space-time continuum consideration, further optimizations may be achieved if there is knowledge of a resource’s or intermediate network’s achieved performance as well as variability through time. Furthermore, in order to tackle the dynamicity and variability of a provider, relevant monitoring and benchmarking approaches need to be periodically launched for modelling and quantifying the “gravitational” equivalence of the performance interference in multitenant infrastructures. The fact that the deployment and execution is based on the FaaS model is ideal for this case, given that it is typical in such systems to have extensive monitoring and measuring capabilities at the function level. Thus for each part of the application graph there is an accurate depiction of its processing time, number of invocations etc. and PHYSICS will be able to solve this optimization problem by taking under consideration a variety of factors such as service performance, functional requirements matching (through semantics), network location, apparent system load of that provider on that time interval, entropy of the overall selected graph (in terms of variability, quality of information, semantic distance) etc.. Through the aforementioned functionalities, platform providers will be assisted in order to enforce automatic reasoning, scheduling and deployment of workflows on top of the resulting infrastructures.
However this level of optimization is not sufficient unless it is coupled with policies and techniques for locally applied fine grained control. For this reason, the more tight collaboration between platform providers and infrastructure providers is foreseen in PHYSICS, an approach that will allow the former to better address QoS adaptation of the deployed workflows and the latter to increase their competitiveness through offering extended and unique functionalities with relation to their competition. This Provider-Local Control Plane will enable the definition and implementation of a relevant Controlling Toolkit that will have a dual nature. Initially it will provide a range of available controller solutions from various domains (indicatively Reinforcement Learning ones, Control Theory based ones, AI ones based on neural networks etc). Furthermore, it will be able to exploit semantic declarations of relevant endpoints to indicate regulating parameters (e.g. number of replicas) and the according APIs to set them, as well as monitoring endpoints for determining the difference of the regulated QoS feature from the desired set point. This toolkit may be applied either at the platform layer (e.g. through regulating aspects such as number of replicas of a component through the existing Cloud/Edge provider APIs) but it will also be more tightly integrated with the Cloud provider themselves. This means that the latter will offer extended interfaces (e.g. real time scheduling interfaces) through which multitenant infrastructures can better adapt to changing application behavior. This will also result in the ability of these providers to co-allocate client services on the same resource without violating their QoS constraints, thus optimizing aspects such as cost and energy efficiency. From the platform side, the usage of such mechanisms will aid in avoiding frequent re-placements. In case a given used resource in a federated service graph does not behave as expected, the platform would need to intervene through the Global Continuum Layer and reassign that element in a different placement decision. While this functionality will be available in PHYSICS, it should not be used too frequently in order to avoid continuous migration (and potential needed locking during that migration) and should be used primarily for dynamic and variable load appearance in the occasional occurence of a new space-time continuum optimization. The Provider-Local Control Plane also enables relaxing the optimization constraints of the platform layer, since any suboptimal decision by the latter due to decision timing constraints can later be handled by local tuner interventions. As a final point, and in order to assist in faster migration implementation for the cases mentioned a distributed in-memory state preservation layer is foreseen, that will handle all state related information, with locality aware features. This implies that any migration/reassignment decision will have minimum effect on the application downtime while offering data management mechanisms to be exploited by functions, so that the latter can remain stateless as is intended by the FaaS paradigm.