Mastering Cloud‑Native Architecture: Practical Steps to Transform SaaS on Alibaba Cloud

What Is Cloud‑Native Architecture

Over the past decade, digital transformation has driven the convergence of technology and business, making the technical architecture the decisive factor for a company's business model. Cloud‑native architecture upgrades cloud services and internet architecture, fundamentally reshaping the IT foundation of enterprises.

Core Concepts

From a technical perspective, cloud‑native architecture is a collection of principles and design patterns based on cloud‑native technologies. It separates non‑functional code (elasticity, resilience, security, observability, canary releases) from business logic, allowing the cloud platform to handle these concerns, resulting in faster feature iteration, higher traffic tolerance, and lower system cost.

Why SaaS Companies Need Cloud‑Native Architecture

The rapid growth of the SaaS market (e.g., projected >¥1 trillion in 2022) creates opportunities for business model innovation but also pressures enterprises to respond quickly to market changes, reduce costs, and improve reliability. Cloud‑native architecture addresses these challenges by offloading non‑functional capabilities to IaaS/PaaS, improving scalability, high‑availability, and cost efficiency.

How to Implement Cloud‑Native Architecture

1. Cloud‑Native Maturity Model (SESORA)

The model defines six dimensions and four maturity levels. The article focuses on five dimensions: serverless, elasticity, observability, resilience, and automation.

2. Serverless (SAE)

Create a namespace to isolate environments.

Create an application (Java, Jar, War, or image) in the chosen namespace.

Configure resources (CPU, memory, instance count, VPC, security groups).

Set up health checks, lifecycle scripts, logging, persistent storage, and configuration management.

3. Bind SLB

Attach a public SLB to expose the service, either by creating a new SLB or using an existing one.

4. Service/Configuration Center

Choose between built‑in SAE Nacos, MSE Nacos, MSE Eureka, or MSE ZooKeeper depending on high‑availability requirements.

5. Elasticity

SAE supports manual and automatic scaling. Manual scaling adjusts instance count via the console. Automatic scaling offers time‑based and metric‑based policies (CPU, memory, QPS, response time) to handle traffic spikes.

6. Observability

Monitoring covers overall health, instance health, and interface health, providing metrics (CPU, memory, GC, slow SQL) and call‑chain tracing via ARMS. Detailed method‑stack and thread‑analysis help pinpoint performance bottlenecks.

7. Resilience

Graceful rollout and shutdown using Liveness/Readiness probes.

Multi‑AZ deployment by distributing VSwitches across zones.

Rate limiting and circuit breaking to protect the system during traffic bursts.

8. Automation (CI/CD)

Two approaches are described:

Integrate SAE deployment into GitLab + Jenkins using a Maven plugin and three YAML configuration files (toolkit_profile.yaml, toolkit_package.yaml, toolkit_deploy.yaml). Example command:

clean package toolkit:deploy -Dtoolkit_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml

Use SAE OpenAPI to embed 90 % of console capabilities into a custom operation platform.

Conclusion

After adopting SAE, the deployment architecture becomes fully cloud‑native, achieving 12 out of 15 points in the SESORA model (Serverless 3, Elasticity 3, Observability 2, Resilience 2, Automation 2). This solution offers a fast, practical path to high‑maturity cloud‑native SaaS systems.