PaperlayerView exact revision on arXiv

Source-linked AI summary

Performance Evaluation of Microservices Architectures using Containers

Marcelo Amaral, Jordà Polo, David Carrera, Iqbal Mohomed, Merve Unuvar, Malgorzata Steinder

arXiv:1511.02043v1cs.DC

TL;DR

The paper addresses how to implement microservices-oriented related-process ensembles with containers while balancing deployment flexibility and performance. It compares master-slave and nested-container models using CPU and network benchmarks. Nested containers preserve CPU performance but introduce network trade-offs relative to bare-metal and regular containers.

  • Problem

    The paper asks how master-slave and nested-container models differ in CPU and network performance when implementing related processes per container for microservices.

    Source: §I · pp. 1–2, B. Key virtual networking differences · p. 2

  • Method

    The study benchmarks CPU and network behavior across master-slave and nested-container implementations, including single-host networking configurations.

    Source: §I · p. 2, B. Key virtual networking differences · p. 2

  • Results

    Nested containers have no significant CPU-performance impact, but incur network-performance trade-offs compared with bare-metal and regular containers.

    Source: §V · p. 8

  • Takeaways & Limitations

    Nested containers are a suitable model when improved resource sharing, IPC, fate sharing, and infrastructure-management flexibility are valuable.

    Source: §V · p. 8

Abstract

from arXiv · show

Microservices architecture has started a new trend for application development for a number of reasons: (1) to reduce complexity by using tiny services; (2) to scale, remove and deploy parts of the system easily; (3) to improve flexibility to use different frameworks and tools; (4) to increase the overall scalability; and (5) to improve the resilience of the system. Containers have empowered the usage of microservices architectures by being lightweight, providing fast start-up times, and having a low overhead. Containers can be used to develop applications based on monolithic architectures where the whole system runs inside a single container or inside a microservices architecture where one or few processes run inside the containers. Two models can be used to implement a microservices architecture using containers: master-slave, or nested-container. The goal of this work is to compare the performance of CPU and network running benchmarks in the two aforementioned models of microservices architecture hence provide a benchmark analysis guidance for system designers.

I. INTRODUCTION

Containers provide lightweight, fast-starting operating-system-level virtualization, while RPPC groups related processes per container for deployment and microservices. The paper compares master-slave and nested-container implementations of RPPC to understand their performance differences.

Containers

  • Containers isolate and control process resources through operating-system-level virtualization, avoiding the overhead of emulating physical hardware.Their core mechanisms rely on Linux namespaces and cGroups.Source: §I · p. 1

Related Processes Per Container

  • RPPC places one process or a few related processes in each container instead of treating a container as a lightweight server.The paper presents RPPC as a useful building block for microservices architectures.Source: §I · p. 1
  • Grouping related processes into containers allows subsets of an application ensemble to be redeployed when functionality changes.This avoids repackaging the entire application unit.Source: §I · p. 1

Microservices

  • Microservices organize systems as independently developed, managed, and scaled services connected through a routing fabric.Kubernetes uses pods as deployable groups of containers whose members share the same fate.Source: §I · p. 2

Compared Models

  • The study compares master-slave, where a parent manages peer child containers, with nested-container, where child containers run inside a privileged parent namespace.The comparison aims to characterize performance differences for future system design.Source: §I · p. 2

II. MICROSERVICES ARCHITECTURE USING CONTAINERS

Containers offer lightweight virtualization, but privileged nested containers introduce security considerations and additional virtual-networking layers. The paper therefore examines how networking configurations affect communication performance on a single host.

A. Containers

  • Containers provide operating-system-level virtualization that isolates and controls processes with less overhead than virtual machines.The approach uses Linux container mechanisms rather than physical-hardware emulation.Source: A. Containers · p. 2
  • A privileged Docker container can access host devices and run another Docker daemon to create child containers.This capability enables the nested-container approach.Source: A. Containers · p. 2
  • Sharing system resources with other users can create security challenges for privileged nested containers.The paper identifies this as a caution associated with the approach.Source: A. Containers · p. 2

B. Key virtual networking differences

  • Single-host communication may traverse native, virtual-switch, nested-switch, or virtual-machine networking layers.The default Docker setup connects containers through Linux Bridge or OpenvSwitch, while nested containers add another virtual-switching level.Source: B. Key virtual networking differences · p. 2

C. Microservices

Microservices decompose applications into independent services, and containers provide a lightweight deployment vehicle for these services. The paper considers master-slave and nested-container organization models, which trade management simplicity and shared resources against possible overhead.

