How to Implement Cloud‑Native Architecture with SAE: A Step‑by‑Step Guide

What Is Cloud‑Native Architecture

Over the past decade, digital transformation has driven the convergence of technology and business, making the technical architecture the determinant of business models. Cloud‑native architecture upgrades cloud services and internet architecture, fundamentally changing the IT foundation of the commercial world.

From a technical perspective, cloud‑native architecture is a set of principles and design patterns based on cloud‑native technologies that separate non‑business code (elasticity, resilience, security, observability, etc.) from business logic, allowing the cloud to handle these concerns and enabling faster iteration with lower cost.

Why Enterprises Need Cloud‑Native Architecture

Rapid SaaS market growth (e.g., 2022 SaaS market expected to exceed 100 billion CNY) forces companies to innovate business models while facing challenges such as high operational costs, labor shortages, and the need for faster feature delivery.

Cloud‑native architecture addresses these pressures by offloading non‑functional capabilities to the cloud, improving scalability, availability, and cost efficiency.

How to Implement Cloud‑Native Architecture

Cloud‑Native Maturity Model (SESORA)

The model evaluates six dimensions—automation, serverless, elasticity, observability, resilience—across four maturity levels.

Traditional Architecture

Typical Java + Spring Cloud deployments run on ECS with SLB, requiring manual management of scaling and high availability.

Serverless (SAE)

SAE provides a Serverless PaaS platform that abstracts IaaS management, supports multiple languages, and offers high elasticity.

1. Create Namespace

In the SAE console, create a namespace to logically isolate environments (dev, test, prod).

2. Create Application

Choose the namespace, set application name, network configuration (auto or custom VPC/VSwitch), instance count, CPU/memory, and upload the JAR/WAR or image.

3. Bind SLB

Expose the service via a public SLB for load balancing.

4. Service/Config Center

SAE includes a built‑in Nacos service registry and configuration center; alternatively, use MSE Nacos/Eureka/ZooKeeper for higher availability.

Elasticity

SAE supports rapid scaling (seconds) via manual or automatic rules based on time schedules or metrics (CPU, memory, QPS, response time).

Observability

SAE integrates ARMS to provide metrics (CPU, memory, JVM GC, slow SQL) and distributed tracing for request call chains, enabling root‑cause analysis.

Resilience

SAE offers graceful shutdown (liveness/readiness probes), multi‑AZ deployment, and built‑in rate‑limiting, isolation, and circuit‑breaker rules for Java applications.

Automation (CI/CD)

SAE can be integrated into GitLab + Jenkins pipelines via a Maven plugin with three YAML configuration files (toolkit_profile.yaml, toolkit_package.yaml, toolkit_deploy.yaml). Example Maven command:

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

Alternatively, use SAE OpenAPI to embed 90% of console functionality into custom operation platforms.

Conclusion

After adopting SAE, the deployment architecture becomes fully cloud‑native, achieving high scores in the SESORA model (12/15) across serverless, elasticity, observability, resilience, and automation.