An ontology is a formal description of domain knowledge that encompasses information about categories, entities, their relationships, and properties. This type of structured information representation follows the paradigm of semantic and linked data and allows machines to read and infer knowledge. Typically, this type of information representation, utilizes triplets in the form of subject, predicate, object.  An example of the aforementioned schema is the following, “John is a friend of Sophia”, where “John” is the subject, “is a friend of” the predicate and “Sophia” the object. If in the respective ontology it is explicitly defined that this type of relationship requires the subject and object to be of type: human a typical reasoner would already know that both John and Sophia are humans. Another fact that can be easily inferred is that Sophia is also a friend of John. Through these simple examples we observe some of the potential of ontology usage. Ontologies up until today are widely used in the Semantic Web domain, but recent work emerges in different domains such as the cloud service provisioning, to tackle problems such as vendor differences in service descriptions both in terms of offerings and functional properties.

Semantic description of resources

Within the PHYSICS platform we use this kind of semantic modelling in two occasions; The first one takes place when an application is modelled while the second when a cluster is registered to the platform. One key aspect of PHYSICS is the utilization of a multi-cluster scenario to optimize application deployments.  While the reader can refer to a previous blog post about the semantics block as a whole, in this post we will discuss the specifics of the resources ontology.

To guide our ontology creation, we have based our process on the four key aspects to be described for each cluster:

1. Cluster capabilities: Functional properties of the cluster such as the available nodes at the time of description, their respective available CPU and RAM allocatable values, whether they are GPU enabled etc.
2. SLA: The necessary classes and relationships to address SLA terms, the rebate in case of agreement breach and their target values.   
3. Cost:  A cloud service cost such as the instance maintenance cost or cost per service request.
4. Energy:  Classes that address how energy efficient are machines are used to comprise a cluster and what percentage of this energy is coming from renewable sources of energy.

These 4 pillars of information provide the necessary knowledge to compare clusters effectively in order to manage them or select one for a specific application that is to be deployed. Several classes, properties and relationships are defined to capture the aforementioned concepts such as in the following picture, where the essentials of SLA terms are captured.

Information Extraction

After the ontology is formulated the next question that arises is: “How are we going to retrieve this kind of information?”.  For the Cost and SLA categories we can safely rely on the public documents provided by the cloud vendors in the case of public cloud or apply a formula to calculate an approximation of energy consumption cost if the respective rates are provided for the region where private clouds reside. For the specific case of public SLA documents, pattern matching, and natural language processing techniques have been successfully used previously to automatically extract information directly to the ontology and we will be utilizing this approach. For the energy certificates and information on sources unfortunately there has not been much standardization on how providers list these kinds of details and as a result we can only rely for the time being on getting this information manually.

Finally, the cluster capabilities information can be retrieved by the Kubernetes API for any Kubernetes cluster. The various API client libraries provided, allow for configuration from within pod making REST API calls efficient and accessible from the same service that also injects their response information into the defined ontology format. After all the clusters have been described in the ontology context, information is passed to the project’s knowledge base so it can be examined and reasoned to guide the cluster selection and management process.

The post Ontologies and Semantic Description of Cloud Resources in PHYSICS appeared first on PHYSICS.

Applications typically consist of a multitude of components; some are in need of locality and others in need of significant computational resources to fulfil their scope and objectives. Even though the idea of efficiency in Function as a Service operation is correct, latency, computing costs or even data privacy is often a showstopper in using cloud services or data centers for IIoT use-cases. The combination of Edge computing with cloud computing might solve some problems associated with the usage of pure centralized computing by creating additional decentralized processing power for achieving a true edge-cloud-computing continuum.

Cloud-Core-Edge-Balance makes flexible and increases reliability for IIoT use cases. Edge computing is therefore complementary for most IIoT environments and does not replace central IT infrastructures. The focus is therefore on the right composition of the IIoT infrastructure – depending on the intended application scenarios and respective requirements, which can differ fundamentally. We can examine the edge-cloud-domain from the following three main requirements for Function-as-a-service:

[1. Cloud costs and volume of Data]

IoT use-cases often come with a high volume of data in small chunks. That said it is often worth to process as much data as possible directly at the edge. This will not only prevent networks from being overloaded but will also reduce costs for data transfer to the cloud. In addition, storing historical data in the cloud by batching them on the edge and uploading them to the cloud in larger batches reduces the cloud costs and increases the availability and durability of the data.

[2. Real-Time Response]

