# Bot-Based Emergency Software Applications for Natural Disaster Situations
## 2 Platform Design  
The design of our platform includes four main components: (1) a Front-end, (2) a Back-end, (3) a Bot Back-end which is an API REST that responds to user requests from the Messenger chat of Facebook and/or Telegram, and (4) a Data Repository like MongoDB [14]. Each component can be replicated, distributed, and partitioned based on the workload and communication requirements. Users connect to the Front-end using a smartphone, a tablet, or a computer. The Back-end hosts the applications and communicates with the data repository component. The Back-end performs data searches and executes transactions. The Data Repository stores the data in non-relational databases such as MongoDB [14] or Cassandra [15]. Both the Back-end and the Data Repository can be deployed on different servers. Our platform uses a container [16] and container technology [17], which allow the deployment of applications based on microservices, to achieve auto-scalable, fault-tolerant, and stateless systems, making the configuration of the infrastructure transparent for the programmer. In particular, we use Kubernetes [18] and Docker [19] due to their wide dissemination in the technology community and the support available in the software communities. In Figure 1, we show the general scheme of the architecture, where Nginx [20] is the access point, which is the application server and works as a proxy. The container orchestrator manages and redirects requests to a container. Finally, the figure shows the interaction between different Back-ends and different Data Repositories such as MongoDB, Cassandra, MariaDB, etc. The orchestrator also starts new instances of the applications running in the containers. New instances are started when failures occur or when more resources are needed to support user demand. To this end, ImageRepo maintains an undeployed image of all orchestrated containers. As a particular example, Figure 2 shows the deployment of the complete platform distributed among a cluster of servers coordinated by a container orchestrator.  
Figure 1: General scheme of the proposed architecture.  
Figure 3 summarizes the technologies used to implement the bot-based application on the platform. Our platform supports different types of configurations: unshared, virtual machine monitor (VMM), cloud computing, and container. In the non-sharing configuration, we install the operating system (OS) that manages the resources, the runtime libraries, and then, we deploy the applications. Another possibility is to connect the hardware directly to the VMM (hypervisor) independent of the operating system. The star (\(*\)) symbol shows this configuration in Figure 3. Cloud computing provides tools to manage virtual machines and their resources, which facilitates tasks such as self-scaling (elastic), live migration, and resizing a virtual machine based on workload. Similarly, container technology and orchestrator provide tools to create container-based, self-scaling (elastic) microservices. It automatically manages the containers using a load-balancing algorithm. Using containers without orchestrator requires manual intervention (on the host VM) to manage the containers.