From Legacy Systems to Microservices: A Story of SOA, Service Decomposition, and Organizational Change

Original article reposted from the public account "Coderising".

After graduating, Xiao Ming secured a job in the information department of a large state‑owned enterprise to obtain a household registration. Over decades the company has built numerous information systems—small ones like OA, leave, vehicle‑management, payroll, and large ones like CRM and ERP—mostly purchased from vendors, with very few internally developed solutions.

Most of these systems are legacy, heterogeneous, and outdated, built on various hardware platforms, software environments, and programming languages. For example, the leave system is written in Delphi, the OA system runs on classic ASP under IIS, and they barely function with ugly interfaces.

Recently a new maintenance system was launched using the latest front‑end technologies, and Xiao Ming briefly explored React.

A foreign‑company sales representative visited, leading the department head to report to senior management. The company then announced a strategic move to break information silos and achieve business agility by adopting an SOA (Service‑Oriented Architecture) strategy, hiring an external consulting firm.

Xiao Ming recognized the buzzwords—SOA, ESB, SCA, BEPL—but did not understand the practical implications. The consultants introduced the idea of wrapping heterogeneous legacy systems into coarse‑grained web services accessible via HTTP, allowing inter‑service calls and orchestration of larger business processes.

The consultants also sold a large amount of hardware and software, demonstrating a small proof‑of‑concept system that impressed the company’s leadership.

However, the promised SOA integration never materialized; the promised inter‑connectivity and business agility remained absent.

Later, Xiao Ming met his friend Zhang Da‑pang, who works at an internet ride‑hailing startup. Zhang explained that their company, unlike the state‑owned enterprise, focuses on splitting a massive monolithic codebase (now over a million lines) into small, independent components that can be developed, tested, and deployed separately.

These components run as separate processes, expose lightweight HTTP‑based RESTful APIs (instead of heavyweight SOAP/WSDL web services), and are managed by dedicated cross‑functional teams responsible for specific domains such as passenger management, driver management, trip management, and payment.

Data is also partitioned, requiring database sharding, which introduces challenges around consistency, distributed transactions, and eventual consistency.

To ensure reliability, the startup performs “chaos testing” by randomly terminating service instances in production to observe system behavior, emphasizing that services must be stateless.

While this approach brings agility, it also brings drawbacks: increased complexity in service discovery, API aggregation, reduced efficiency compared to in‑process calls, and significant monitoring challenges due to many interacting instances.

When asked about a high‑level term for this architectural style, Zhang confirmed it is called "microservices," though he wishes for a more precise name akin to "Dependency Injection" for IoC.

Reflecting on the conversation, Xiao Ming realizes the cyclical nature of software architecture—systems that were once integrated become fragmented, and fragmented systems eventually need integration.

After three years at the state‑owned enterprise, Xiao Ming finally obtained a Beijing household registration and decided to jump to Zhang’s company to work on microservices.