[Paper Review] An Experimental Study on Microservices based Edge Computing Platforms
This paper evaluates microservice deployment policies on edge computing platforms using Docker containers, demonstrating that running CPU-intensive and I/O-intensive microservices together in a single container can maintain near-baseline performance, while memory-intensive workloads suffer only when competing with similar types. The study finds that container resource control via cgroups significantly reduces interference, especially in resource-constrained edge environments.
The rapid technological advances in the Internet of Things (IoT) allows the blueprint of Smart Cities to become feasible by integrating heterogeneous cloud/fog/edge computing paradigms to collaboratively provide variant smart services in our cities and communities. Thanks to attractive features like fine granularity and loose coupling, the microservices architecture has been proposed to provide scalable and extensible services in large scale distributed IoT systems. Recent studies have evaluated and analyzed the performance interference between microservices based on scenarios on the cloud computing environment. However, they are not holistic for IoT applications given the restriction of the edge device like computation consumption and network capacity. This paper investigates multiple microservice deployment policies on the edge computing platform. The microservices are developed as docker containers, and comprehensive experimental results demonstrate the performance and interference of microservices running on benchmark scenarios.
Motivation & Objective
- Investigate the performance and interference of multiple microservices deployed on resource-constrained edge devices.
- Assess whether running multiple microservices in a single container is viable on edge platforms despite violating the 'one process per container' principle.
- Compare performance interference patterns between fog and edge computing environments for microservice workloads.
- Identify optimal microservice deployment policies that balance performance, resource utilization, and system maintainability on edge devices.
Proposed method
- Developed microservices as Docker containers with distinct resource profiles: CPU-intensive (L), memory-intensive (S), and disk I/O-intensive (B).
- Designed four deployment policies: single container with/without cgroups, and separate containers with/without cgroups.
- Conducted experiments on Raspberry Pi-based edge platforms using benchmark workloads: CPU (lmbench), memory (COPY), and disk I/O (Bonnie++).
- Measured performance using metrics like CPU latency, memory bandwidth (GB/s), and disk I/O throughput (MB/s).
- Applied cgroups to enforce resource limits and isolate container interference in controlled test cases.
- Compared results across four deployment configurations (case 1 to case 4) under identical workloads to isolate the impact of containerization and resource control.
Experimental results
Research questions
- RQ1Is it feasible to run multiple microservices in a single container on edge devices, despite violating the 'one process per container' rule?
- RQ2How does performance interference differ between fog and edge computing platforms when deploying multiple microservices?
- RQ3What is the trade-off between container consolidation and resource contention on edge devices with limited CPU, memory, and I/O capacity?
- RQ4Which combinations of microservice types (CPU, memory, I/O) exhibit the least performance degradation when co-located in a single container?
Key findings
- Running CPU-intensive (L) and disk I/O (B) microservices together in a single container caused only 12% performance degradation compared to baseline, indicating acceptable co-location.
- The combination of memory-intensive (S) and CPU-intensive (L) microservices in a single container caused 41% performance degradation, making it the worst-performing configuration.
- Enabling cgroups in separate-container deployments (case 4) reduced interference and improved performance across all microservice combinations, outperforming non-cgroups cases.
- Memory-intensive microservices showed minimal performance impact unless competing with another memory-intensive service in the same container.
- Disk I/O microservices (B+B) caused significant performance degradation due to resource contention, even when isolated, indicating high contention under I/O load.
- The best overall performance was achieved in case 4 (separate containers with cgroups enabled), where microservices were isolated and resource-controlled, showing near-baseline performance for all combinations.
Better researchstarts right now
From reading papers to final review, dramatically reduce your research time.
No credit card · Free plan available
This review was created by AI and reviewed by human editors.