PaperlayerView exact revision on arXiv

Source-linked AI summary

A Comparative Review of Microservices and Monolithic Architectures

Omar Al-Debagy, Peter Martinek

arXiv:1905.07997v1cs.SE

TL;DR

Because prior studies report conflicting performance comparisons between microservices and monolithic architectures, this paper evaluates both across testing scenarios and compares service-discovery options. The results vary by scenario: load performance is similar, monoliths lead in concurrency throughput, and Consul exceeds Eureka in throughput.

  • Problem

    Prior studies report contradictory performance findings for microservices and monolithic architectures, motivating further comparison across scenarios.

    Source: §I · p. 1

  • Method

    The paper tests JHipster-generated microservices and monolithic applications with JMeter and compares Consul with Eureka for service discovery.

    Source: §III · p. 2

  • Results

    Load testing showed similar performance, monolithic throughput was 6% better on average in concurrency testing, and Consul throughput exceeded Eureka by 3.8%.

    Source: B. Second Test Scenario: Concurrency… · p. 3, §V · p. 4, C. Third Test Scenario: Eureka vs… · p. 4

  • Takeaways & Limitations

    The conclusion recommends monoliths for small applications with few users and says Consul can be preferred over Eureka for microservices.

    Source: §V · pp. 4–5

Abstract

from arXiv · show

Microservices' architecture is getting attention in the academic community and the industry, and mostly is compared with monolithic architecture. Plenty of the results of these research papers contradict each other regarding the performance of these architectures. Therefore, these two architectures are compared in this paper, and some specific configurations of microservices' applications are evaluated as well in the term of service discovery. Monolithic architecture in concurrency testing showed better performance in throughput by 6% when compared to microservices architecture. The load testing scenario did not present significant difference between the two architectures. Furthermore, a third test comparing microservices applications built with different service discovery technologies such as Consul and Eureka showed that applications with Consul presented better results in terms of throughput.

I. INTRODUCTION

The paper motivates comparing microservices and monolithic architectures because prior performance findings conflict, while organizations also face coordination challenges in tightly coupled monoliths. It introduces the architectures and their commonly cited trade-offs before stating its performance-comparison aim.

I. INTRODUCTION

  • Microservices are independent services communicating through lightweight mechanisms, whereas a monolith places multiple services in one codebase.The paper describes HTTP resource APIs as one example of a lightweight communication mechanism.Source: §I · p. 1
  • Cited advantages of microservices include technology heterogeneity, resilience to component failure, and scaling only the services that need it.The paper also lists independent deployment, organizational alignment, composability, and replaceability as advantages.Source: §I · p. 1
  • The paper compares microservices and monolithic architectures across testing scenarios because prior research reports contradictory performance findings.It also frames the comparison against challenges teams face when working in a shared monolithic codebase.Source: §I · p. 1

II. LITERATURE REVIEW

The literature review surveys architecture comparisons and related concepts, including conflicting findings on microservices versus monolith performance. It also covers deployment environments, containers, and service discovery.

II. LITERATURE REVIEW

  • Prior comparisons report conflicting performance findings: Singh and Peddoju found higher microservices throughput at large request volumes, while IBM reported monolithic gains in many configurations.The paper presents these contrasting results as motivation for further comparison.Source: §II · pp. 1–2
  • Richards’ cited work compares microservices and service-oriented architecture by services, architecture characteristics, and capabilities.Source: §II · p. 2
  • Villamizar et al. found response time increased with microservices because requests passed through a gateway to each service.Their comparison also covered cloud costs and included monolithic and AWS Lambda architectures.Source: §II · p. 2
  • A separate Amazon-cloud study found VM-based environments outperformed container-based environments, including a 125% response-time advantage for VMs.The study compared throughput, response time, and CPU consumption.Source: §II · p. 2
  • Docker is described as Linux-container-based virtualization used in microservices, with minimal processing, memory, and network impact as a reason for its use.Source: §II · p. 2
  • Service discovery matters because service locations are not fixed at design time and services may relocate or replicate in production.Source: §II · p. 2

III. METHODOLOGY

The study uses JHipster-generated web applications to compare microservices and monolithic architectures, then tests service-discovery alternatives. JMeter scenarios assess throughput and response time under varying load, concurrency, and endurance conditions.

III. METHODOLOGY

  • The JHipster-generated application used Spring Boot and Angular JS and consisted of three services.The paper presents it as the application used to generate comparable microservices and monolithic results.Source: §III · p. 2
  • A JHipster microservices application includes a registry connecting components and a gateway exposing the system’s APIs through its frontend.The microservice application provides backend capabilities by exposing an API; Fig. 1 is labeled as a general overview of the architecture.Source: §III · p. 2, Figure 1 · p. 2
  • JMeter tested three scenarios, comparing response time and throughput; the setup used Docker, a remote client, and a 16GB-memory, 2.60 GHz server.The remote client connected to the server by ethernet cable.Source: §III · p. 2
  • Load testing increased the load from 100 to 7,000 threads, using two-minute ramp-up and hold periods at each level.The scenario monitored how increasing users affected throughput and response time.Source: §III · p. 2
  • Concurrency testing sent simultaneous requests to each service, increasing from 100 to 1,000 requests per service without a specified ramp-up.Source: §III · p. 2
  • The endurance scenario tested system endurance with 10,000 threads, a 10-minute ramp-up, and a 10-minute hold, and included microservice configurations using Consul and Eureka for service discovery.Source: §III · p. 2

IV. RESULTS AND DISCUSSION

The results section reports that performance varied across architectures and test scenarios, with throughput and response time used as comparison measures.

IV. RESULTS AND DISCUSSION

  • The tested architectures and scenarios produced differing results in throughput and response time.Source: §IV · p. 3

A. First Test Scenario: Load Testing

In load testing, the architectures had a 0.87% average throughput difference, with monolithic ahead at lower thread counts and similar performance at higher counts. Response time rose as thread counts increased, while fulfilled-request results also differed between architectures.

A. First Test Scenario: Load Testing

B. Second Test Scenario: Concurrency Testing

In the higher-load concurrency test, monolithic architecture had higher average throughput, while response time did not differ significantly between architectures. The test invoked all services simultaneously without a specific ramp-up time.

B. Second Test Scenario: Concurrency Testing

C. Third Test Scenario: Eureka vs Consul Service

The third scenario compares microservices using Consul and Eureka under a 10,000-thread discovery test. Consul had higher throughput and a slightly lower average response time.

C. Third Test Scenario: Eureka vs Consul Service

V. CONCLUSION

The conclusion reports similar performance under normal load, with monoliths doing slightly better below 100 users and achieving higher average throughput in the second scenario. Within microservices, Consul outperformed Eureka in throughput.

V. CONCLUSION

  • Microservices and monolithic applications had similar performance under normal load, while monoliths performed slightly better below 100 users.The conclusion recommends monolithic applications for small applications used by few users.Source: §V · p. 4
  • Monolithic applications showed higher average throughput in the second test scenario and were described as handling requests faster.The conclusion frames this as relevant when faster request handling is the developer's aim.Source: §V · p. 4
  • 4% throughput improvement was reported for microservices using Consul compared with Eureka, and the conclusion prefers Consul for service discovery.Source: §V · p. 5
Loading 1905.07997v1…