Serverless (điện toán phi máy chủ) là mô hình trong đó bạn chỉ viết và tải mã hoặc chọn dịch vụ, còn nhà cung cấp tự lo máy chủ, tự co giãn từ không đến hàng nghìn bản sao theo lượng yêu cầu, và tính tiền theo lần gọi cùng thời gian chạy thực tế thay vì theo giờ máy bật. Máy chủ vẫn tồn tại, chỉ là bạn không thấy, không đặt cỡ và không trả tiền khi không có ai gọi.
Dạng phổ biến nhất là hàm như một dịch vụ (Function as a Service, FaaS): một đoạn mã nhỏ chạy khi có sự kiện, như một yêu cầu web, một tệp vừa tải lên, một tin nhắn vào hàng đợi, rồi kết thúc. Nhưng serverless còn bao gồm cơ sở dữ liệu, hàng đợi, kho lưu trữ tính tiền theo mức dùng và co giãn về không, đôi khi gọi là backend như một dịch vụ.
Bài này giải thích cơ chế bên dưới, cách tính tiền kèm một phép tính minh hoạ, những giới hạn kỹ thuật thường gây bất ngờ, và một khung để quyết định khi nào serverless hợp, khi nào máy ảo hay container rẻ và đơn giản hơn.
Nguồn gốc và định nghĩa học thuật
Dịch vụ hàm chạy theo sự kiện thương mại được nhắc đến nhiều nhất ra mắt năm 2014, và trong vài năm sau đó mọi nhà cung cấp đám mây lớn đều có dịch vụ tương đương. Tuy vậy, ý tưởng không trả tiền cho máy rảnh đã có từ trước, trong các nền tảng chạy ứng dụng quản lý cuối thập niên 2000, nơi lập trình viên chỉ tải mã lên và nền tảng tự lo phần còn lại.
Năm 2019, một nhóm nghiên cứu tại Đại học California, Berkeley công bố báo cáo kỹ thuật "Cloud Programming Simplified: A Berkeley View on Serverless Computing", nêu ba đặc điểm phân biệt serverless với đám mây truyền thống: tách rời tính toán khỏi lưu trữ, chạy mã mà không phải quản lý cấp phát tài nguyên, và trả tiền theo mức tài nguyên dùng thực thay vì tài nguyên đã cấp. Báo cáo cũng dự đoán serverless sẽ trở thành mô hình lập trình chủ đạo của đám mây, đồng thời liệt kê các giới hạn cần vượt qua như trạng thái, độ trễ và tính dự đoán của hiệu năng.
Định nghĩa này hữu ích vì nó giúp nhận ra những dịch vụ được gắn nhãn serverless nhưng thật ra vẫn bắt bạn trả tiền tối thiểu theo giờ hoặc chọn cỡ. Tiêu chí đơn giản nhất: khi không có tải, hoá đơn có về gần không hay không.
Cơ chế chạy: điều gì xảy ra khi một hàm được gọi
Kích hoạt bởi sự kiện. Mỗi hàm gắn với một hoặc nhiều nguồn sự kiện: cổng giao diện lập trình, hàng đợi, kho lưu trữ, lịch định kỳ, thay đổi trong cơ sở dữ liệu. Khi sự kiện xảy ra, nền tảng tìm một môi trường chạy cho hàm đó.
Môi trường chạy dùng lại hoặc tạo mới. Nếu có môi trường đã khởi tạo từ lần gọi trước còn rảnh, nền tảng dùng lại ngay. Nếu không, nó phải tạo môi trường mới: cấp một vùng cách ly, tải mã, khởi động trình thông dịch hay máy ảo của ngôn ngữ, chạy phần khởi tạo của hàm. Khoảng thời gian này gọi là khởi động lạnh (cold start).
Co giãn bằng nhân bản. Khi có một trăm yêu cầu cùng lúc, nền tảng chạy song song nhiều môi trường, mỗi môi trường xử lý một hoặc vài yêu cầu. Bạn không cấu hình số máy; bạn chỉ có thể đặt giới hạn đồng thời để bảo vệ hệ thống phía sau, như cơ sở dữ liệu.
Không trạng thái giữa các lần gọi. Môi trường có thể bị thu hồi bất cứ lúc nào sau khi rảnh, nên mọi dữ liệu cần giữ phải nằm ở dịch vụ bên ngoài: cơ sở dữ liệu, bộ nhớ đệm, kho lưu trữ. Thiết kế quên điều này là nguồn lỗi kinh điển, như đếm số lượt truy cập bằng một biến trong bộ nhớ.
Giới hạn thời gian chạy. Mỗi lần gọi có thời gian chạy tối đa, thường tính bằng phút, khác nhau giữa các nhà cung cấp. Tác vụ dài hơn phải chia nhỏ hoặc chuyển sang dịch vụ điều phối luồng công việc.
Cách tính tiền và một phép tính minh hoạ
Hàm serverless thường được tính theo hai thành phần: số lần gọi và lượng tài nguyên nhân thời gian chạy, thường đo bằng gigabyte bộ nhớ nhân giây (GB-giây). Đơn giá dưới đây là ví dụ giả định để minh hoạ cách tính, không phải bảng giá của nhà cung cấp nào; bạn thay bằng giá hiện hành của nền tảng mình dùng.
| Thành phần | Giả định | Cách tính | Kết quả mỗi tháng |
|---|---|---|---|
| Số lần gọi | 10 triệu lần; đơn giá giả định 5.000 đồng cho 1 triệu lần | 10 × 5.000 | 50.000 đồng |
| Tài nguyên | Mỗi lần chạy 200 mili giây với 0,5 GB bộ nhớ | 10.000.000 × 0,2 × 0,5 = 1.000.000 GB-giây | 1 triệu GB-giây |
| Đơn giá tài nguyên | Giả định 0,4 đồng mỗi GB-giây | 1.000.000 × 0,4 | 400.000 đồng |
| Tổng hàm | 50.000 + 400.000 | khoảng 450.000 đồng | |
| Chi phí đi kèm | Cổng giao diện lập trình, nhật ký, truyền dữ liệu, cơ sở dữ liệu | Tính riêng | Thường lớn hơn phần hàm |
Hai bài học rút ra từ phép tính. Thứ nhất, với tải thấp và không đều, như một hệ thống nội bộ chỉ dùng giờ hành chính, serverless thường rẻ hơn hẳn một máy ảo chạy suốt ngày đêm. Thứ hai, chi phí tỷ lệ thuận với tải: khi tải tăng gấp mười và đều đặn quanh năm, hoá đơn hàm cũng tăng gấp mười, trong khi vài máy ảo có cam kết sử dụng có thể xử lý cùng lượng việc với giá thấp hơn. Có một điểm hoà vốn, và nó nên được tính bằng số liệu thật.
Dòng cuối của bảng hay bị quên. Cổng giao diện lập trình tính theo số yêu cầu, nhật ký tính theo dung lượng, và mỗi lần hàm gọi cơ sở dữ liệu hay dịch vụ khác cũng có giá. Đánh giá chi phí serverless chỉ nhìn đơn giá hàm là đánh giá thiếu.
Khởi động lạnh và các giới hạn kỹ thuật khác
Khởi động lạnh là giới hạn được bàn nhiều nhất. Độ dài phụ thuộc vào ngôn ngữ, kích thước gói mã, lượng bộ nhớ cấp và việc hàm có nối vào mạng riêng hay không; với ngôn ngữ thông dịch và gói nhỏ thường ngắn, với nền tảng nặng như máy ảo Java chưa tối ưu và gói lớn có thể dài hơn rõ rệt. Với tác vụ chạy nền, độ trễ này không quan trọng; với giao diện người dùng cần phản hồi tức thì, nó có thể làm trải nghiệm chập chờn. Các nền tảng có tuỳ chọn giữ sẵn một số môi trường ấm, nhưng khi đó bạn lại trả tiền cho công suất chờ, tức một phần quay về mô hình cũ.
Giới hạn thứ hai là kết nối cơ sở dữ liệu. Cơ sở dữ liệu quan hệ truyền thống được thiết kế cho số kết nối vừa phải từ vài máy chủ ứng dụng. Khi hàng nghìn bản hàm cùng mở kết nối, cơ sở dữ liệu có thể hết kết nối và từ chối phục vụ. Giải pháp là dùng bộ gom kết nối, giới hạn đồng thời của hàm, hoặc cơ sở dữ liệu thiết kế cho kiểu truy cập này.
Giới hạn thứ ba là quan sát và gỡ lỗi. Một luồng nghiệp vụ có thể đi qua năm hàm, hai hàng đợi và một cơ sở dữ liệu; khi có lỗi, không có một máy chủ nào để đăng nhập xem. Cần đầu tư sớm vào nhật ký có cấu trúc và theo dõi phân tán. Cuối cùng là khoá chặt: mã hàm thường gắn chặt vào định dạng sự kiện và dịch vụ của một nhà cung cấp, nên chuyển đi tốn công hơn ứng dụng container.
So sánh serverless, container và máy ảo
Ba mô hình không loại trừ nhau; một hệ thống thực tế thường dùng cả ba cho các phần khác nhau.
| Tiêu chí | Hàm serverless | Container (có điều phối) | Máy ảo |
|---|---|---|---|
| Đơn vị tính tiền | Lần gọi và GB-giây | Tài nguyên cụm hoặc tài nguyên container | Giờ máy bật |
| Chi phí khi không có tải | Gần không | Thấp đến trung bình | Đầy đủ |
| Co giãn | Tự động, rất nhanh | Tự động, cần cấu hình | Chậm hơn, theo nhóm máy |
| Thời gian chạy tối đa | Bị giới hạn | Không giới hạn | Không giới hạn |
| Kiểm soát môi trường | Thấp | Cao | Cao nhất |
| Mức khoá chặt | Cao | Thấp đến trung bình | Thấp |
| Hợp nhất với | Tải nhọn, theo sự kiện, tác vụ ngắn | Dịch vụ chạy liên tục, nhiều dịch vụ | Phần mềm đóng gói, hệ thống cũ, tải đều |
Ranh giới giữa các cột đang mờ dần. Đã có nền tảng chạy container theo kiểu serverless: bạn đưa ảnh container, nền tảng tự co giãn về không và tính tiền theo thời gian xử lý yêu cầu. Lựa chọn này giữ được tính di động của container mà vẫn không phải quản lý cụm, nên là điểm khởi đầu hợp lý cho nhiều ứng dụng web cỡ vừa.
Ví dụ giả định về một hệ thống thương mại điện tử: trang sản phẩm và giỏ hàng chạy liên tục trên container có cam kết sử dụng; xử lý ảnh sản phẩm, gửi thư xác nhận đơn và đối soát thanh toán cuối ngày chạy bằng hàm serverless; phần mềm kế toán đóng gói của bên thứ ba nằm trên máy ảo. Mỗi phần nằm ở mô hình có chi phí và độ phức tạp hợp với đặc tính tải của nó.
Khi nào nên và không nên dùng serverless
Các tình huống dưới đây dựa trên đặc tính kỹ thuật vừa nêu, không phải sở thích công nghệ.
- Nên: xử lý tệp tải lên như thu nhỏ ảnh, trích xuất dữ liệu hoá đơn; tác vụ định kỳ như gửi báo cáo, đồng bộ dữ liệu đêm; giao diện lập trình có tải thấp hoặc rất nhọn, như cổng đăng ký sự kiện chỉ mở vài ngày; xử lý tin nhắn từ hàng đợi; tự động hoá vận hành hạ tầng.
- Nên thử: sản phẩm mới chưa biết tải, khi đội nhỏ muốn ra sản phẩm nhanh và chấp nhận viết lại một phần nếu tải lớn và đều.
- Không nên: dịch vụ chạy liên tục với tải cao và đều, vì chi phí thường vượt máy ảo hay container có cam kết.
- Không nên: tác vụ dài hàng giờ như xử lý video dài, huấn luyện mô hình, vượt giới hạn thời gian chạy.
- Không nên: ứng dụng cần độ trễ thấp ổn định từng mili giây hoặc kết nối giữ lâu, như trò chơi thời gian thực, nếu không có cơ chế giữ ấm.
- Cân nhắc kỹ: hệ thống có yêu cầu chạy được trên nhiều nhà cung cấp hoặc tại chỗ.
Câu hỏi thường gặp
Serverless có thật sự không có máy chủ không?
Không. Mã vẫn chạy trên máy chủ trong trung tâm dữ liệu của nhà cung cấp. Chữ "serverless" chỉ việc bạn không thấy, không quản lý và không trả tiền cho máy chủ khi không có tải; mọi việc cấp phát, vá lỗi, co giãn do nhà cung cấp lo.
Có nên viết cả ứng dụng web lớn bằng hàm serverless?
Được, nhưng cần cân nhắc. Chia một ứng dụng lớn thành hàng trăm hàm làm việc gỡ lỗi, kiểm thử và quản lý phiên bản phức tạp. Nhiều đội chọn cách chạy cả ứng dụng web trong một container trên nền tảng serverless cho container, giữ lợi ích co giãn về không mà ít mảnh hơn.
Làm sao tránh hoá đơn serverless tăng đột biến?
Đặt giới hạn đồng thời cho từng hàm, cảnh báo ngân sách, và đặc biệt cẩn thận với vòng lặp vô tình, như hàm ghi tệp vào chính kho lưu trữ kích hoạt nó. Với giao diện lập trình công khai, cần giới hạn tần suất gọi để một đợt lưu lượng bất thường không biến thành hoá đơn lớn.
Ngôn ngữ nào hợp với serverless?
Các ngôn ngữ khởi động nhanh và gói nhỏ thường cho thời gian khởi động lạnh ngắn hơn. Ngôn ngữ chạy trên máy ảo nặng vẫn dùng được, nhất là khi nền tảng có tính năng chụp sẵn trạng thái khởi tạo, nhưng nên đo trên chính ứng dụng của bạn.
Serverless có phù hợp với doanh nghiệp nhỏ ở Việt Nam không?
Phù hợp với các tác vụ tải thấp, không đều, vì chi phí gần như bằng không khi không dùng và không cần người vận hành máy chủ. Điểm cần lưu ý là độ trễ tới vùng trung tâm dữ liệu gần nhất và chi phí các dịch vụ đi kèm như cơ sở dữ liệu.