## 3 Materials and Methods
### x86 Tests  
As previously mentioned, the term Bogo Ops is short for \"bogus operations\", and it is a metric used by stress-ng to indicate the number of operations performed by the stress test within a given time frame, which for us is 1 min and 10 min.  
While Bogo Ops are not a standardized measurement like FLOPS (for floating-point operations) or IOPS (for disk), they give a rough idea of performance by showing how many iterations of a given task have been completed. The higher the Bogo Ops value, the more operations the system was able to perform during the stress test, which suggests better performance for that particular component.  
When running CPU stress tests with stress-ng, the tool runs different types of computational workloads (like integer calculations, floating-point math, or cryptographic operations). The Bogo Ops metric in CPU tests indicates how many iterations of these workloads the CPU was able to complete.  
In memory stress tests, stress-ng performs memory-intensive operations like allocating, copying, reading and writing data to and from memory. Here, the Bogo Ops metric reflects how many memory-related operations (e.g., memory reads, writes or allocations) were completed. This metric is useful for testing how well the system handles memory-intensive workloads and can reveal memory bottlenecks.  
For I/O disk tests, stress-ng performs read/write operations on files to measure the disk's I/O performance. The Bogo Ops metric in I/O tests represents the number of I/O operations completed, such as file reads, writes and seeks or other disk-related operations. A large number of Bogo Ops in this context suggests that the disk subsystem can handle a  
Figure 1: Global scheme of the tests.  
larger volume of I/O operations in the given time. We performed each test three times and obtained the average value in order to have relevant values.  
Kubernetes and Docker Engine are very common in companies with complicated and scalable networks. These tools enable automated scalability management, load balancing and container failure management for a complex application. The goal is to test the different cases in a simple architecture with similar solutions to quantify performance. Compared to Docker Engine, Podman does not use a centralized daemon, which allows for lighter container management, does not use root connection for security, and natively supports pod management. Podman is therefore a legitimate competitor to Docker Engine as a runtime container. For orchestrators, Kubernetes is designed to handle complex applications on a large scale and is suitable for production environments, so it has plenty of features. Docker Compose is designed for a simple application consisting of a single node. It does not have features such as scaling (too light), fault tolerance and advanced volume management, making it much easier to configure. Later on, we will describe Docker Compose as a container manager, but as having a simple command utility for the sake of simplicity.  
For each container-runtime and container-manager coupling, we obtained specific metrics:  
* Duration of the test: this was measured to see the influence of time on efficiency.
* Bogo Ops: This is a non-official metric used to measure the number of operations carried out by the hardware. We will use this to compare the efficiency of each method.
* User time: this is the time taken by the CPU to execute code from you or your apps.
* System time: this is the time taken by the CPU to manage and interact with other hardware components (I/O, network, memory, etc.).