When to Adopt Microservices: Evaluation, Risks, and Best Practices

1. Monolithic Architecture

Monolithic applications are quick to develop and validate ideas, and they require relatively low resource and cost investment.

Advantages

Fast development and proof of concept.

Lower human and material costs.

Disadvantages

IDE overload and slower compile times as code grows.

Difficulty scaling teams and maintaining efficiency.

Conflicts in development, testing, and deployment.

Limited to a single technology stack.

Poor extensibility and limited high‑concurrency handling.

Suitable Scenarios

For early‑stage projects where simplicity, adequacy, and evolution are key, a monolith is the most cost‑effective choice; it also serves as a solid foundation for later migration to microservices.

Layering Purpose

The core goal of any layered design is to keep boundaries clear so that changes in one layer (e.g., swapping Android for iOS) do not affect others.

Recommendation

If business requirements are unclear and the team is small, modestly improve the existing monolith rather than undertaking a full microservice rewrite.

2. Microservice Architecture

Advantages

Microservices support massive user traffic, multi‑region deployment, unlimited server scaling, and can run on private, public, or hybrid clouds, making them the default choice for large‑scale internet companies.

Costs

High technical threshold: requires service registry, monitoring, tracing, governance, containerization, DevOps, etc.

Increased complexity: service granularity, inter‑service communication, and debugging become harder.

Organizational shift: changes development culture and team structure.

Higher upfront investment: infrastructure and skill development.

Typical Layered Diagram

The architecture is usually divided into four layers:

Client layer: all devices that can connect (mobile, web, IoT, etc.).

API Gateway: service registration, discovery, authentication, rate‑limiting, circuit‑breaking, etc.

Microservice Cluster: business services (user, order, metadata) and shared services.

Event Bus: lightweight message‑queue‑based decoupling (e.g., RabbitMQ).

The difficulty lies mainly in defining service boundaries and managing service sprawl.

3. When to Adopt Microservices?

Expert Insight (Yang Bo)

Yang advises against starting with microservices because of high initial cost and complexity; a monolith is preferable until the product is market‑validated. Once the system grows and team size reaches roughly a hundred engineers, microservices become beneficial for productivity and scalability.

The key decision points are business complexity and team size.

3.2 Landing Conditions Evaluation

Deployment Options

1) Engage an external architecture consultancy for demos and training. 2) Hire experienced staff to build the architecture internally.

Talent Reserve

Two roles are needed: research‑oriented engineers who develop core platform components, and application‑oriented engineers who implement business services.

Technical Reserve

Core microservice stack plus surrounding technologies: domain‑driven design, CI/CD, distributed tracing, load balancing, CAP theory, caching, DevOps, containerization.

Team Size Assessment

Estimates range from a few specialists to a hundred engineers; the actual number depends on business scope and the amount of non‑functional services (gateway, tracing, governance) to maintain.

3.3 Risk Assessment

Wide‑scale rewrite: many existing components must be refactored.

High complexity: broad technology surface and architectural choices.

Personnel requirements: backend engineers need deep knowledge of microservice principles and open‑source components.

Collaboration mode: external partners can provide end‑to‑end transformation but may extend timelines.

3.4 Reasonable Splitting Strategies

Vertical Splitting

Divide by business domain based on the degree of inter‑relation; tightly coupled functions stay together, loosely coupled ones become separate services.

Horizontal Splitting

Separate shared, independent capabilities (e.g., metadata service, messaging service) that are used by multiple business services.

Summary

Incorrect service boundaries lead to frequent re‑architecting and higher costs; careful domain analysis is essential.

4. SOA vs. Microservices

SOA focuses on centralized management and integration, while microservices emphasize decentralized management, code reuse, and automation.

5. Conclusion

Distributed systems principle: "Avoid distribution if possible."

There is no silver bullet; microservices require solid infrastructure automation.

Follow the principles of simplicity, suitability, and evolution when making architectural choices.