Tôi nhớ lại quãng thời gian không sao hiểu nổi serverless và quyết định hỏi mọi điều mình thắc mắc.

Máy chủ biến mất? Thân phận thật của vị pháp sư

🧙‍♂️（博士）「🐣, hôm nay chúng ta học về serverless. Chỉ nghe tên đã tưởng là ‘phép thuật làm biến mất máy chủ’, nhưng bản chất của nó bình dị hơn mà cũng rất sâu sắc.」

🐣（学生）「Không có máy chủ? Chẳng lẽ thầy giống Harry Potter hét lên 『Máy chủ, biến đi!』 rồi nó biến mất thật sao?」

🧙‍♂️（博士）「Ha ha, chín trên mười người ban đầu đều nghĩ vậy. Nhưng máy chủ đâu có biến mất. Chúng vẫn làm việc hết công suất trong lòng đám mây, chỉ là người dùng không phải bận tâm đến chúng mà thôi.」

🐣（学生）「Vậy chẳng phải là lừa đảo sao. Kiểu ghi là ‘rau hữu cơ’ nhưng phía sau lại phun đầy thuốc.」

🧙‍♂️（博士）「Ví dụ hơi lệch nhưng trúng ý. Chữ ’less’ trong serverless nghĩa là ‘ít phải quản trị’. Ngày xưa chúng ta phải nuôi máy chủ, cài hệ điều hành, xử lý sự cố — như chăm sóc một chú hamster. Với serverless, nhà cung cấp đám mây gánh hết.」

🐣（学生）「Hamster chết thì mình khóc, còn máy chủ chết thì khách hàng mắng, đau hơn nhiều.」

🧙‍♂️（博士）「Đã thế nửa đêm 3 giờ nó còn gọi bạn dậy ‘database không phản hồi’ nữa.」

📌 Ghi chú: Khái niệm nền tảng của serverless Serverless không có nghĩa là “không còn máy chủ”, mà là kiến trúc trong đó nhà cung cấp đám mây chịu trách nhiệm quản trị máy chủ.

  • Cách truyền thống: tự mua, lắp đặt và vận hành máy chủ
  • Serverless: nhà cung cấp quản lý toàn bộ hạ tầng, bạn chỉ tập trung vào code

Cơ chế serverless: ninja chỉ xuất hiện khi được gọi

🐣（学生）「Có vẻ khó dùng. Nó khác máy chủ thường ở điểm nào?」

🧙‍♂️（博士）「Đúng là có khác. Serverless chỉ ‘bật lên’ khi được gọi, xử lý xong rồi biến mất. Vì thế ứng dụng phải được thiết kế như một ‘vận động viên chạy nước rút’. Chạy marathon thì không hợp.」

🐣（学生）「Tức là ai đó hét ’tính ngay đi!’ thì nó xuất hiện, rồi vừa nghe ‘xong rồi’ là biến mất?」

🧙‍♂️（博士）「Chính xác! Như một ninja xuất hiện theo triệu tập. Khi ẩn mình trong mây, bạn không phải trả tiền thuê nhà lúc nó rảnh.」

🐣（学生）「Nhưng ninja mỗi lần nhảy ra một chỗ khác. Địa chỉ IP thế nào?」

🧙‍♂️（博士）「Câu hỏi hay! Họ không có địa chỉ cố định. Vì máy chủ thay đổi liên tục nên đám mây đặt API Gateway làm ’người gác cổng làng ninja’ để phân phối yêu cầu đến đúng ninja.」

🐣（学生）「Ra vậy. Nhưng nếu ninja thay đổi hoài thì đâu giữ được ký ức?」

🧙‍♂️（博士）「Đúng thế, nên phải thiết kế stateless. Không có chuyện ’tiếp tục câu chuyện hôm qua’. Mỗi lần đều như mới gặp một chú cá vàng vậy.」

🐣（学生）「Bất tiện quá. Vậy đăng nhập, phiên làm sao?」

🧙‍♂️（博士）「Lưu trạng thái ở ngoài: database, Redis v.v. Ninja không giữ trí nhớ, nhưng gửi những cuộn giấy quan trọng vào ‘kho chứa cuộn thư’.」

