Cà phê buổi sáng với thằng bạn lâu năm làm ở một công ty e-commerce, hai đứa đang nói chuyện mấy vụ tối ưu hạ tầng thì nó bảo: “Tụi tao đang migrate qua Knative để scale to zero tiết kiệm chi phí lúc off-peak.”

Mình trong đầu cũng đầy 3 chấm cả đống tình huống “scale to zero” đã từng gây toang trong quá khứ. Nên viết bài này để chia sẻ với góc nhìn cá nhân cho anh em đang cân nhắc, đừng tin vào giấc mơ không tốn tiền mà vẫn có high availability.

1. Scale to zero không dành cho hệ thống yêu cầu phản hồi tức thì

Anh em nào từng support production real-time chắc hiểu: Chỉ cần cold start vài giây là dính lỗi business.

Ví dụ:

• Hệ thống loyalty khách hàng, backend trả điểm tích lũy cho app.
• Gateway thanh toán cần xác thực realtime với hệ thống.
• API bị gọi webhook từ bên thứ ba như Zalo OA, Facebook, Shopee…

Cái gì “phải có mặt ngay khi bị gọi” thì scale to zero là đập vào mặt chính mình.

2. Cold start là cái giá mà không ai chịu nhận

Scale to zero = chấp nhận khi có request mới thì mới spin up container (hoặc function). Khi đó:

• Container phải được pull image lại, nếu không cache.
• Init time của app có thể từ vài giây tới cả phút, tuỳ tech stack.
• App có cần warmup không? Có chạy background task không? Có preload không?

Thế là user request timeout. Sếp hỏi: “Sao lại lỗi?” DevOps ấp úng: “Dạ vì tụi em xài scale to zero ạ.”

3. Hệ thống thật không bao giờ ngủ vì traffic luôn unpredictable

Nhiều anh em bảo:

“Công ty em ít request, ngủ cũng được mà.“

Ngủ đến khi có traffic bất ngờ, rồi lên không nổi là xong phim.

Có hệ thống 3 tháng không ai dùng, đến khi launch campaign thì:

• Request tăng đột biến trong 10 phút.
• Pod chưa kịp warm thì queue đầy.
• Redis bị nghẽn, Kafka mất consumer, backend timeout.

Không có gì chết production nhanh hơn một cold-start đồng loạt.

4. Cost saving không đến từ scale to zero mà đến từ scale đúng

Sự thật hơi buồn: Bạn không tiết kiệm được bao nhiêu bằng scale to zero đâu.

• Tính theo giờ, GCP Cloud Run hay AWS Lambda tính phí thấp thật.
• Nhưng nếu app cần chạy 24/7, tính ra còn mắc hơn EC2/ECS/Fargate/K8s node thường.
• Đặc biệt nếu container image nặng, latency cao, thì số lần cold start ngốn tiền gấp đôi.

Tốt hơn là:

Scale to near zero, nhưng vẫn giữ 1 pod luôn warm.

5. Ai hay on-call mới hiểu, latency production không tha ai cả

Bạn không thể đi pitch với sếp rằng:

“Lỗi user thấy chỉ do hệ thống em đang… ngủ.”

Nó không phải câu trả lời cho khách hàng khi web không tải nổi, hoặc API 503 timeout.

Scale to zero là một luxury bạn chỉ nên bật ở dev hoặc demo environment. Còn production – phải có mặt 24/7 như một người lính gác.

Hết lời

Nghĩ sao viết vậy còn lại tiếp tục làm culi không sếp gank :D

Mình không nói scale to zero là tệ. Nó có chỗ đứng. Nhưng không phải ở những nơi mà người dùng kỳ vọng phản hồi dưới 1 giây.

DevOps không chỉ là tối ưu chi phí – mà là tối ưu trải nghiệm, sự tin cậy, và chịu trách nhiệm khi hệ thống fail.

Đừng để lời hứa “tự động scale, tiết kiệm tiền” làm mờ đi thực tế bạn phải sống cùng production mỗi ngày. Còn vẫn rất mong nhận được phản hồi từ anh em 😄🤙