Why Microservices Beat Monoliths: Benefits, Drawbacks, and Best Practices

Software architecture consists of various organized components such as web servers, application servers, databases, storage, and communication layers, which interact with each other and the environment. The goal of system architecture is to address stakeholder concerns.

Conway’s law states that organizations which design systems are constrained to produce designs that mirror the communication structures of those organizations.

Monolithic Architecture

Monolithic architecture is suitable for small projects. Its advantages include simple and direct development, centralized management, minimal code duplication, and no distributed management or call overhead.

However, its disadvantages are evident, especially for internet companies:

Low development efficiency: all developers work on a single codebase, leading to code conflicts.

Difficult maintenance: tightly coupled functionality makes onboarding new developers hard.

Inflexible deployment: any change requires rebuilding the entire project.

Low stability: a minor issue can crash the whole application.

Insufficient scalability: cannot meet high‑concurrency business demands.

Microservice Architecture

Microservices are small, independently deployable services that each provide a specific business capability and communicate via lightweight mechanisms. They embody componentization, loose coupling, autonomy, and decentralization.

A set of small services, each focused on a single responsibility.

Independent deployment and scaling, enabling rapid delivery and response to change.

Independent development and evolution, allowing technology choices per service.

Independent teams with autonomy over the full service lifecycle.

Microservices aim to decouple work, applying a divide‑and‑conquer approach to reduce unnecessary overhead and enable rapid adaptation to change.

"Let our system respond to change as quickly as possible" – Rebecca Parsons

Over the past decades, various lightweight development methods (XP, Scrum) and the Agile Manifesto have sought to embrace change. Microservice architecture addresses this need at the technical and architectural level.

Service Communication

Synchronous calls are simple and strongly consistent but can suffer from performance issues and call‑stack depth. RESTful (HTTP‑based) calls are widely accepted and language‑agnostic, while RPC offers higher efficiency and tighter security in controlled environments. Asynchronous messaging reduces coupling and provides buffering, at the cost of eventual consistency and the need for idempotent services and a reliable broker.

Microservice Advantages

Each service is small and focuses on a specific business function.

Small teams (2‑5 developers) can develop services independently.

Loose coupling and independent deployment improve flexibility.

Multiple language support.

Easy integration with CI/CD pipelines (e.g., Jenkins, Bamboo).

New team members can become productive quickly.

Individual services are easier to understand, modify, and maintain.

Facilitates adoption of latest technologies.

Business logic stays separate from UI components.

Services can be scaled on demand.

Can run on modest hardware.

Simple third‑party integration.

Each service can have its own storage, or share a database.

Microservice Disadvantages

Potential operational overhead.

Requires DevOps expertise.

May double effort due to duplication.

Distributed systems can be complex to manage.

Debugging and tracing become harder with many services.

Complexity grows as the number of services increases.

Considerations

While each service has less code, the overall system complexity does not decrease; assembling many small services is akin to solving a large puzzle.

Independent data and deployment increase the need for efficient inter‑service communication mechanisms.

Dynamic scaling and lifecycle management require robust versioning, deployment, and orchestration capabilities.

Load balancing across multiple instances improves performance and reliability, but introduces additional monitoring and routing complexity.

A unified entry point (service registry) is needed for dynamic service discovery.

Enterprise concerns such as centralized security policies, fault auditing, system monitoring, and dependency management must be addressed at the platform level.

Why APIs Matter

APIs encapsulate service value, must be reliable, readable, and are often a single point of interaction. Implementing an API gateway provides a unified entry for clients, handling routing, security, and versioning.

API Design Elements

Version

Request ID

Auth & Signature

Rate Limit

Documentation

Error Code & Message

Microservice Governance

On‑demand scaling (deployment & monitoring costs)

Independent deployment (machine count & deployment cost)

Business isolation (service dependencies, versioning, transaction handling)

Technology diversity (environment deployment cost, conventions)

Additional governance aspects include runtime monitoring, rate limiting, SLA, load balancing, logging, service registration & discovery, deployment automation, fault tolerance, and security.

Service Fault Tolerance

In microservice environments, services often depend on multiple downstream services (fan‑out). Failures or latency in a single backend can cause cascading failures, exhausting resources and potentially bringing down the entire system.

Service Framework

Service registration, discovery, load balancing, and health checks.

Monitoring and logging, exposing metrics and trace data.

REST/RPC and serialization support for various client types.

Dynamic configuration management.

Rate limiting and circuit breaking.

Management interfaces (e.g., Spring Boot Actuator).

Unified error handling.

Security plugins.

Automatic API documentation (e.g., Swagger).

Microservice System Foundations

A minimal microservice platform should include:

Log aggregation, classification, and querying.

Monitoring and alerting.

Lightweight message bus (MQ or HTTP).

Service registry and discovery.

Load balancing.

Deployment and upgrade mechanisms.

Event scheduling.

Resource management (VMs, physical machines, networking).

Additional capabilities may include authentication, multi‑language code frameworks, unified build & packaging, testing, CI/CD pipelines, dependency management, tracing, and deployment strategies such as canary or blue‑green releases.

Containers (Docker) and Microservices

Containers are lightweight, solving the machine count requirement for microservices.

Containers are isolated, enabling multi‑language support.

Development and production environments become identical, improving efficiency.

High container efficiency reduces costs.

Code and image are bundled together for easy reuse.

Horizontal and vertical scaling are straightforward.

Impact of Development Practices

With continuous delivery and Docker adoption, microservices combine these concepts into a containerized, continuously delivered platform. Traditional monolithic DevOps teams span product, development, QA, DBA, and operations, whereas microservice teams are split by service boundaries with a central platform team handling operations via APIs.

Successful microservice adoption requires strong DevOps capabilities, continuous evolution of services, alignment between teams and architecture, and a culture of continuous improvement.

Microservice Case Studies

Netflix’s microservice architecture emphasizes global distribution, high scalability, and availability.

Twitter’s microservice architecture focuses on efficient, scalable data center operations.

Source: https://www.cnblogs.com/wintersun/p/6219259.html