Single service comparison

Cloud Run is request/event-driven with Knative-style service and revision objects, L7 HTTP traffic splitting, and scale-to-zero; Huawei CCI is a serverless Kubernetes pod engine exposed through Kubernetes-native APIs, ccictl, and the console with Layer-4 load balancing. CCI scales pods in seconds and supports sub-core sizing (0.25 vCPU) but does not advertise scale-to-zero or revision-based traffic management, so the request-traffic-control surface differs materially. Cloud Run's data model is Service/Revision/TrafficSplit; CCI's is Pod/Deployment/Service, requiring manifest re-architecting rather than a direct API port.

Huawei splits the serverless-container space across three non-interchangeable offerings: CCI (original engine, commonly co-executed with CCE for elastic burst of CCE pods), CCI 2.0 (next-generation serverless container engine on the QingTian architecture, the current default for standalone serverless pods), and Flexus CCI (lightweight economy-tier container compute instance). Cloud Run is a single product covering all these variants. CCI integrates with SWR for images, ELB for L4 traffic, and SFS Turbo/EVS/OBS for storage versus Cloud Run's Artifact Registry, Cloud Load Balancing, and Cloud Storage/Eventarc integrations.

Pricing and idle-cost semantics diverge sharply. Cloud Run bills per request in milli-CPU-seconds, memory-seconds, and request count, and charges nothing when scaled to zero. CCI bills per-second based on the pod's requested vCPU/memory for as long as the pod runs; without scale-to-zero, idle pods keep accruing charges, changing TCO math. Both rely on VM-level isolation for pod security, but operational responsibility for autoscaling policies, concurrency tuning, and rollout strategy shifts from Cloud Run's managed revision routing to Kubernetes-native constructs the operator must maintain.

First assess workload shape: containerize to OCI and capture Cloud Run service config (concurrency, timeout, CPU/memory limits, min/max instances, revision traffic weights, env vars, secrets, VPC egress). Choose CCI 2.0 for new standalone serverless pod workloads, original CCI where co-execution with a CCE cluster for elastic burst of CCE pods is desired, or Flexus CCI for lightweight/economy-tier container compute. Note that no Huawei target offers Cloud Run's revision-based traffic splitting or scale-to-zero, so request-driven autoscaling semantics must be re-engineered.

There is no one-click Cloud Run-to-CCI migration path; treat it as a re-deployment onto Kubernetes primitives. Push container images to SWR, map secrets and env vars to ConfigMaps and Secrets, and translate each Cloud Run Service into a Kubernetes Deployment plus Service (and an HPA or CCI autoscaling policy). Replace revision traffic splitting with a rollout strategy (e.g., Canary via Istio/CCE Ingress or Recreate/RollingUpdate) and Cloud Run Jobs with Kubernetes Job/CronJob constructs, since CCI has no first-class jobs abstraction.

Adapt runtime configuration to CCI's pod model: set pod CPU/memory requests including sub-core sizes, configure Layer-4 ELB or Ingress for HTTP entrypoints (Cloud Run's L7 managed ingress has no exact equivalent), wire persistent storage through SFS Turbo where stateful side data is needed, and connect to OBS/EFS-like data services. Adjust for Huawei region and quota availability, which differ from Cloud Run's regional model, and validate that features such as request-timeout knobs, max-concurrency, and binary/GPU acceleration map to CCI-owned parameters.

Validate scaling, cold-start, SLA, and cost before cutover: load-test CCI autoscaling thresholds and pod-start latency against Cloud Run's concurrent-request autoscaling, then cut over traffic via DNS or a shared ELB. Recalculate TCO using CCI's per-second pod billing rather than Cloud Run's per-request billing, factoring in the absence of scale-to-zero, retained idle pods, SWR storage, bandwidth/traffic, and optional ELB and observability add-ons. Document residual gaps: no scale-to-zero, no revision traffic splitting, no native Cloud Run jobs equivalent, L4-vs-L7 ingress differences, and different compliance/region footprints.