Automatic understanding of patients to drive personalized interventions is becoming important in personalized healthcare, especially when patients are suffering from chronic conditions, ideally spending most of their patient journey away from clinical facilities. In most cases using models to infer on patients is a sporadic task, each patient being processed once or a few times per day. Deployed inference services are mostly inactive, occasionally serving bursts of requests. This is a clear indication of benefits that can be achieved if such services are deployed as functions. PHYSICS provides the tools for designing, testing, deploying and evaluating such Functions as a Service (FaaS). Engineers can use the provided Design Environment (DE) to first design their service. The PHYSICS DE integrates Node-RED and extends its palette of nodes, facilitating graphical service implementation as a flow. Some of the nodes do accept Javascript and Python scripts for advanced functionality. The flow can be tested locally, optimized and finalized.

The DE then provides the means to build the flow into an action that can be invoked within OpenWhisk. A Jenkins pipeline is executed, and as a result, the engineer comes up with a new action from their flow.

The deployed actions are then tested via flows dedicated to invoking deployed actions. The outputs of the deployed actions are compared to those of the local flows.

Finally, deployed actions can be evaluated under different scenarios implemented using dedicated load generator nodes.

The results of such tests can be as follows, where experiments last 2 minutes continuous requests, each request arriving at a fixed delay after the previous. As long as the delays are larger than the inference time, the achieved rate follows the increase of that of a system with infinite resources. When the delay drops below the execution time, then the achieved rate reaches a plateau. Even more frequent requests push Openwhisk beyond the accepted maximum request level, dropping the requests, resulting to a performance collapse.

The post Deploying healthcare ML functions in the PHYSICS way appeared first on PHYSICS.

The Design Environment is a graphical user interface (GUI) with the aim of helping users to get in touch with the PHYSICS solution framework, providing the tools and a GUI to simplify the development, testing and management of FaaS applications, all in one place.

The Design Environment is a graphical user interface (GUI) with the aim of helping users to get in touch with the PHYSICS solution framework, providing the tools and a GUI to simplify the development, testing and management of FaaS applications, all in one place.

The GUI is a downloadable packaged solution running as docker container on the user client device. Such solution gives to the user the flexibility, at the start up of the project, to leverage the user resources and don’t necessary rely on the cloud environment, with an approach of EDGE computing[1] architecture.

The GUI is divided in two main sections: the first one is dedicated to the Node-RED[2] application that provides a browser-based editor that makes easier to wire together flows using the wide range of available nodes, even custom PHYSICS’s nodes; the second one is the Admin Panel where the tools for managing the deployed Node-RED flows are located.

In the “Admin Panel” the user can proceed to the build of the deployed Node-RED flow to make it ready for the execution in the PHYSICS platform. Then, in the “Test” section, the flow can be tested from both logical and performance point of views. The last section (“Graph”) is dedicated to the creation of the graph where the user can define an application that includes one or more flows.

The application also gives to the user the possibility to load the (not generated) custom images into the integrated Node-RED environment, which can also be located in a user’s custom repository.

The Design Environment integrates a login system based on Keycloak[3], which provides an all-in-one solution to manage the user’s Single Sign-On (SSO) to the application, i.e. the capabilities of authentication, authorization and segregation of the user workspace. The SSO feature enables the future opportunity of enforcing the security of the PHYSICS resources.

The application interacts with the other components of the PHYSICS environment, to enable the build, testing and management of the related flow. In Figure 2, a high-level diagram of the interactions of the GUI with the other PHYSICS components is represented.