Inserted between space of the deployment and the time of the execution one cannot separate the two concepts in the eyes of the application user who only is interested in the deployment of the final optimized result. Utilizing a centralized service in the cloud far away from the observer may introduce latency or other factors that render this selection as more time consuming than a localized deployment on the edge. The data should also be processed directly at the edge if low latency is crucial; this keeps the shipping distance short. Depending on whether processing has to take place quickly or even close to real time, the analysis of this trade-off should result in a unified space-time combinatorial approach in order to handle the selection.

[3. Computing Power]

IIoT use-cases in particular where AI methods are involved require high computing power and storage capacity. It is often worth to run computing task in cloud or core environments, which requires high computing power like training of inference models and only run the inference task on the edge.

Methods like complex event processing, pre-filtering and batching of data and serverless functions or event-driven functions deployed in a continuum environment on the edge, cloud or in the core will help to overcome these obstacles in realizing value adding IoT use-cases.

The PHYSICS Project will further elaborate on these mentioned methods in the next years for a true continuum computing space.

[1] https://blog.de.fujitsu.com/connected-services/industrial-iot-in-deutschland-edge-computing-ist-das-fehlende-puzzleteil-fuer-viele-iot-use-cases/

The post The Merits of Cloud Functions in an Edge Computing Context appeared first on PHYSICS.

The main goal of PHYSICS is to unlock the potential of the Function-as-a-Service (FaaS) paradigm for Cloud Service Providers (CSP) and for Application Developers. Specifically, it will enable application developers to design, implement and deploy advanced FaaS applications in the scope of advanced cloud application design environments, leveraging proven design patterns and existing libraries of cloud/FaaS components. Furthermore, PHYSICS will offer a novel Global Continuum Layer that will undertake to deploy functions in optimal ways that will optimize multiple application objectives at the same time, including for example performance, latency, and cost. The platform will offer a graphical view of the application flow, allowing through simple drag and drop commands to create pipelines of functions according to the FaaS model.

PHYSICS will validate the benefits of its Global Continuum Layer and tools, in the scope of user-driven application scenarios in three important sectors, namely healthcare, agriculture and industry.

Specifically:

• PHYSICS in Manufacturing: The PHYSICS industrial use cases will focus on manufacturing and production. It will be deployed in a smart plant testbed to demonstrate how FaaS model can be used to optimize production pipelines in environments where multiple edge devices are used. Specifically, FaaS enabled production pipelines based on heterogeneous devices that are currently available in the plant will be developed. The devices of the pilot plant include edge devices, several HPC (High-Performance Computing) Clusters or single HPCs, special GPU (Graphical Processing Units) enabled processing nodes, industrial PCs, PLCs (Programmable Logic Controllers), Single-board computers, Raspberry Pis, as well as devices that simulate Quantum-like processes. PHYSICS will facilitate the combination and use of services from these diverse setups in a seamless and integrated manner. Moreover, it will ensure that relevant FaaS functions for accessing the capabilities of these devices are assigned and used in optimally.
  
• PHYSICS in Healthcare: The PHYSICS healthcare use case will focus on the deployment of functions (FaaS) across multiple IoT edge devices and smartphones that provide Real-World Data and enable the extraction of novel biomarkers about certain diseases. The data received are divided into two main categories: measured (objective) and reported (subjective). Through different devices it will be possible, exploiting the FaaS paradigm and Machine Learning technologies, to make predictions on possible problems based also on clustering activities between patients with similar lifestyles. PHYSICS FaaS functions will be optimized to address diverse needs about data access interfaces, data harmonization, and transformation, as well as different privacy and data protection requirements. 
  
• PHYSICS in Agriculture: The PHYSICS Agriculture Use Case will showcase how the FaaS paradigm can facilitate the implementation of many thousands of daily climatic simulations towards improving crop management and yield estimation. The scalable execution of thousands of simulations about each greenhouse is a key to manage meteorological uncertainty and correcting its trajectory with existing historical data. Specifically, FaaS will facilitate the optimal distribution and deployment of functions across different cloud environments and the local sites, in ways that ease (re)configuration of simulations towards an optimal distribution of computations across edge nodes and the cloud. Likewise, the use case will showcase a tangible performance improvement in the execution of simulation, including the possibility to execute simulations in near real-time.

Follow GFT on Twitter and on Linkedin to see the latest updates!

The post The main goals and Use cases of the PHYSICS Project appeared first on PHYSICS.