- Serverless trông có vẻ tiện, nhưng trên thực tế lại tạo ra độ phức tạp, ràng buộc và chi phí cao
- Container mang lại tính di động, khả năng giữ trạng thái và quyền kiểm soát rõ ràng, phù hợp hơn với đa số trường hợp sử dụng
- Serverless có cấu trúc chi phí thiếu minh bạch, khó dự đoán, và gây ra độ phức tạp không cần thiết giữa các thành phần
- Khả năng mở rộng và sự tiện lợi của serverless chỉ phù hợp với một số ít trường hợp sử dụng hạn chế
- Trong môi trường vận hành thực tế, triển khai dựa trên container đơn giản hơn, dễ mở rộng hơn và hiệu quả chi phí hơn
Serverless Is a Scam. Just Use a Container.
Serverless là gì?
- Serverless là cách triển khai mã theo từng hàm riêng lẻ, để nền tảng đám mây tự động xử lý việc thực thi và mở rộng
- Nhưng trên thực tế, có những vấn đề sau
- Giới hạn thời gian chạy (ví dụ: AWS Lambda giới hạn 15 phút)
- Không thể giữ trạng thái (mỗi lần chạy đều khởi tạo lại)
- Vấn đề cold start
- Môi trường gần như không thể debug
- Thiết lập và cấu hình theo từng nền tảng
- Lạm dụng YAML
- Nhìn thì đơn giản, nhưng không phù hợp với các tác vụ phức tạp
Container: đơn giản, mạnh mẽ và nhàm chán theo nghĩa tích cực
- Container có các ưu điểm sau
- Khởi động nhanh
- Có thể chạy ở mọi môi trường
- Có thể giữ trạng thái (dùng
Docker volume)
- Không có giới hạn thời gian chạy
- Tự do debug, phát triển cục bộ và chuyển đổi giữa các môi trường vận hành
- Ví dụ mã:
docker run -v my-data:/data my-app
- Kết quả là có thể chạy workload có trạng thái một cách nhất quán ở bất kỳ đâu
- Không bị khóa nhà cung cấp, không có chi phí ẩn, không cần thay đổi kiến trúc vô ích
Định giá serverless: dễ khiến người dùng bối rối
- Chi phí serverless được cấu thành rất phức tạp
- Phí theo mỗi lần gọi
- Lượng bộ nhớ sử dụng
- Thời gian thực thi
- Lượng dữ liệu truyền tải
- Mức giá khác nhau theo từng region
- Chi phí truy cập khóa bí mật v.v.
- Ví dụ các thuật ngữ gây rối
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- Cấu trúc tính phí khó dự đoán có thể dẫn đến hóa đơn ngoài dự kiến
- So sánh: VPS $5 có mức phí cố định dễ dự đoán và cho phép kiểm soát toàn bộ tài nguyên
Phản biện luận điểm “serverless có thể mở rộng”
- Serverless về mặt kỹ thuật là có thể mở rộng, nhưng trên thực tế đa số ứng dụng không cần điều đó
- Phần lớn ứng dụng thực sự cần những thứ sau
- Tính dự đoán được
- Khả năng giám sát
- Giới hạn tài nguyên hợp lý
- Môi trường phát triển và staging
- Với mô hình dựa trên container, mở rộng cũng rất đơn giản
replicas: 5
- Hoặc có thể mở rộng theo chiều ngang bằng load balancer
Thiết kế stateless tạo ra những vấn đề nhân tạo
- Serverless ép buộc thiết kế hoàn toàn stateless
- Không thể dùng cache, session, file tạm hay kết nối lâu dài
- Kết quả là phải cần đến
- Cơ sở dữ liệu bên ngoài
- Cache phân tán
- Lưu trữ tệp
- Event bus
- State machine
- Cuối cùng, một ứng dụng serverless “đơn giản” lại có hơn 6 phụ thuộc SaaS
- Trong khi đó, với container có thể
- Cache trong bộ nhớ
- Ghi ra đĩa
- Duy trì session
- Chạy không giới hạn thời gian
Trả lời cho ý kiến “tôi không muốn quản lý server”
- Vẫn có cách dùng nền tảng dựa trên container mà không phải quản lý server trực tiếp
- Dùng các nền tảng như Sliplane, Railway, Coolify
- Hoặc chỉ cần Docker + systemd trên VPS là đủ
- Vẫn đảm bảo sự tiện lợi trong vận hành như triển khai theo Git, rollback, logging, metrics
- Đồng thời vẫn có khả năng hiểu và kiểm soát toàn bộ hệ thống
Phản biện luận điểm “serverless rẻ hơn”
- Ở mức tần suất gọi cực thấp, nó có thể rẻ hơn
- Nhưng chi phí tăng vọt trong các tình huống sau
- Khi lưu lượng vượt qua một ngưỡng nhất định
- Khi cần tăng bộ nhớ
- Khi khối lượng tính toán thực tế lớn
- Khi có nhiều truyền tải dữ liệu
- Serverless khiến việc tối ưu trở nên khó khăn vì nền tảng che giấu mọi thứ
- Ngược lại, container
- Có thể chạy liên tục ngay cả trên phần cứng rẻ tiền
- Có thể kết hợp với cache và lưu trữ
- Dễ benchmark và tuning
- Không có kiểu tính phí theo từng mili giây
Khi nào serverless thực sự phù hợp
- Phù hợp với các tác vụ không thường xuyên và không trạng thái như
- Hàm xử lý theo sự kiện (ví dụ: resize ảnh)
- Tác vụ chạy hiếm khi xảy ra hoặc webhook
- Công cụ nội bộ
- POC
- Khi cần scale up/down rất nhanh
- Nhưng với ứng dụng thực tế, nó sẽ sớm đụng đến giới hạn, và
- bạn sẽ phải trả cái giá lớn về thời gian, chi phí và độ phức tạp
Vì sao container là lựa chọn tốt hơn
- Container cung cấp
- Tính di động
- Quyền kiểm soát
- Sự đơn giản
- Tính minh bạch
- Sự linh hoạt
- Có thể triển khai một hoặc nhiều container, scale, giữ trạng thái, chạy tác vụ nền, kết nối DB đều được
- Cũng có thể chuyển nền tảng mà không cần viết lại mã
Tóm tắt (TL;DR)
- Serverless nghe có vẻ rất hấp dẫn trên lý thuyết
- Nhưng trong thực tế, nó là
- Thiếu minh bạch
- Tốn kém
- Quá phức tạp
- Bị thổi phồng quá mức
> Trước khi bắt đầu, hãy tự hỏi:
> “Liệu mình có thể đơn giản làm cái này bằng container không?”
- Nếu câu trả lời là ‘có’, thì bắt đầu với container là lựa chọn tốt hơn
Hành động tiếp theo được khuyến nghị
- Khuyến khích chia sẻ các trường hợp serverless gây ra chi phí ngoài dự kiến hoặc quy trình làm việc kém hiệu quả
- Đừng biến một vấn đề đơn giản thành thứ phức tạp quá mức
19 bình luận
Đã có xfaas rồi mà.. cũng có cả cf workers nữa. Có vẻ là một bài viết thiên lệch.
Khi thuê GPU, tôi đang nghĩ đến việc chạy tạm thời bằng serverless function.
Liệu với container cũng làm được như vậy không?
Từ các dịch vụ web hosting PHP ngày xưa, nếu bỏ PHP đi và thay vào đó là JS bị khóa chặt vào nhà cung cấp thì....
Tôi không thể ngừng nghĩ rằng sẽ rất khó để phân biệt chúng với các nền tảng serverless FaaS tiêu biểu.
Tất nhiên, là một kẻ sành đồ tệ chủ yếu dùng PHP và JS/TS, tôi vẫn đang tận dụng nó một cách khá hài lòng,
nhưng tôi cũng không thực sự hiểu vì sao nhiều người lại đánh giá thứ này là ngon đến vậy.
Theo quan điểm cá nhân của tôi, việc sử dụng dịch vụ serverless của nhà cung cấp là rủi ro, nhưng dùng container để chính công ty tự cung cấp môi trường serverless thì có vẻ là một ý hay. Có lẽ sẽ tốt nếu tận dụng serverless như một khái niệm chứ không phải như một dịch vụ.
Trước đây từng có tweet và video[1] về việc từ bỏ Edge rendering của vercel, cùng bài viết về serverless server (kkk)[2] khá hot nhỉ. Có vẻ tôi cũng có quan điểm tương tự với những bài viết xuất hiện khi đó.
Đây là ý kiến cá nhân, nhưng từ góc nhìn của một lập trình viên frontend, tôi nghĩ việc gắn serverless function vào các request của người dùng vẫn còn là câu chuyện khá xa vời (trừ khi ứng dụng bạn định làm chỉ là MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Tất nhiên, giống như cũng đã có bình luận trong bài đăng này, có vẻ đây là một bài viết cố tình giật tít quá đà :)
Ở góc độ người đã trải nghiệm cả môi trường dựa trên container (chủ yếu là ECS Fargate, cụm Kubernetes) lẫn môi trường serverless (AWS), tôi không thấy quá thuyết phục.
Những điểm được liệt kê là ưu điểm của môi trường dựa trên container cũng đồng thời có thể trở thành nhược điểm.
Những phần được nhắc đến như “có thể tự kiểm soát trực tiếp và có thể giữ trạng thái” cuối cùng đều trở thành các điểm phải quản lý, khiến độ khó vận hành tăng lên.
Với tôi, càng là tổ chức nhỏ, càng là tổ chức không có đội ngũ quản trị server chuyên nghiệp, thì tôi càng khuyến nghị mạnh mẽ serverless.
À, tôi đồng ý về chuyện việc tính chi phí phức tạp hoặc khó dự đoán, cũng như vấn đề vendor lock-in.
Vì có người nhắc đến trải nghiệm phát triển và khả năng quan sát nên tôi xin nói thêm,
Nếu thiết lập tốt môi trường tích hợp ban đầu thì cũng có thể có được trải nghiệm phát triển gần như tương đương với nền tảng container, thậm chí có thể còn gần với native hơn cả nền tảng container. (Cũng có nhiều công cụ phục vụ việc này.)
Còn về khả năng quan sát, nếu muốn làm sâu thì với serverless hay nền tảng container cũng đều không phải bài toán dễ như nhau. Tập trung hóa log, trực quan hóa các loại metric, APM, trực quan hóa mức sử dụng CPU/memory và từ đó xây dựng chiến lược scaling, v.v...
Nếu chưa đến mức đó thì tích hợp metric/log mà nhà cung cấp cloud cung cấp sẵn vốn đã rất mạnh, nên thực ra cũng tương tự nhau thôi.
Nói hơi mạnh một chút thì tôi muốn hỏi: 'Bạn đã thực sự làm serverless đến mức nào rồi?'...😅
Tuy cũng có thể nghĩ rằng chỉ đưa một vài endpoint cần thiết lên Lambda thì sẽ tốt hơn chăng. Ngay từ đầu tôi cũng không có kinh nghiệm phát triển serverless nên không thể nói chắc được, nhưng vì có vẻ nó sẽ phù hợp với một số trường hợp đặc thù nên tôi nghĩ cũng có điểm hay.
Có phải công ty viết bài này là một công ty nền tảng hosting container nên đã viết bài từ góc nhìn thiên lệch không nhỉ haha
Trước đây cũng có người nghi ngờ bài viết của một lập trình viên từ netlify (đối thủ cạnh tranh) bày tỏ lo ngại về nextjs (vercel) ở phía frontend. Nhìn phần bình luận thì có vẻ không thiên lệch.
Tôi làm bên frontend nên... cũng không quá gần gũi với mảng này, nhưng có vẻ tôi khá thường xuyên thấy meme “serverless (có server)” haha
Điểm đau quá lớn là trải nghiệm phát triển kém hơn hẳn so với native, và vì bản thân phần mềm phát sinh sự phụ thuộc vào nhà cung cấp hạ tầng nên một khi đã bám rễ thì rất khó thoát ra. Không chỉ ít tài liệu tham khảo hơn rõ rệt mà khả năng quan sát cũng quá kém.
Có vẻ Cloudflare là bên đang cố làm serverless cho ra hồn hơn so với các công ty khác. Cơ sở dữ liệu cũng serverless, lưu trữ key-value cũng serverless, thậm chí hàng đợi thông điệp cũng có loại serverless...
(Tất nhiên, khi thành ra như vậy thì đôi lúc cũng thấy khó chịu vì có cảm giác bị phụ thuộc và trói chặt hoàn toàn vào nền tảng)
Dù vậy, nếu debugging, khả năng quan sát và trải nghiệm phát triển không được cải thiện thì rốt cuộc vẫn chỉ là giậm chân tại chỗ.
Dùng Cloud Run đi
Vận hành dịch vụ bằng serverless là chọn sai công cụ.
Có những bài toán cụ thể cần đến serverless. Nó phù hợp cho các mục đích được sử dụng không thường xuyên.
Không biết với các dịch vụ container serverless thì có còn cùng quan điểm đó không nhỉ
Vì những vấn đề của các dịch vụ serverless hiện có (kiểu như Lambda), nên AWS đã tạo ra Fargate, rồi còn làm cả App Runner đơn giản hơn nữa 🤔
Thậm chí Google Cloud còn có Cloud Run, một dịch vụ container serverless scale-to-zero cực đỉnh nữa mà
Trong số đó thì cá nhân mình thấy trải nghiệm phát triển với Cloud Run là tốt nhất
Serverless là trò bịp (vẫn có server)
Ý kiến Hacker News
Ngay từ đầu nó đã không phải là serverless mà là serverlease.
kkkkk