From Monolith to Microservices: Key Differences, Benefits, and Framework Choices

Monolithic Architecture

Definition

A monolithic application is packaged as a single WAR (Web Application Archive) that contains all code, resources (JSP, JS, CSS) and business modules (order, payment, logistics, points, etc.) in one deployment unit.

Advantages

Simple architecture; avoids many complexities inherent to distributed systems.

Development, testing and deployment are straightforward, especially deployment.

Disadvantages

Codebase grows with business expansion, leading to lower code quality and risky changes.

Deployment becomes slow (minutes to tens of minutes) as the artifact size increases.

Scaling requires replicating the whole application, raising hardware costs.

Adopting new technologies often requires major refactoring.

Microservices and Microservice Architecture

What is a microservice?

Microservices split a monolithic application into independent services, each with its own database and deployment unit, reducing coupling. For example, order, payment, logistics and points modules become separate services.

Microservice architecture characteristics

Develop a single logical application as a set of small, autonomous services.

Each service runs in its own process (or container).

Services communicate via lightweight mechanisms such as HTTP REST APIs.

Each service can be deployed independently.

Each service may own its own database, enabling decentralized data management.

Difference between microservice and microservice architecture

“Microservice” refers to the size and single responsibility of an individual service, while “microservice architecture” describes the overall management, integration and operational model of many such services.

Pros of microservice architecture

Services are small and highly cohesive, making code easier to understand.

Development focuses on a single responsibility per service, simplifying implementation.

Small, cross‑functional teams can work on individual services efficiently.

Scaling costs are lower because resources can be allocated per service.

Front‑end and back‑end can be decoupled; back‑end developers can concentrate on API performance and security.

Each service can have its own database, or multiple services can share a database when appropriate.

Cons of microservice architecture

Operational overhead increases; many containers/WARs must be managed (e.g., Kubernetes, Docker, CI pipelines).

Inter‑service communication adds latency and complexity.

Data consistency becomes challenging (distributed transactions, eventual consistency).

Debugging and issue localization are more time‑consuming.

Suitable scenarios

Large, complex projects with millions of lines of code.

Fast‑iteration projects that require multiple releases per day.

High‑concurrency systems that need elastic scaling.

Unsuitable scenarios

Stable business domains where only bug fixes or minor data tweaks are needed.

Projects with long release cycles (monthly or longer).

Data storage differences

Monolithic architecture typically uses a single shared database. Microservice architecture allows each service to own its own database, enabling decentralized data management.

Frameworks for Developing Microservices

Related frameworks

Spring Boot – rapid development of microservice‑based web applications.

Spring Cloud – a suite of tools for building microservice architectures (service discovery, configuration, circuit breaking, etc.).

Spring Cloud Alibaba – Alibaba’s implementation of the Spring Cloud standard, providing additional components (e.g., Sentinel for rate limiting).

Version selection guidelines

Spring Boot versioning

Example version: 2.1.6.RELEASE 2 – major version (second generation of Spring Boot).

1 – minor version (adds new features while remaining backward compatible).

6 – bug‑fix iteration.

RELEASE – stable official release. Other suffixes include SNAPSHOT (development build), M1…M2 (milestones), and RC (release candidate). Prefer the RELEASE or later SR variants.

Spring Cloud versioning

Angeles (1st generation)

Brixton (2nd generation)

Camden (3rd generation)

Edgware (4th generation)

Finchley (5th generation)

Greenwich (6th generation)

Hoxton (7th generation, still in development)

Spring Cloud versions are named after London Underground stations.

Release naming conventions

SNAPSHOT – mutable development build.

M – milestone (e.g., M1, M2) usually marked as preview.

RC – Release Candidate, a near‑final version.

SR – Service Release (e.g., SR1, SR2); GA (Generally Available) stable releases.

Typical flow for a version series:

Greenwich.RELEASE → bug found → Greenwich.SR1 → bug found → Greenwich.SR2

Recommendations

Avoid non‑stable or end‑of‑life versions.

Prefer official RELEASE or SR versions.

Versions SR2 and later are generally safe for production use.

References

Spring: https://spring.io/

Microservices article: http://blog.cuicc.com/blog/2015/07/22/microservices/