## Appendix B  
Detail of the development view.  
Figure A1 shows the essential elements of the application development process, some of which are described below:  
1. Developing applications are shown as a set of subapplications that are implemented as microservices (Sub-App1 = {uServices} and Sub-App2 = {uServices});
2. There is a set of libraries necessary for the operation of microservices (such as MongoDB, Apache Spark, EMQ, Apache Kafka, and Apache Zookeeper libraries);
3. The third-party software in Docker containers (for instance, MQTT broker and Apache Kafka) can be used to create an agile development and testing environment for subapplications on the same computer. In addition, the subapplication microservice versions can be updated using a distributed version control system such as GitLab;
4. Finally, there is a platform used to support the development, integration, and versioning of subapplications. Some of the main elements of the platform are the following: simple build tool (SBT), software development kit (SDK), Scala-SDK, Play Framework support, Intellij IDEA with Git integration plugin, Maven integration plugin, and GitLab project plugin.  
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt}} \hline \hline
**Kubernetes Patterns** & **Description** \\ \hline Multiple Availability Zone Design [78; 79] & This pattern provides independent power, network, security, and isolation from failures in other availability zones. Availability zones within the same region have low latency network connectivity between them. It provides sufficient configuration within the scope of our system testing. \\ \hline Single Container [80] & A single container per pod is the simplest and most common Kubernetes use case. Each pod is used to run a single instance of a given application. It is a basic pattern for the placement of the components of the system applications. All system components were deployed under this pattern as there are no components that must work together in a single pod. \\ \hline Automated Placement [81] & It helps influence the placement of pods in the cluster to control the impact on the availability, performance, and capacity of the distributed systems. We use the following strategies: Node-Name: The simplest way to place a pod on a specific node. It was used to deploy the MQTT-Kafka bridge and scale it on a single and exclusive node. \\ Pod-Anti-affinity: Spread the pods of a service across nodes or availability zones, e.g., to reduce correlated failures. It was applied in the deployment of the three messaging brokers of the EMQ cluster in different nodes. \\ \hline \hline \end{tabular}
\begin{tabular}{p{113.8 pt} p{113.8 pt}} \hline \hline
**Stateful Service** [82; 83] & The stateful service pattern provides building blocks through the Kubernetes StatefulSet resource for the management of distributed stateful applications. It provides persistent identity, networking through services resources, storage (persistent disks), and ordinality (instantiation order/position of pods). In this paper, this pattern was suitable for implementing clusters of ZooKeeper, Kafka, MongoDB, and MQTT that required unique and persistent identities.