Code Smells: Microservices vs. Monoliths

01. Executive Summary & Core Insight

Software rarely fails outright when it is poorly built—it simply becomes progressively harder, riskier, and exponentially more expensive to change.

Organizations routinely invest millions rewriting legacy monolithic applications into distributed microservices architectures with the implicit assumption that "modern" architecture automatically produces "cleaner, maintainable" code. This empirical study by Dr. Amit Puri, conducted for his MS in Data Science at Liverpool John Moores University (LJMU), treats the monolith-to-microservices migration as a controlled natural experiment to test that foundational assumption.

02. Research Problem & Guiding Questions

Prior academic software engineering research frequently studied monoliths and microservices as isolated domains using disparate metric definitions. This left a crucial empirical void: no direct, metric-calibrated side-by-side comparison using a unified static analysis pipeline across both paradigms.

This study formulates four anchoring research questions:

03. The 11 Microservices Bad Smells Taxonomy

In monolithic systems, code smells reside comfortably within package boundaries. In distributed microservices architectures, smells metastasize across network boundaries, becoming dramatically harder to detect with conventional class-level linters.

The research synthesizes the literature into the definitive 11 Microservices Bad Smells Taxonomy:

04. Empirical Methodology & Extraction Pipeline

The study deployed a comparative analytics pipeline using standardized static analysis across two complementary datasets:

05. Longitudinal Aging & Compounding Technical Debt

Tracking projects across historical release cycles revealed that technical debt does not accumulate linearly with code size—it compounds exponentially:

06. The Quantitative Comparison: Monoliths vs. Microservices

When the monolithic benchmark dataset is compared directly against the microservices corpus, code smells divide into three unambiguous behavioral categories:

07. The Infrastructure Dimension: Docker & Kubernetes Smells

A major contribution of this research was treating Infrastructure-as-Code (IaC) as code. While monoliths have minimal infrastructure definitions, microservices rely heavily on Dockerfiles, Helm charts, and Kubernetes YAML manifests.

08. The Bridge to Low-Code & Citizen Development

Under RQ3 & RQ4, the research investigates why so many enterprise microservices migrations end in cognitive fatigue:

09. Actionable Guidelines for Architects & CI/CD Linters

Never assume decomposing into microservices buys cleaner code. Configure your automated CI/CD static analysis pipelines with these calibrated rules:

{
  "rules": [
    {
      "key": "UnutilisedAbstraction",
      "severity": "BLOCKER",
      "description": "Fail build if interface has only one concrete implementation without extension rationale"
    },
    {
      "key": "MaxStatementLength",
      "threshold": 100,
      "severity": "MAJOR",
      "description": "Prevent unreadable fluent chaining in stream operations"
    },
    {
      "key": "SharedPersistenceBan",
      "severity": "CRITICAL",
      "description": "Disallow cross-service direct SQL schema queries"
    }
  ]
}

• Target Unutilised Abstractions: Fail builds when interfaces or abstract base classes have only a single concrete implementation without an immediate extensibility rationale.
• Enforce Statement Length Limits: Restrict chained fluent statements and long stream filters to prevent unreadable, bug-prone one-liners.
• Mandate IaC Static Analysis: Integrate tools like Hadolint for Dockerfiles and Kubeconform / Checkov for Kubernetes manifests directly into the commit pipeline.
• Enforce Shared Persistence Bans: Automated architectural linter checks must ensure no microservice can access another service's private database tables directly.

10. Academic Citation & Public Access

To cite this comparative empirical research in academic literature or industry reports, use: