Single service comparison

Cloud Run is a single fully-managed abstraction: one service object, one revision model, request-driven autoscaling to zero, and built-in HTTPS termination. Huawei splits this model across services: ServiceStage owns application lifecycle, pipelines, and framework governance (Spring Cloud, ServiceComb, Dubbo, Service Mesh), while CCI owns the serverless container substrate. Neither alone replicates Cloud Run's revision traffic-splitting or per-request concurrency knobs; capabilities must be composed and the control plane differs considerably.

Scaling and runtime semantics diverge. CCI scales pods in seconds and bills per second down to 0.25 vCPU, but does not natively scale to zero on idle or expose Cloud Run's concurrency-per-instance dial; it pairs with EIP/ELB rather than Google's integrated ingress. ServiceStage adds blue/green and dark-launch routing and integrates with AOM/APM for observability, but its unit of deployment is a component bound to CCE or CCI runtimes, not Cloud Run's unified revision object. Expect to redesign health checks, autoscaling targets, and traffic-shifting logic.

Operational responsibility shifts. Cloud Run hides node pools, OS patching, and cluster upgrades; on Huawei, CCI removes infrastructure management, yet ServiceStage plus CCE-based components still involve you in VPC/ELB, SWR image management, IAM scoping, and Security Container isolation posture. Pricing also differs: Google meterizes instance CPU/memory across requests, whereas Huawei bills pod-seconds on CCI plus ServiceStage/CodeArts/APM dimensions separately, so TCO recalculation is required before cutover.

Start with workload assessment. Cloud Run services that are stateless, HTTP/event-driven, and single-container map cleanly to CCI for the runtime; pair with ServiceStage when you need framework governance, CI/CD pipelines from CodeArts/GitLab, and microservice registry. If you only need container execution with scale-to-zero-like bursts and no application platform, CCI alone is the lighter target. Do not assume parity of revision traffic-splitting; budget rework for release controls and confirm regional availability of both services in your target region.

Replatform the application and config. Rebuild the container image for SWR with Huawei-compatible base images and re-wire env vars, secrets, and volumes (EVS/SFS on CCI). Replace Cloud Run IAM service identities with Huawei IAM and KMS-managed secrets; re-point triggers to APIG or ELB since Cloud Run's auto-ingress has no direct equivalent. Re-implement event sources (Cloud Tasks, Eventarc) against DMS or FunctionGraph, and adjust autoscaling from request-concurrency models to CCI pod autoscaling plus ServiceStage dark-launch rules.

Validate carefully before cutover. Run the migrated revisions in parallel behind APIG weighted routing, comparing latency, error rate, and cold-start behavior under realistic load; Cloud Run's per-request concurrency can produce lower instance counts than CCI's pod-per-request scaling, so load-test to size pods (min 0.25 vCPU) and establish HPA thresholds. Confirm graceful shutdown, connection draining, and revision rollback procedures work on the ServiceStage/CCI path, since Cloud Run's atomic revision model does not map one-to-one.

Mind gaps and cost-model changes. Cloud Run's all-inclusive metering (runtime, ingress, scale-to-zero) differs from Huawei's itemized billing of CCI pod-seconds plus SWR storage, APIG/ELB traffic, and ServiceStage/CodeArts runtime; recalc TCO with peak concurrency, request volume, retention, and cross-region egress. Document unsupported features (managed GPU concurrency tuning, Cloud Run jobs) and consider CCE with GPU nodes or FunctionGraph where Cloud Run's job/event models were used; treat reconciliation of these gaps as a migration prerequisite, not a post-cutover surprise.