How Enterprise Architecture Evolves: From Monoliths to Cloud‑Native Platforms

Introduction

Before cloud‑native architectures, the most discussed model was microservices. The choice of architecture depends heavily on a company's current stage, and a good architecture solves the business problems it faces at that moment.

As quoted by Wang Xiaochuan at CNCC, technology and business relationships are like a car’s three components—wheels, engine, and steering wheel—representing technology support, technology drive, and technology disruption. Most companies are technology‑support oriented, iterating quickly on business before architecture catches up. No architecture is a silver bullet; the best one solves the current business challenges.

2.1 Technical Architecture Evolution

Definition and Classification

Architecture (software architecture) is a set of abstract patterns guiding the design of large software systems. It abstracts complex engineering into understandable modules, similar to scientific management, enabling division of labor across front‑end, back‑end, quality, and operations.

Characteristics of a Good Architecture

High concurrency, availability, and scalability.

Usability and reliability to ensure continuous business operation.

High performance for greater throughput and lower response time.

Maintainability to reduce support costs.

Extensibility to adapt to changing market and B2B needs.

Security to meet compliance such as personal information protection and data security laws.

Architecture Types

Business architecture : key processes, organization, and information flow (e.g., product selection, procurement, logistics in e‑commerce).

Functional architecture : detailed product functions (e.g., user management, order management).

Application architecture : layered structure of applications and their interactions (e.g., user center, search engine).

Technical architecture : technology stack and middleware (e.g., Spring Cloud, ZooKeeper, Redis, MySQL).

Physical architecture : hardware topology, network, firewalls, and servers.

2.1.2 Monolithic Architecture

Early web applications packaged all services into a single WAR running on Tomcat, directly accessing databases and files. This approach is lightweight for early stages but becomes a bottleneck as traffic grows, leading to tight coupling and deployment difficulties.

2.1.3 Distributed Architecture

To handle increased load, a single instance is expanded horizontally across multiple servers, requiring load balancing to distribute requests evenly. Distributed architecture adds load balancers, improves availability, and may involve database sharding.

Advantages include low coupling, clear responsibilities, easier deployment, and higher stability. The main drawback is increased dependency and maintenance cost across services.

2.1.4 Microservice Architecture

Building on distributed architecture, microservices further split applications into fine‑grained services. Benefits are reduced coupling, stronger autonomy, technology heterogeneity, and higher availability. Drawbacks include higher complexity, difficulty defining service granularity, 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 improve reuse and reduce duplicated development. Types include business middle platform, data middle platform, and technical middle platform. The technical middle platform provides common capabilities such as authentication, messaging, monitoring, and governance.

2.2 Ziru’s Technical Evolution

Ziru, an O2O rental brand founded in 2011, serves about 50 000 owners and 3 000 000 tenants. Its business grew from a single line to ten, prompting architecture changes.

2.2.1 Business Background

Ziru connects owners, houses, and tenants, solving supply‑demand mismatches, renovation inconsistencies, and service quality issues.

2.2.2 Evolution Timeline

Before 2015: Asset‑centric, PHP codebase managed with SVN; legacy code ~1 GB.

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

July 2018: Foundation platform built with Spring Cloud, Nacos, Pinpoint, Graylog, Apollo; second data center added for same‑city disaster recovery.

2019: DevOps and SRE practices introduced; platform capabilities (gateway, monitoring, config center, message queue, permission) formed a technical middle platform.

2020: Container and Kubernetes adoption; continuous delivery pipeline rebuilt.

2.2.3 Current Architecture

Today Ziru’s front‑end consists of multiple business lines (owner, rental, home‑decoration, customer service) supported by three middle platforms:

Business middle platform : reusable capabilities such as coupon, rating, pricing, and messaging services.

Data middle platform : core data (pricing system, user profiles, property archives, recommendation engine) enabling fast, multidimensional data access.

Technical middle platform : high‑frequency services (login, permission, profanity filter, instant messaging, push, search) and infrastructure tools (configuration, service registry, monitoring, chaos engineering, gateway, circuit breaking, traffic shading, service governance).

2.3 Challenges Faced by Ziru’s Architecture

2.3.1 Stability Issues

Before 2019, a single business line experienced 13 outages in 30 days, hindering feature development. Root causes included outdated middleware versions, shared MQ/Redis instances causing cross‑service impact, and inconsistent environment configurations. After two years of middleware governance, fault distribution shifted to code errors (45%), product design defects, and data issues.

2.3.2 Development Efficiency Issues

Prior to 2019, the full development lifecycle lacked digitalization; 90 % of projects were unmanaged, leading to low efficiency and poor quality metrics.

2.3.3 Process System Issues

Surveys revealed low satisfaction (average 5.76/10) with CI/CD processes, highlighting pain points such as lack of automatic compile error notifications, opaque merge/release steps, rigid release windows, unstable pre‑production environments, limited parallel branch releases, and cumbersome approval workflows.

Feedback suggested adding code quality checks, simplifying approvals, visualizing progress, supporting gray‑scale releases, improving environment consistency, and enhancing automation.

2.4 Chapter Summary

This chapter defined technical architecture, distinguished common architecture categories, traced Ziru’s architectural evolution, and identified stability, efficiency, and process challenges that will be addressed in subsequent chapters.

Content excerpted from "Cloud‑Native Implementation: Enterprise‑Level DevOps Practices" with publisher permission.