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

1. Monolithic Architecture

Monolithic applications are quick to develop and validate ideas, requiring relatively low resource and cost investment. However, as business complexity grows, monoliths suffer from IDE overload, scaling limits, deployment conflicts, limited extensibility, and poor handling of massive concurrent users.

Advantages

Fast development and proof of concept.

Cost‑effective in terms of manpower and infrastructure.

Disadvantages

Compilation slowdown with large codebases.

Inability to support large development teams efficiently.

Testing, deployment, and system conflicts.

Single‑technology‑stack lock‑in.

Poor scalability and limited high‑concurrency support.

Suitable Scenarios

For early‑stage projects where simplicity, moderate scope, and evolutionary design are priorities, a monolith is the most efficient and cost‑effective choice.

2. Microservice Architecture

Microservices enable large‑scale business, massive concurrent users, multi‑region deployment, and flexible cloud options (private, public, hybrid). They are the preferred choice for many internet companies.

Costs

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

Increased system complexity and need for comprehensive observability.

Organizational mindset shift.

Higher upfront infrastructure investment.

Typical Layered Model

The architecture is often divided into four layers:

Client layer – all network‑connected devices (mobile, web, IoT, etc.).

API‑Gateway layer – registration, discovery, authentication, rate‑limiting, circuit‑breaker, etc.

Microservice cluster – business services (user, order, etc.) and shared services (metadata, messaging).

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

3. When to Adopt Microservices?

Expert Opinions

Architect Yang Bo (former eBay architect) advises against early adoption because of high initial cost and complexity; recommends starting with a monolith until the product is validated. When business complexity grows and team size reaches roughly a hundred developers, microservices become beneficial.

Evaluation Criteria

Business complexity and growth rate.

Team size and development efficiency.

Technical readiness (infrastructure, DevOps, monitoring).

Resource investment and risk tolerance.

3.2 Implementation Options

Two main approaches:

Outsource architecture design and training to a consulting firm.

Hire experienced engineers to build and maintain the platform internally.

Both require a baseline of technical talent for long‑term maintenance.

Talent Reserve

Divide personnel into research‑oriented (core component development) and application‑oriented (technology adoption) roles.

Technical Reserve

Key knowledge areas include domain‑driven design, continuous delivery, distributed systems fundamentals, load balancing, CAP theorem, caching, DevOps, and containerization.

Team Size Assessment

Estimates vary from 10‑15 engineers for small‑to‑medium projects to around 100 for large enterprises; the exact number depends on business scope and the number of core services.

3.3 Risks

Extensive code rewrite and impact on existing modules.

Higher architectural and operational complexity.

Need for senior backend engineers familiar with microservice principles.

Potentially long cooperation cycles if external consultants are used.

3.4 Service Splitting Strategies

Two common methods:

Vertical splitting : divide by business domain based on coupling intensity (e.g., separate order, user services).

Horizontal splitting : extract common, independent functionalities used by multiple domains (e.g., metadata, messaging services).

Proper granularity is crucial; overly fine‑grained services increase aggregation overhead, while overly coarse services defeat the purpose of micro‑segmentation.

4. SOA vs. Microservices

SOA emphasizes centralized management and integration of existing applications, whereas microservices focus on distributed management, code reuse, and automation for rapid feature delivery.

5. Conclusion

Prefer simplicity: avoid unnecessary distribution.

Microservices are not a silver bullet; they require solid infrastructure automation.

Follow the principles of simplicity, suitability, and evolutionary design when deciding the architectural path.