A Container Orchestration Development that Optimizes the Etherpad Collaborative Editing Tool through a Novel Management System

Freddy Tapia,Theofilos Toulkeridis,Jorge Edison Lascano,Walter Fuertes,Miguel Ángel Mora

doi:10.3390/electronics9050828

Freddy Tapia, Theofilos Toulkeridis + Show 3 more

Open Access

https://doi.org/10.3390/electronics9050828

Copy DOI

Abstract

The use of collaborative tools has notably increased recently. It is common to see distinct users that need to work simultaneously on shared documents. In most cases, large companies provide tools whose implementations have been a very complicated and expensive task. Likewise, their platform deployment requirements should be robust hardware infrastructures. It becomes even more critical when their main target is to reach scalability and highavailability. Therefore, this study aims to design and implement a microservices-based collaborative architecture using assembled containers in the cloud, enabling them to deploy Etherpad instances to guarantee high availability. To ensure such a task, we developed and optimized a central management system that creates Etherpad instances and continuously interacts with other Etherpad tools running on Docker containers. This design goes from the monolithic Etherpad instantiation and handling towards a service architecture, where every Etherpad is offered as a microservice. Furthermore, the management system follows (implements) the Observer, Factory Method, Proxy, and Service Layerpopular design patterns. This allows users to gain more privacy through access to validations and shared resources. Our results indicate both the correct operation in the automation of containers’ creation for new users who register in the system and quantifiable improvement in performance.

Highlights

Microservices have increasingly become popular in recent years
We provide in our solution a management system that is in charge of user management, pad management, and container management
Our management system followed three popular design patterns that together solve the following problems. These patterns can be found on the GoF Design patterns book [41]: (1) Observer pattern: “several components depend on a subject components’ state, a dependent component should be informed about state changes of the subjects, loose coupling between dependent and subject component required, and keeping related objects consistent without tightly coupling them”, (2) Factory Method pattern: “A class needs to instantiate a derivation of another class but does not know which one”. (3) Proxy pattern: “creation and initialization of objects are expensive tasks, some objects do not have appropriate access rights, and we need different access rights to different objects, when an object is accessed by a pointer, additional action is performed by that pointer, it is difficult to create an object in a different space.” [43]

Summary

Introduction

Microservices have increasingly become popular in recent years. Some companies, such as Netflix, Amazon, and The Guardian, have successfully been early adopters of microservices in large-scale software systems environments [1]. Each service is responsible for the implementation of full business functionality and is deployed independently. They can be programmed in different languages and use diverse data storage technologies [3]. A microservices-based distributed architecture inevitably inherits the problems and complexities of distributed systems. They are much more complicated to design; Electronics 2020, 9, 828; doi:10.3390/electronics9050828 www.mdpi.com/journal/electronics

Objectives

Methods

Results

Discussion

Conclusion