📌 Ghi chú: Vì sao phải thiết kế stateless Mỗi lần chạy, hàm serverless khởi động trong container mới nên trạng thái cục bộ (biến, file, session) không được giữ lại.

  • Quản lý trạng thái: dùng database ngoài, Redis, S3…
  • Phiên làm việc: JWT hoặc lưu ở kho ngoài
  • Tệp tin: mọi thứ ngoài xử lý tạm thời phải đưa ra storage bên ngoài

So với máy chủ truyền thống: thú cưng vs. ninja

🐣（学生）「Thầy cho ví dụ cụ thể được không?」

🧙‍♂️（博士）「Ví thử ’tạo ảnh thumbnail khi upload’. Máy chủ truyền thống phải trực 24/7 kiểu 『có ai đến không ta?』. Tốn điện, lại hay trục trặc.」

🐣（学生）「Giống bảo vệ đứng trước cửa chờ khách.」

🧙‍♂️（博士）「Chuẩn! Và đôi khi bảo vệ cảm cúm ngã quỵ. Với serverless, chuông 『ảnh đã upload!』 vừa reo là ninja xuất hiện, tạo thumbnail rồi biến mất.」

🐣（学生）「Có mất thời gian đợi ninja không?」

🧙‍♂️（博士）「Đó là vấn đề cold start. Ninja đang ngủ phải mất vài giây để dậy và chuẩn bị. Với ngôn ngữ nặng như Java thì như ninja ngái ngủ trải thảm yoga rồi pha bữa sáng.」

🐣（学生）「Bực thật. Vậy xử lý thời gian thực là thua?」

🧙‍♂️（博士）「Có cơ chế giữ ấm, nhưng nhìn chung serverless hợp với batch hoặc xử lý bất đồng bộ. Những việc kiểu 『trả lời ngay!』 thì không phải sở trường.」

Hiểu qua ví dụ: ứng dụng chia sẻ ảnh

🐣（学生）「Ví dụ cụ thể đi. Nếu làm app chia sẻ ảnh thì sao?」

🧙‍♂️（博士）「Hay đấy. Cách truyền thống sẽ như sau:」

Máy chủ truyền thống:

Web server chạy 24/7 (5.000 yên/tháng)
↓
“Ảnh đã upload”
↓
Xử lý tạo thumbnail trên server
↓
Lưu vào database

🧙‍♂️（博士）「Cách này dù không ai tải ảnh bạn vẫn trả 5.000 yên mỗi tháng. Như thuê mặt bằng mà chẳng có khách.」

🐣（学生）「Lãng phí thật.」

🧙‍♂️（博士）「Còn serverless thì:」

Phiên bản serverless:

Ảnh được upload lên S3
↓
Sự kiện S3 kích hoạt hàm Lambda
↓
Lambda khởi động (0,1 giây)
↓
Tạo thumbnail rồi lưu vào bucket S3 khác
↓
Lambda kết thúc
↓
Tính phí: chỉ thời gian chạy (khoảng 0,001 yên mỗi lần)

🐣（学生）「Vậy không ai dùng thì không tốn tiền?」

🧙‍♂️（博士）「Chuẩn! Dùng bao nhiêu trả bấy nhiêu. Nhưng nếu bùng nổ, hóa đơn cũng bùng nổ. Video lan truyền, 1 triệu lượt chạy…」

🐣（学生）「Thành 1.000 yên!」

🧙‍♂️（博士）「Tính vậy đúng, nhưng nhớ còn phí truyền dữ liệu, API Gateway, database. Không hiếm khi hóa đơn lên hàng chục nghìn yên. Thảm kịch thời hiện đại: 『viral rồi phá sản』.」

📌 Ghi chú: Lợi ích và rủi ro của việc tính phí theo mức dùng

Lợi ích

  • Gần như không cần vốn đầu
  • Tự động mở rộng theo lưu lượng
  • Không phải quản trị hạ tầng

Rủi ro

  • Hóa đơn cao bất ngờ (nhất là khi viral)
  • Mô hình giá phức tạp
  • Khó nhìn ra tổng chi phí khi ghép nhiều dịch vụ

Biện pháp

  • Đặt cảnh báo chi phí
  • Thêm giới hạn tần suất
  • Kiểm thử tải và ước lượng chi phí trước

Các loại serverless: chuyên môn của ninja

🐣（学生）「Nghe nói serverless cũng có nhiều loại?」

🧙‍♂️（博士）「Ba nhánh chính: FaaS (Function as a Service), BaaS (Backend as a Service) và container serverless.」

🐣（学生）「FaaS là gì?」

🧙‍♂️（博士）「Là dịch vụ kiểu 『chúng tôi chỉ nhận phần hàm』. AWS Lambda, Google Cloud Functions, Azure Functions. Bạn viết hàm, họ 『chạy khi được gọi và tính phí theo thời gian』 — y như quán sushi băng chuyền.」

🐣（学生）「Còn BaaS?」

🧙‍♂️（博士）「『Database, xác thực, push — để chúng tôi lo』. Firebase, Supabase, AWS Amplify. Giống như sống với ba mẹ: 『mẹ làm hết cho con』.」

🐣（学生）「Sống với ba mẹ thì sướng nhưng phải nghe lời.」

🧙‍♂️（博士）「Đúng. Đó là nguy cơ bị khóa nhà cung cấp. Chưa kịp nhận ra thì bạn đã 『không sống nổi nếu thiếu dịch vụ ấy』.」

Serverless mạnh ở đâu, yếu ở đâu

🐣（学生）「Nếu vậy cứ chịu khó làm thủ công có phải xong không? Sao phải dùng serverless?」

🧙‍♂️（博士）「Điểm mạnh là tốc độ. Nghĩ ra ý tưởng là tung lên ngay, lúc ít người dùng thì hầu như không tốn gì. Bạn có thể biến ý tưởng đêm qua thành sản phẩm sáng nay.」

🐣（学生）「Nhưng chắc chắn không phải thứ gì cũng hợp?」

🧙‍♂️（博士）「Đúng, ưu khuyết rất rõ:」

Điểm mạnh

  • Xử lý ảnh (upload → tạo thumbnail)
  • Chuyển đổi dữ liệu (CSV → JSON)
  • Gửi thông báo (email, push)
  • Job batch định kỳ (báo cáo hằng ngày)
  • API nhẹ (tìm kiếm người dùng, đọc dữ liệu)

Điểm yếu

  • Xử lý thời gian thực (chat, game)
  • Tác vụ dài (encode video, machine learning)
  • Ứng dụng cần quản lý trạng thái phức tạp
  • Hệ thống gắn chặt với legacy

🐣（学生）「Tức là 『bứt tốc nhanh nhưng không bền』.」

🧙‍♂️（博士）「Chuẩn! Chạy 100 mét thì vô địch, marathon thì chịu.」

Cái bẫy chi phí: ninja lĩnh lương theo giờ

🐣（学生）「Nếu người khỏe không cần, còn hóa đơn có thể giết, vậy chỉ người đầu óc mới hưởng lợi?」

🧙‍♂️（博士）「Đúng. Serverless là 『ai biết tính toán thì lời, sơ ý là nổ tung』. Không hiểu cơ chế tính phí thì xuống địa ngục.」

🐣（学生）「Địa ngục thế nào?」

🧙‍♂️（博士）「Ví dụ viết code lặp vô hạn. Máy chủ truyền thống chỉ ì ạch. Còn serverless sẽ 『triệu hồi ninja vô hạn』.」

🐣（学生）「Cả đội ninja làm việc liên tục rồi gửi hóa đơn? Ghê quá.」

🧙‍♂️（博士）「Đến cuối tháng nhận hóa đơn mới tá hỏa: 『Sao lại 1.000.000 yên?』. AWS đã có cả đống câu chuyện vài trăm nghìn yên.」

🐣（学生）「Sợ thật. Có cách phòng không?」

🧙‍♂️（博士）「Tất nhiên. Cài cảnh báo chi phí, giới hạn thời gian chạy, giới hạn số phiên song song. Nghĩa là viết rõ 『hợp đồng thuê ninja』.」

Thất bại thực tế: nỗi khiếp sợ khi bỗng nổi tiếng

🐣（学生）「Có ví dụ thực tế nào bị tính phí khổng lồ không?」

🧙‍♂️（博士）「Nhiều lắm. Nổi tiếng nhất là 『app chỉnh ảnh viral và nhận hóa đơn 3 triệu yên』.」

🐣（学生）「Nghe chi tiết với ạ.」

🧙‍♂️（博士）「Một startup làm app 『làm đẹp ảnh bằng AI』. Họ tính toán khoảng 0,1 yên mỗi ảnh.」

🐣（学生）「Rồi sao nữa?」

🧙‍♂️（博士）「Nó viral: 1.000.000 ảnh mỗi ngày. Mỗi ảnh xử lý lâu hơn dự kiến, thành ra 3 yên/ảnh.」

🐣（学生）「1.000.000 × 3 yên = 3.000.000…」

🧙‍♂️（博士）「Và kéo dài 30 ngày. 『Nổi tiếng rồi phá sản』 — bi kịch hiện đại.」

🐣（学生）「Không có biện pháp gì ư?」

🧙‍♂️（博士）「Không đặt giới hạn chi phí. 『Đâu ngờ lại viral thế』. Giờ thì ai cũng biết phải đặt 『trần thành công』.」

🐣（学生）「Nghe buồn cười: giới hạn mức thành công.」

🧙‍♂️（博士）「Đúng là trớ trêu. 『Tiếng hét vì vui mừng』 thành tiếng khóc thật sự.」

Trải nghiệm phát triển: khoái cảm phép thuật và nỗi đau ràng buộc

🐣（学生）「Vậy khi phát triển thì sao? Khác lập trình bình thường à?」

🧙‍♂️（博士）「Ban đầu rất đã. Viết hàm, bấm nút là toàn thế giới dùng được. Cảm giác như thành pháp sư.」

🐣（学生）「Nghe hấp dẫn thật.」

🧙‍♂️（博士）「Nhưng càng làm càng thấy mặt trái. Khó test local, debug cực khổ. Vừa thắc mắc 『sao không chạy?』 thì ninja biến mất, chỉ còn log.」

🐣（学生）「Như đến hiện trường vụ án chỉ còn dấu vết.」

🧙‍♂️（博士）「Chuẩn. Log lại tản mác khắp nơi: CloudWatch, X-Ray, CloudTrail — biến thành trò chơi thám tử.」

🐣（学生）「Phiền phức. Thà tự dựng máy chủ còn hơn.」

🧙‍♂️（博士）「Đó là chiếc bẫy của serverless. Mới đầu như phép thuật đơn giản, sau thành lời nguyền phức tạp. Nhưng khi quen rồi, khó quay lại cảnh ‘chăm máy chủ’.」

🐣（学生）「Thế là gây nghiện?」

🧙‍♂️（博士）「Đúng. 『Không phải lo máy chủ』 dễ gây nghiện. Nhưng đổi lại là 『lo hóa đơn』 và 『giới hạn thiết kế』.」

Serverless so với cách truyền thống: bức tranh chi phí thực tế

🐣（学生）「Cuối cùng thì cách nào rẻ hơn?」

🧙‍♂️（博士）「Tùy vào mức dùng và khả năng dự đoán. Hãy nghĩ bằng đồ thị:」

Máy chủ truyền thống

  • Chi phí cố định: 50.000 yên/tháng
  • Chi phí biến đổi: gần như 0
  • Mô hình ‘quán cơm suất’

Serverless

  • Chi phí cố định: gần như 0
  • Chi phí biến đổi: theo mức sử dụng
  • Mô hình ‘sushi băng chuyền’

🐣（学生）「Rẻ hay không còn tùy bạn ‘ăn’ bao nhiêu.」

🧙‍♂️（博士）「Đúng. Ăn ít → sushi băng chuyền (serverless). Ăn nhiều → cơm suất (truyền thống). Cụ thể:」

Dưới 1 triệu request/tháng: serverless rẻ vượt trội
Trên 10 triệu request/tháng: máy chủ truyền thống rẻ hơn
Ở giữa: còn tùy, phải tính cả chi phí vận hành

🐣（学生）「Lỡ dự đoán sai thì sao?」

🧙‍♂️（博士）「Thành đánh cược. 『Tưởng ăn nhiều ở quán cơm mà lại mất khẩu vị』 hay 『định ăn nhẹ ở sushi băng chuyền mà hóa ra đại tiệc』.」

Serverless sẽ thắng chứ?

🐣（学生）「Vậy serverless sẽ thành công hay thất bại?」

🧙‍♂️（博士）「Không có chuyện thắng tuyệt đối hay thua trắng. Máy chủ truyền thống, container và serverless sẽ cùng tồn tại. 『Thế giới cần cả ninja, kỵ sĩ và pháp sư』.」

🐣（学生）「Hiểu rồi. Không công nghệ nào giải quyết được mọi thứ.」

🧙‍♂️（博士）「Chuẩn. 『Không có viên đạn bạc』. Nhưng dùng đúng nơi thì nó cực kỳ lợi hại.」

🐣（学生）「Vậy ai nên dùng?」

🧙‍♂️（博士）「Những người như sau:」

Phù hợp với serverless

  • Muốn có sản phẩm chạy được càng nhanh càng tốt
  • Hiểu rõ cơ chế tính phí
  • Ưa quản lý nhẹ nhàng hơn là kiểm soát tuyệt đối
  • Hào hứng với công nghệ mới

Không hợp với serverless

  • Người thợ muốn nắm mọi thứ trong tay
  • Khó quản lý ngân sách
  • Đặt ổn định lên trên hết
  • Bị ràng buộc với hệ thống cũ

🐣（学生）「Tức là dành cho 『người tiết kiệm mê đổi mới』.」

🧙‍♂️（博士）「Mô tả tuyệt vời. Phải vừa thích sáng tạo vừa biết tiết kiệm.」

Kết: sống trong thế giới serverless

🐣（学生）「Cuối cùng thầy có khuyên dùng serverless không?」

🧙‍♂️（博士）「Tôi không nói ‘hãy dùng’, mà nói ‘hãy hiểu rồi dùng cho đúng’. Serverless là câu thần chú hiện đại: phải cân giữa sự tiện lợi và rủi ro hóa đơn.」

🐣（学生）「Thần chú à… Niệm sai là phản ngược lại mình.」

🧙‍♂️（博士）「Đúng thế. Phải học ‘cách niệm chuẩn’. Serverless là 『dùng đầu óc thì thắng, lơ là thì nổ tung』. Không hợp với người chỉ biết dùng sức, nhưng ai biết tận dụng thì có vũ khí mạnh.」

🐣（学生）「Tóm lại là:

  • Vận hành máy chủ: địa ngục thể lực
  • Serverless: sinh tồn bằng trí tuệ trước hóa đơn Đúng không?」

🧙‍♂️（博士）「Chuẩn không cần chỉnh. Chọn cái nào tùy bối cảnh. Nhưng 『không chọn』 thì giờ không còn là lựa chọn. Kỹ sư thời nay phải quyết định làm kỵ sĩ, ninja hay pháp sư.」

🐣（学生）「Em rõ rồi. Học chắc nền tảng trước, ninja tính sau.」

🧙‍♂️（博士）「Tư duy đó sẽ biến em thành ’người điều khiển ninja’ cừ khôi. Nhưng nhớ coi chừng hóa đơn.」

🐣（学生）「Vâng! Em sẽ bật cảnh báo chi phí!」

📌 Ghi chú cuối: Khung ra quyết định khi chọn serverless

Trước khi áp dụng serverless, hãy cân nhắc tổng thể các yếu tố sau:

Yếu tố kỹ thuật

  • Tính chất xử lý (batch hay thời gian thực)
  • Tần suất thực thi (ít hay nhiều)
  • Mức độ cần lưu trạng thái
  • Liên kết với hệ thống cũ

Yếu tố kinh doanh

  • Ngân sách đầu tư ban đầu
  • Năng lực đội vận hành
  • Độ chính xác của dự báo tăng trưởng
  • Mức chấp nhận khóa nhà cung cấp

Kết luận: serverless không phải thuốc chữa bách bệnh mà là kỹ thuật chuyên dụng phát huy sức mạnh khi dùng đúng chỗ. Hiểu và chuẩn bị kỹ sẽ biến nó thành vũ khí mạnh; chủ quan sẽ trả giá bằng hóa đơn khổng lồ.

Với kỹ sư ngày nay, serverless là lựa chọn nên có trong tầm ngắm — một công nghệ để áp dụng đúng nơi đúng lúc.