Serverless không như kỳ vọng – Nhiều đội ngũ đang quay lại dùng VM
Serverless từng được xem là lời giải hoàn hảo cho bài toán hạ tầng: không cần máy chủ, tự động mở rộng, trả tiền theo mức sử dụng. Nhưng khi hệ thống bước vào giai đoạn vận hành ổn định, nhiều đội ngũ kỹ thuật bắt đầu nhận ra rằng sự đơn giản trên sơ đồ kiến trúc không đồng nghĩa với sự đơn giản trong thực tế. Đó là lúc câu hỏi “có nên quay lại dùng VM?” dần xuất hiện.
Khi sự kỳ vọng vào Server kết thúc
Giống như nhiều đội kỹ thuật khác đã đặt rất nhiều kỳ vọng vào serverless.
– Không cần quản lý server.
– Không cần lo capacity planning.
– Trả tiền theo từng request.
Backend được chia nhỏ thành các function: xác thực, hóa đơn, thông báo, phân tích. Mỗi team phụ trách vài handler nhỏ. Nhìn trên sơ đồ, kiến trúc trông hiện đại, gọn gàng và rất “đúng xu hướng”.
Trong giai đoạn đầu, mọi thứ vận hành khá trơn tru. Traffic tăng đột biến không còn là nỗi lo. Deploy nhanh. Autoscaling không còn là khái niệm đáng sợ với các kỹ sư mới.
Nhưng rồi thực tế dần bộc lộ qua ba vấn đề quen thuộc.
– Cold start khiến bước thanh toán đôi lúc chậm thấy rõ.
– Debug một request phải lần qua nhiều service, nhiều dashboard và console khác nhau.
– Chi phí tiếp tục tăng ngay cả khi lưu lượng gần như không đổi.
Nhưng trên thực tế, chúng tôi đã đổi sự phức tạp hữu hình của server lấy một hệ thống gồm nhiều thành phần vô hình, khó kiểm soát và khó dự đoán.
Serverless gây ra vấn đề ở đâu?
Serverless hoạt động rất tốt với những workload ngắt quãng và độc lập: webhook, resize ảnh, các batch job thỉnh thoảng chạy. Vấn đề xuất hiện khi hệ thống của bạn không còn “bật – tắt theo sự kiện” mà vận hành như một dòng request ổn định suốt cả ngày.
Một số vấn đề thường xuyên lặp lại:
Cold start và tail latency: Người dùng không quan tâm nhiều đến thời gian phản hồi trung bình. Thứ họ nhớ là lần checkout mất vài giây chỉ vì function đã bị idle trước đó.
Debug phân mảnh: Log ở một nơi, metric ở nơi khác, cấu hình lại nằm trong một console khác. Một request chậm có thể biến thành quá trình mở hàng loạt tab trình duyệt chỉ để lần ra nguyên nhân.
Concurrency khó lường: Bạn suy nghĩ theo throughput nghiệp vụ. Nền tảng serverless lại áp đặt các giới hạn concurrency theo function, theo vùng. Cách hệ thống phản ứng khi traffic tăng đột ngột không phải lúc nào cũng rõ ràng cho đến khi có sự cố.
Kết nối database ở quy mô lớn: Mỗi instance function thường mở một kết nối database riêng. Khi tải cao, giới hạn kết nối có thể bị chạm trần trước cả CPU hay memory.
Sử dụng Benchmark để thay đổi
Lấy cùng một API endpoint và chạy trong hai thiết lập:
– Serverless function phía sau gateway tiêu chuẩn
– Một VM nhỏ với một container duy nhất và reverse proxy cơ bản
Giữ code giống hệt nhau. Handler chỉ làm một việc: đọc từ database và trả về một payload JSON rất nhỏ. Sau đó thực hiện chạy một bài load test cực kỳ “nhàm chán”.
# warm up
wrk -t4 -c50 -d30s https://api.example.com/orders
# main run
wrk -t8 -c200 -d120s https://api.example.com/orders
Con đường serverless có độ trễ trung bình tốt, nhưng tail latency rất xấu mỗi khi phải spin up instance mới. VM thì nhàm chán và có thể dự đoán được.
Sơ đồ kiến trúc
Khi vẽ lại kiến trúc trên bảng, mọi thứ trở nên rất rõ ràng.
Phiên bản serverless cho một request đơn giản:
Client
|
v
+———–+
| API GW |
+———–+
|
v
+——————+
| Auth function |
+——————+
|
v
+——————+
| Orders function |
+——————+
|
v
+————-+
| Database |
+————-+
Mỗi khối là một cấu hình, một quy tắc scaling, một điểm có thể lỗi. Trên slide thì đẹp, nhưng khi xử lý sự cố lúc nửa đêm thì rất mong manh.
Phiên bản VM:
Client
|
v
+———–+
| Nginx |
+———–+
|
v
+———————-+
| orders-service app |
+———————-+
|
v
+————-+
| Database |
+————-+
Nhiều đội ngũ đang quay lại dùng VM
Không ai thích thừa nhận rằng một quyết định công nghệ từng được ca ngợi lại không mang đến hiệu quả như mong đợi. Vì vậy, phần lớn những thay đổi này diễn ra rất âm thầm.
– Traffic ổn định: khi hệ thống xử lý request liên tục, idle time không còn là lợi thế lớn. VM hoặc container giúp hiệu năng và chi phí dễ dự đoán hơn.
– Workflow phức tạp: nhiều function call cho một hành động người dùng làm tăng độ phức tạp và rủi ro. Một service chạy liên tục đôi khi đơn giản và an toàn hơn.
– Chi phí bị soi kỹ hơn: khi hệ thống lớn dần, đội tài chính không chỉ nhìn vào “pay per use” mà quan tâm đến tổng chi phí dài hạn.
– Nhu cầu kiểm soát: khi hạ tầng bị trừu tượng hóa quá mức, đội kỹ thuật khó chủ động xử lý timeout, retry hay kết nối.
