Evolution of Enterprise Technical Architecture and Cloud‑Native Adoption: A Ziroom Case Study

Before cloud‑native architectures became popular, most discussions focused on microservice architectures; enterprises choose architectures based on their current stage and business problems, and a good architecture is one that solves those problems.

The chapter first introduces the evolution of enterprise‑level architectures that many companies experience: monolithic, distributed, microservice, and the recent middle‑platform architecture, then presents Ziroom's historical technical architecture as a concrete example of a medium‑size internet company's evolution.

2.1 Technical Architecture Evolution

Architecture is defined as a set of abstract patterns guiding the design of large software systems. Good architecture should support high concurrency, high availability, and high scalability, while also emphasizing reliability, performance, maintainability, extensibility, and security.

Common architecture classifications include business, functional, application, technical, and physical architectures, each focusing on different aspects such as processes, modules, service interactions, technology stacks, and hardware topology.

2.1.2 Monolithic Architecture

Early web applications packaged all services into a single deployable unit (e.g., a WAR running on Tomcat). While easy to develop and deploy for simple, low‑traffic scenarios, monoliths become a bottleneck as traffic grows, leading to coupling, deployment inefficiency, and the need for distributed architectures.

2.1.3 Distributed Architecture

Scaling horizontally by adding more servers introduces load‑balancing components to evenly distribute traffic and improve availability. Distributed systems also enable database sharding and service decomposition, but they increase inter‑service dependencies and operational complexity.

2.1.4 Microservice Architecture

Microservices further split applications into fine‑grained services, allowing independent deployment, technology heterogeneity, and higher availability. However, they bring challenges such as increased complexity, difficulty defining service granularity, higher operational overhead, and potential performance degradation due to long call chains.

2.1.5 Middle‑Platform Architecture

Inspired by Alibaba’s “big middle‑platform, small front‑end” concept, middle platforms aim to improve reuse across business lines by abstracting common capabilities (e.g., user management, order processing). Benefits include cost reduction, faster iteration, data‑driven operations, and better organizational collaboration, though adoption can be difficult.

2.2 Ziroom's Technical Development History

Ziroom, an O2O rental service founded in 2011, evolved its architecture as its business grew from a single line to multiple lines serving millions of users.

2.2.1 Business Background

Ziroom connects owners, properties, and tenants (C2B2C). The platform addresses supply‑demand mismatches, renovation mismatches, and service mismatches in the rental market.

2.2.2 Technical Evolution

Before 2015: PHP monolith managed assets; code stored in SVN; legacy code ~1 GB.

2015‑2018: Service‑oriented stage; Java replaced PHP; RPC communication; transition to distributed architecture.

2018: Foundation platform introduced Spring Cloud, Nacos, Pinpoint, Graylog, Apollo, and a second data center for disaster recovery.

2019: DevOps/SRE transformation; built platform capabilities (gateway, monitoring, config center, message queue, permission, user center).

2020: Full container‑and‑Kubernetes‑driven continuous delivery overhaul.

2.2.3 Current Architecture

Ziroom now operates multiple front‑end business lines supported by three major middle platforms:

Business middle platform – shared services such as coupon, rating, pricing, and messaging.

Data middle platform – core data assets (pricing, user profiles, property profiles, recommendation system) that power fast, multidimensional business insights.

Technical middle platform – high‑frequency capabilities (login, permission, profanity filter, IM, push, search) and foundational infrastructure (config/registry, monitoring, chaos engineering, gateway, circuit‑breaker, traffic routing, service governance).

2.3 Problems Encountered in Ziroom's Architecture

2.3.1 Stability Issues

Before 2019, a single business line experienced 13 incidents in 30 days, causing frequent outages. Root causes included outdated middleware versions, shared middleware instances causing cross‑service impact, and inconsistent environment configurations. After two years of remediation, incident distribution shifted to code errors (45 %), product design flaws, and data issues.

2.3.2 Development Efficiency Issues

Productivity was low because the full development lifecycle lacked digitalization; most projects had no proper management, and quality metrics were rudimentary.

2.3.3 Process System Issues

CI/CD processes were cumbersome; surveys showed low satisfaction (average 5.76/10) with pain points such as manual release steps, poor error visibility, lack of graceful shutdown, and excessive manual configuration.

Feedback highlighted desires for automated code checks, streamlined approvals, visual progress tracking, gray‑release capabilities, pre‑release validation environments, better monitoring, and intelligent configuration management.

2.4 Chapter Summary

The chapter defined technical architecture, distinguished common architecture types, and detailed Ziroom's architectural evolution. It showed that architecture evolves with business stages, and Ziroom faced stability, efficiency, and process challenges before embarking on a cloud‑native and DevOps transformation described in later chapters.