Reinventing DataWorks: How Microservices and Cloud‑Native Architecture Solve Legacy Pain Points

1. Pain Points

1.1 Heavy Historical Burden

DataWorks has accumulated many legacy issues since its inception in 2010, including multiple versions, diverse front‑end and back‑end stacks, and APIs that date back five years, making it difficult to retire outdated components.

1.2 Complex Soft‑Hardware Environment

The platform runs across Alibaba's hybrid cloud, requiring custom solutions for missing middleware and dealing with network, hardware, and even chip‑architecture differences between x86 and ARM.

1.3 One‑Touch Impact

In a traditional SOA, a change in a single service can affect the entire system, leading to fragile dependencies and costly releases.

1.4 Frequent Requirement Changes and Releases

Multiple teams need to release features on different clouds (private, public, hybrid) with varying cadences, causing coordination challenges and risk of large‑scale failures.

1.5 Internationalization Issues

Supporting 20+ regions introduces time‑zone, language, and localization complexities.

1.6 Dependency Coupling

Shared SpringBoot starters improve reuse but also propagate bugs across all dependent services.

1.7 Awkward Gray‑Release Mechanism

Current gray releases rely on manual switches, making iterative testing costly and error‑prone.

1.8 Uncertain External Services

External dependencies can fail unpredictably, leading to cascading failures in data integration pipelines.

1.9 Front‑End Talent Shortage

Limited front‑end resources hinder rapid UI development and component reuse.

2. Cooperation and Competition

Different industries (finance, government, internet, etc.) use DataWorks in vastly different ways, creating diverse requirements that the platform must accommodate through extensible APIs and plug‑in mechanisms.

3. Architectural Transformation

Adopting a cloud‑native microservice architecture—embracing DevOps, continuous delivery, and containerization—offers a natural fit for DataWorks' scale and complexity.

3.1 Microservice Architecture

Microservices enable incremental replacement of legacy monoliths, blue‑green deployments, canary testing, and language‑agnostic services.

3.1.1 Recognizing the Current State

DataWorks is a PaaS that needs to evolve toward SaaS capabilities via microservices.

3.1.2 Solving Pain Points

Legacy functions are gradually replaced by low‑coupling microservices, allowing blue‑green and canary releases to mitigate risk.

3.1.3 Evidence‑Based Architecture

Microservices act as lightweight SOA, enabling domain‑driven design, high cohesion, low coupling, and service‑mesh‑based gray releases.

3.2 Front‑End Integration

The XStudio plug‑in system built on single‑spa and qiankun allows front‑end slots to bind to back‑end microservices, enabling rapid component reuse and customization.

3.3 Plugin Runtime

Plugins such as Terminal, DWEditor, and the file explorer are packaged as microservices, allowing dynamic scaling and resource‑efficient execution.

3.3.1 DataWorks Microservice Platform (DMSP)

DMSP manages deployment, release, and service governance across private, public, and hybrid clouds, enabling continuous delivery of plug‑ins via Swagger integration.

4. Building the Ecosystem

Microservices foster an evolutionary ecosystem where multiple implementations of the same function compete, and the best solutions are selected automatically.

5. Front‑Back Combo

Team responsibilities shift toward domain‑driven design, with front‑end developers contributing to nodejs microservices and back‑end engineers focusing on platform stability.

6. Future Outlook

The vision is a continuously evolving, intelligent engineering system where architecture enables innovation, and future AI‑assisted development can further transform the platform.