How to Choose a Serverless Architecture for High‑Elastic, Low‑Cost Apps with Alibaba FC

Background and Requirements

Xiao Wang, a programmer, manages applications on on‑premise servers that require manual operation, scaling, and monitoring. To reduce operational overhead and hardware costs, he plans to migrate two new online applications to the cloud, aiming for high elasticity, low cost, and minimal maintenance.

The two applications share several characteristics:

Strict latency and stability requirements for online services.

Highly variable traffic with unpredictable spikes, demanding rapid scaling.

Clear low‑traffic periods, mainly at night.

Long startup times (≈1 minute) for a Java SpringBoot order system and an AI image‑recognition service based on a large‑spec image.

From these, Xiao Wang derives three key goals:

Simplify operations: deliver a JAR or container image and run it with minimal configuration, avoiding dedicated ops, monitoring, and alerting work.

Achieve strong elasticity: automatic scaling up during traffic surges and scaling down when demand drops.

Improve cost efficiency by leveraging cloud resources.

Technical Options Considered

He evaluates three architectures:

Traditional stack: SLB + Elastic Compute Service (ECS) + Auto‑Scaling. This requires manual load‑balancer setup, scaling policy tuning, and custom log collection for monitoring and alerts.

Kubernetes (K8s): Uses Services and Ingress for traffic management and Horizontal Pod Autoscaler (HPA) for scaling. While it removes the need for SLB, HPA reacts on a minute‑level timescale; scaling up can lag behind traffic spikes, causing latency or failures. Lowering thresholds improves responsiveness but raises resource usage and cost. Additionally, Xiao Wang lacks K8s experience, adding learning overhead.

Function Compute (FC): A serverless, fully managed solution offering pre‑reserved mode and instance‑metric‑based auto‑scaling. FC provides rapid, fine‑grained scaling, built‑in HTTP triggers, integrated observability, and a pay‑for‑active‑resource model (no charge when idle).

Why FC Wins: Reserved Mode and Idle Billing

FC’s reserved‑instance mode solves the cold‑start problem of long‑running services. In reserved mode, a fixed number of instances stay warm, handling incoming requests instantly. When demand exceeds the reserved pool, FC automatically launches on‑demand instances.

FC also offers an "idle billing" feature: reserved instances are billed at 20 % of the active rate when they are idle (CPU frozen). This dramatically reduces cost while preserving the ability to handle sudden traffic spikes.

Cost Calculation Example

Assuming a reserved‑instance utilization of 60 % and a baseline cost of 1 unit, the total cost with idle billing becomes:

0.60 × 1 + 0.40 × 0.20 × 1 = 0.68, a 32 % reduction.

Configuration Steps

Reserved instances and idle billing can be configured via the FC console or SDK (Java, Go, Node.js, etc.). In the console, navigate to the Elastic Management page and create a rule for idle billing. Using the SDK, call the PutProvisionConfig API (see API reference).

After enabling idle billing, the billing console shows separate line items for active and idle resources, with a typical reporting delay of 3–6 hours.

Conclusion

Function Compute provides a high‑elasticity, zero‑ops, cost‑effective platform for online services with long startup times. The reserved‑instance mode eliminates cold‑starts, while idle billing cuts expenses by charging only 20 % for unused capacity. Together, these features enable developers like Xiao Wang to focus on business logic rather than infrastructure.