Designing Ops‑Friendly Microservice Architecture: 6 Key Principles

Preface

Automation is a goal for operations, yet many focus solely on automation tools and overlook the business architecture that directly influences automation success. Because architecture determines operational efficiency and quality, this article shares six design points that make a system friendly to operations, based on years of experience at Tencent.

Key Point 1: Architecture Independence

When an architecture satisfies business needs while also meeting non‑functional operational requirements, it is considered ops‑friendly.

From an ops perspective, independence includes four aspects:

Independent Deployment

Independent Testing

Componentization

Technical Decoupling

① Independent Deployment

A single codebase can be deployed, upgraded, and scaled according to operational management requirements, with regional configuration handled via settings. Services communicate through API calls, making deployment independence a prerequisite for ops independence.

② Independent Testing

Operations can use lightweight test cases or tools to verify the availability of a service or architecture, allowing independent releases without developer or tester involvement each time.

③ Component Specification

Standardized frameworks within a company prevent different teams from using divergent tech stacks, avoiding uncontrolled architectural sprawl and reducing unordered growth of operational objects.

④ Technical Decoupling

Reducing inter‑service dependencies—and even code‑to‑configuration dependencies—lays the foundation for microservices, independent deployment, testing, and componentization.

Key Point 2: Deployment Friendliness

Continuous delivery emphasizes end‑to‑end automation; deployment is a high‑frequency, planned operation that must be efficient.

Effective deployment requires five dimensions:

① CMDB Configuration Before each deployment, ops need a clear view of the application’s relationship to architecture and business. Storing this information in a CMDB provides data for automation, monitoring, and alerting. ② Environment Configuration Standardizing development, testing, and production environments eliminates the “environment‑drift” problem that hampers deployment speed. ③ Dependency Management Packaging libraries and environment settings, and using scripts or container solutions, resolves cross‑environment dependency challenges. ④ Deployment Methods Adopt repeatable pipelines (e.g., Docker Build‑Ship‑Run or one‑click configurations) to achieve reliable, automated releases. ⑤ Release Self‑Testing Two parts: lightweight functional tests and change‑set verification (e.g., MD5 checks, port/config checks). ⑥ Gray‑Scale Release Gradual rollout—delaying or throttling irreversible changes—reduces risk and aligns with gray‑scale deployment principles.

Key Point 3: Operability

A microservice architecture must be highly operable; otherwise it wastes ops personnel.

Operability can be broken into seven areas:

① Configuration Management Separate binaries from configuration. Three management modes: file‑based, key‑value, and distributed configuration center. ② Version Management All operational objects (packages, configs, scripts) should be version‑controlled, similar to source code. ③ Standard Operations Standardize repetitive tasks (file transfer, remote execution, start/stop) into one‑click procedures to boost efficiency. ④ Process Management Define install paths, directory structures, process names, ports, and monitoring to improve automation and reduce unplanned work. ⑤ Space Management Plan disk usage, backup strategies, storage solutions, capacity alerts, and cleanup policies. ⑥ Log Management Separate business data from logs Decouple logs from business logic Standardize log format Clear return codes and comments Expose business metrics (request count, success rate, latency) Define key events Set log levels Retention and compression policies When applied, developers, ops, and business gain better monitoring and analysis capabilities. ⑦ Centralized Control Provide a unified ops platform that links change release, monitoring, incident handling, multi‑cloud management, etc., eliminating information silos and improving overall control.

Key Point 4: Fault Tolerance & Disaster Recovery

Operations focus on quality, efficiency, cost, and safety. High‑availability design includes:

① Load Balancing Stateless routing and intelligent address selection make clusters fault‑tolerant. ② Schedulability During incidents, shift users or services away from affected zones—core to Tencent’s QQ and WeChat reliability. ③ Multi‑Region Active‑Active Data high‑availability across locations underpins schedulability. ④ Master‑Slave Switching Read‑write separation and smart routing enable automatic failover. ⑤ Elastic Availability “Survive first, optimize later” – use flexible switches or built‑in throttling to prevent service avalanche under traffic spikes.

Key Point 5: Quality Monitoring

Monitoring is the main technical means to ensure and improve business quality.

① Metric Measurement Each architecture should expose a single, unique metric to avoid metric explosion. ② Basic Monitoring Network, link, host, and system metrics are non‑intrusive and easy to collect. ③ Component Monitoring Embedding monitoring in frameworks, routers, and middleware provides mid‑level data (request count, latency, etc.). ④ Business Monitoring Active or passive monitoring of business‑level indicators (request volume, success rate, latency) requires developer cooperation. ⑤ End‑to‑End Monitoring Trace calls across distributed services using transaction IDs or RPC links to reconstruct call chains and raise alerts. ⑥ Quality Assessment Closed‑loop management—coverage, completeness, incident handling, reporting—drives continuous improvement.

Key Point 6: Performance & Cost

Ops staff must ensure reasonable operational costs while maintaining performance.

① Throughput Performance Non‑functional testing during CI validates that the architecture can handle expected load. ② Capacity Planning Based on total request volume, plan service capacity while ensuring performance thresholds. ③ Operational Cost Optimizing bandwidth, hardware, and other resources reduces cash outflow without sacrificing quality or efficiency.

Conclusion

The author’s personal view, from an ops perspective, stresses that a well‑designed business architecture is essential for maximizing operational value, improving quality, efficiency, and cost. Ops must develop architectural awareness and collaborate with developers to continuously refine the system, embodying the DevOps spirit.