Computing Services Design: ECS, BMS, Auto Scaling and Containers
What to know
ECS is the workhorse. You choose an instance family matched to the workload (general-purpose, compute-optimized, memory-optimized, GPU/heterogeneous), an image (public, private, shared, or marketplace), EVS system/data disks, security groups, and an EIP if public access is needed. Purchase modes matter for cost: yearly/monthly subscription for steady workloads, pay-per-use for spiky or short-lived ones, and spot for fault-tolerant batch jobs that can tolerate reclamation. ECS supports resize (flavor change) and is the target type for most scaling groups.
BMS delivers a bare-metal server with no hypervisor layer: predictable performance, full hardware access, support for high-throughput network fabrics, and suitability for performance-sensitive databases, HPC, and big-data nodes. It is still managed by the cloud platform for network, storage attach, and lifecycle.
Auto Scaling (AS) needs a scaling configuration (flavor, image, disk, key pair, security group), a scaling group (VPC/subnet, min/desired/max, associated ELB backend pool), and a policy: scheduled, periodic, or alarm-based on a CES metric. Two parameters decide whether it behaves well in production - warm-up time (ignore a new instance's metrics until it is ready) and cooldown (prevent flapping). Lifecycle hooks let you run scripts to register/deregister instances gracefully before they are added or removed.
Containers: CCE is managed Kubernetes (Huawei runs the control plane), CCI runs containers serverlessly with no nodes, SWR stores images, and HPA/cluster autoscaler handle pod and node elasticity.
Traps
AS does not repair data - scaling a stateful database out is wrong; scale up or use read replicas. New instances must be stateless and bootstrapped from an image or script or they will serve stale config. Spot instances can be reclaimed mid-run.
Rule of thumb
Stateless tier → scale out with AS + ELB. Stateful tier → scale up, then read replicas. Never both on the same data.