C. Microservices

  • Microservices replace monolithic applications with many independent services that work together.The architecture supports simpler individual codebases and isolated service updates and scaling.Source: C. Microservices · p. 2
  • Docker containers suit microservices because they are lightweight, start quickly, and encapsulate implementation dependencies.Container images can include preconfigured middleware, databases, and applications.Source: D. Achieving Microservices with… · pp. 2–3

D. Achieving Microservices with Containers

III. RELATED WORK

Prior work established containers, Docker, and microservices management, but this paper addresses a specific gap: performance analysis of nested and master-slave container implementations.

  • This paper identifies its work as the first analysis of microservices performance using nested and master-slave container implementations.Source: §III · p. 3
  • Containers reduce virtualization overhead relative to virtual machines, while providing somewhat less isolation.Source: §III · p. 3
  • Nested-containers draw inspiration from Google’s pod concept for managing Docker containers, whose performance over virtual machines or bare metal had not been studied.Source: §III · p. 3
  • Kubernetes and Mesos represent related approaches to microservices or cluster management, although the cited Mesos work did not consider container technology.Source: §III · pp. 3–4

IV. EVALUATION

The evaluation studies nested-containers as a microservices architecture approach and compares them with bare metal, regular containers, and virtual machines across CPU- and network-oriented experiments.

  • Five experiments examine CPU and network performance, including CPU-intensive execution and virtual-container creation overhead.Source: §IV · p. 4
  • The study compares bare metal, regular containers representing master-slave deployment, nested-containers, and virtual machines in every experiment.Source: §IV · p. 4

B. Experiment 1: CPU Performance Evaluation

The CPU experiment compares Sysbench execution across bare metal, regular containers, nested-containers, and virtual machines as concurrency increases. All environments show similar CPU behavior relative to bare metal, with slowdown accelerating beyond the machine’s core capacity.

C. Experiment 2: Comparing Overhead of Virtual Container Creation

The second experiment evaluates the scalability and overhead of creating containers, nested-containers, and virtual machines. Regular containers are fastest, nested-containers are intermediate, and their overhead reflects parent initialization and becomes less favorable at higher concurrency.

D. Experiment 3: Overhead of Nested-Container Creation

Experiment 3 measures nested-container creation time across different parent-to-child ratios. Creation is dominated by parent initialization, while distributing children across a small number of parents can reduce elapsed time.

Measurement method

Creation-time results

E. Experiment 4: Network Performance - Local traffic in one host

Experiment 4 evaluates local network performance for bare-metal, containers, virtual machines, and nested-containers using TCP throughput and request/response tests. Containers generally outperform virtual machines, while Host-Network can match bare-metal performance but introduces security concerns for parent containers.

Method

Experimental setting

Results

Nested-container results

  • Nested-container configurations with Host-Network are approximately twice as fast as Linux Bridge or OpenvSwitch in both throughput and latency.Host-Network in a parent container poses security concerns because privileged parents may access host packets.Source: E. Experiment 4: Network Performance -… · p. 7

F. Experiment 5: Network Performance - Remote traffic across two hosts

Experiment 5 measures network performance across two hosts connected by a physical 1-Gigabit switch. The physical network becomes the primary bottleneck, reducing differences among container configurations, while virtual machines show higher latency than containers.

Method

Results

Nested-container results

  • Nested-container configuration differences have no significant performance impact once the physical network is the bottleneck.Host-Network remains associated with security concerns when used in the parent container.Source: F. Experiment 5: Network Performance -… · p. 7

V. CONCLUSIONS

The paper evaluates nested-containers as an RPPC implementation and finds them suitable for microservices because they support resource sharing and IPC without significant CPU impact. Network performance, security, and simplicity remain trade-offs when selecting an implementation model.

Contribution

  • RPPC groups related processes into container ensembles intended to improve infrastructure management and application deployment.Source: §V · p. 7

Compared models

  • The paper compares master-slave and nested-container models for implementing RPPCs.Master-slave uses peer child containers managed by a parent, while nested-container places child containers inside a privileged parent’s namespace.Source: §V · p. 8

Conclusions

  • Nested-containers support resource sharing, IPC, and fate sharing among containers in the same nested-container.Source: §V · p. 8
  • Nested-containers do not significantly affect CPU performance but involve network-performance trade-offs relative to bare-metal and regular containers.Source: §V · p. 8

Trade-offs

  • Selecting a microservices implementation model requires considering network performance, security, and simplicity.Source: §V · p. 8
Loading 1511.02043v1…