[1] Edge computing is a distributed computing paradigm that brings computation and data storage closer to the sources of data. (https://en.wikipedia.org/wiki/Edge_computing)

[2] Node-RED (https://nodered.org/)

[3] Keycloak (https://www.keycloak.org/)

The post PHYSICS Design Environment appeared first on PHYSICS.

Plant growth and production are the outcome of complex interactions between the plant and its environment. To setup the devices controlling the environment in the greenhouses with optimal efficiency, these interactions must be accounted for. Cybeletech develops biophysical plant growth models, which coupled with environmental models, allow to anticipate the impact of management scenarios on greenhouses outcome. To accurately estimate the current status of the plants and anticipate their development in different scenarios it is necessary to have access to the full history of environmental conditions in the greenhouse.

In most of the greenhouses these environmental data are monitored by a set of sensors. The data collected by the sensors are made available through a so-called supervisor, which is often a desktop computer with dedicated software for greenhouse monitoring and management, located in the greenhouse. According to the greenhouse equipment the data may be temporarily saved on this computer or not. To enable the plant growth models to access the full history about environmental conditions, there is a need for reliable data collection pipeline with the following requirements:

1. The data collection pipeline must be resilient to connexion failures, which are happening regularly in greenhouses;
2. The pipeline must be easily adaptable to integrate new and different kind of environmental data sources;
3. The pipeline must be easily deployable on different kind of infrastructure.

A generic data collection pipeline has been implemented in a Node-Red flow and packaged as a pattern (Figure A). It integrates a getaway to temporarily saved the environmental data in a local database in case of connexion failure as well as a retry procedure to send them in distant database as soon as connexion is restored. The procedure to retrieve and pre-process the data collected by the sensors can be implemented in a Python script which is given as input of the pattern (Figure B). The deployment of the pipeline has been done on the supervisor using the Design Environment developed in PHYSICS.

The deployment from scratch on the test greenhouse supervisor took less than half a day. It allows to collect the data measured by sensors over a month without any data lost despite several connexion failures in the greenhouse. Moreover, the Python script for data collection and pre-processing has been adapted to integrate a novel temperature sensor. With the Edge-ETL pattern enabling to abstract from the overall logic, and the Design Environment for deployment on the edge, this update takes less than a day.

The PHYSICS development environment enables a smoother deployment and adaptation of the pipeline for data collection on the edge, while the dedicated pattern increases the reliability of this pipeline.

The post Taking advantage of PHYSICS to implement reliable data collection pipelines on the edge appeared first on PHYSICS.

In the PHYSICS platform, the main function editing environment used is Node-RED. One of the abilities of the latter is to group a number of functions into subflows that can hide the internal implementation details and appear as regular Node-RED nodes with the parameterizable interfaces. Based on this feature, we have created an extended list of pattern functionalities, providing a parametric, generic implementation that can be dragged and dropped into a developer’s flow in order to speed up development time and reduce the learning curve of FaaS. Examples of such patterns include:

• Implementation of the Fork-Join parallelization primitive, including intra and inter-container parallelization abilities

• Different means of context management, including means to maintain context in warm function executions (reuse of existing containers) or to clean up context for functional or security purposes

• Intelligent request aggregation patterns for reducing back-end stress and costs in high frequency request rates [5]

• Edge ETL Data Collection

• Function-based load generators with support for function chaining

The provided PHYSICS patterns are gradually released in a specific collection included in the Node-RED flows repository, including test flows and documentation about their usage [6].

1. A. Wahyudi, G. Kuk, and M. Janssen, “A process pattern model for tackling and improving big data quality,” Information Systems Frontiers, vol. 20, no. 3, pp. 457–469, 2018.
2. P. Jamshidi, C. Pahl, and N. C. Mendonc¸a, “Pattern-based multi-cloud architecture migration,” Software: Practice and Experience, vol. 47, no. 9, pp. 1159–1184, 2017.
3. “Microsoft cloud design patterns catalogue and documentation.” Available at: https: //docs.microsoft.com/en-us/azure/architecture/patterns/index-patterns
4. D. Taibi, N. El Ioini, C. Pahl, and J. R. S. Niederkofler, “Patterns for serverless functions (function-as-a-service): A multivocal literature review,” 2020.
5. G. Kousiouris, “A self-adaptive batch request aggregation pattern for improving resource management, response time and costs in microservice and serverless environments,” in 40th IEEE International Performance Computing and Communications Conference (IPCCC 2021), IEEE, 2021.
6. PHYSICS pattern flows for Cloud/Edge and Openwhisk, available at: https://flows.nodered.org/collection/HXSkA2JJLcGA

The post Patterns appeared first on PHYSICS.

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.