Marie-Donnie

The shift from cloud computing to edge computing has changed the requirements for the applications running there. While the current cloud computing applications are extremely robust in the context of the cloud, they were not made to face the challenges inherent to the edge computing, especially disconnections and high latencies that can be observed between far sites. Since we already have robust and huge cloud applications, the question that remains is: could it be possible to use them at the edge by managing the scale and the geo-distribution of the infrastructure outside of the business logic? To answer this question, I study different existing approaches to bring applications to the edge and identify what is missing in these solutions, as well as keeping track of the interesting answers to specific problems. From this study, I present the solution built to bring cloud applications at the edge while giving users the choice of the location for their requests executions. This solution relies on the modularity of these existing cloud applications to create a service-mesh like approach that intercepts the requests between services and redirects them according to the domain-specific language (DSL) we created that allows users to specify collaborations between different edge sites.

With the arrival of the edge computing a new challenge arise for cloud applications: How to benefit from geo-distribution (locality) while dealing with inherent constraints of wide-area network links? The admitted approach consists in modifying cloud applications by entangling geo-distribution aspects in the business logic using distributed data stores. However, this makes the code intricate and contradicts the software engineering principle of externalizing concerns. We propose a different approach that relies on the modularity property of microservices applications: (i) one instance of an application is deployed at each edge location, making the system more robust to network partitions (local requests can still be satisfied), and (ii) collaboration between instances can be programmed outside of the application in a generic manner thanks to a service mesh. We validate the relevance of our proposal on a real use-case: geo-distributing OpenStack, a modular application composed of 13 million of lines of code and more than 150 services.

One question to answer the shift from the Cloud to the Edge computing paradigm is: how dis- tributed applications developed for Cloud platforms can benefit from the opportunities of the Edge while dealing with inherent constraints of wide-area network links? Our solution to this question is to give the illusion of “single service images” spreading over the Edge infrastructure. Thanks to the modularity of micro-service based applications, one can deploy multiple instances of the same service (one per edge site) and deliver collaborations between them according to each request. This non-invasive approach is made possible by (i) a DSL that extends the application API and allows DevOps to program where/how the execution of each request should be executed, (ii) and its runtime, Cheops, a service that interprets and orchestrates each request in order to satisfy the geo-distribution parameters, allowing collaborations in a transparent manner for the underlying application. We demonstrate the relevance of our proposal by illustrating how Cheops can successfully geo- distribute the Kubernetes vanilla code.

Despite the importance of experiment-driven research in the distributed computing community, there has been little progress in helping researchers conduct their experiments. In most cases, they have to achieve tedious and time-consuming development and instrumentation activities to deal with the specifics of testbeds and the system under study. In order to relieve researchers of the burden of those efforts, we have developed ENOSLIB: a Python library that takes into account best experimentation practices and leverages modern toolkits on automatic deployment and configuration systems. ENOSLIB helps researchers not only in the process of developing their experimental artifacts, but also in running them over different infrastructures. To demonstrate the relevance of our library, we discuss three experimental engines built on top of ENOSLIB, and used to conduct empirical studies on complex software stacks between 2016 and 2019 (database systems, communication buses and OpenStack). By introducing ENOSLIB, our goal is to gather academic and industrial actors of our community around a library that aggregates everyday experiment-driven research operations. A library that has been already adopted by open-source projects and members of the scientific community thanks to its ease of use and extension.

Edge computing is becoming more and more present, with sites geo-distributed around the globe. Applications on these infrastructures must be able to manage the latency and disconnections inherent to their distribution. One way to deal with these concerns could be to deploy one entire instance of the application per site and use a service mesh to manage the collaboration between the geo-distributed instances. More precisely, we propose to reify the location of application instances in REST requests and allow redirections between these requests thanks to a dedicated language and a service mesh allowing three types of collaborations. This paper focuses on the replication of a resource between multiple instances. Though it is still a work in progress, we demonstrated the relevance of our approach in the OpenStack ecosystem.

Resource management systems are key elements of distributed infrastructures. At HotEdge'18, we alerted our community of the importance of delivering such a system to favor the advent of the edge computing paradigm. While new initiatives have been proposed, they are far from offering the expected features to administrate and use geo-distributed infrastructures such as the edge ones. However, there is an opportunity to move forward by proposing a break through approach in the design of resource management systems for the edge. We give the premises of such an approach by illustrating how multiple instances of a Virtual Infrastructure Manager can collaborate with each other while mitigating code efforts. Our proposal leverages service concepts, dynamic composition as well as programming software abstractions. Beyond the development of a resource management system for edge infrastructures, our proposal may lead to a new way of distributing applications where intermittent network is the norm.

Since 2016, the FEMDC SiG has been investigating how OpenStack could operate Edge Cloud infrastructures. Among the challenges that have been identified by the SiG, dealing with latency issues and network split brains is important for most OpenStack services. In this presentation, we focus on how they impact the Keystone Identity Service. Keystone offers different deployment approaches, from a centralized one, to a federation, as well as a replication using database clustering. By varying the number of regions and latency between those regions, we compare the following deployments:
- One centralized Keystone handling requests of all regions
- A replicated Keystone using Galera Cluster to synchronize databases in the different regions
- A replicated Keystone leveraging the NewSQL CockroachDB database
- A federated Keystone
We present the methodology, results and identification of possible improvements towards a more decentralized management of the OpenStack services.

How to administrate and use edge infrastructures is still an open question. After analyzing and proposing various strategies for almost 6 years, academics have identified an interesting approach to turn any kind of micro-service based application "edge compliant". One instance of an application is deployed at each edge location, making the system robust to network partitions (local requests can still be satisfied), and collaboration between instances can be programmed outside of the application in a generic manner thanks to a service mesh. Materialized in Cheops, our prototype allows DevOps to deal with the location of application instances in REST requests using redirection technics. Cheops decorates the original API with a dedicated language and proposes various collaboration mechanisms, allowing for instance to share resources across sites or create/manage replicas in an straightforward manner. We demonstrate the relevance of our approach in the OpenStack and Kubernetes ecosystems.