Những câu chuyện kinh hoàng về serverless

• Nhiều trường hợp bị tính phí khổng lồ ngoài dự kiến thường xuyên xảy ra trên các dịch vụ SaaS và serverless khác nhau, và đây là một trang đã tổng hợp chúng theo cách dễ theo dõi
• Đã xuất hiện các trường hợp người dùng vốn đang trả phí thuê bao hàng tháng bình thường nhưng do tấn công DoS hoặc sử dụng tài nguyên thiếu kiểm soát mà bị tính phí từ hàng chục nghìn đến hàng trăm nghìn USD chỉ trong một ngày
• Ở một số dịch vụ, ngay cả khi đã đặt giới hạn chi tiêu, phí vượt mức vẫn bị áp dụng, làm lộ rõ những giới hạn mang tính hệ thống
• Cộng đồng lập trình viên chia sẻ những trải nghiệm như vậy và chỉ ra cấu trúc tính phí phi lý cùng sự thiếu minh bạch là các vấn đề chính
• Trong môi trường serverless và cloud, chỉ một sai sót nhỏ hoặc một cuộc tấn công cũng có thể gây thiệt hại tài chính rất lớn, nên cần đặc biệt chú ý

---

Tổng hợp các trường hợp bị tính phí quá mức trên dịch vụ serverless và SaaS

#1 Khoản phí khổng lồ phát sinh trên Webflow

• Trong khi dùng gói 69 USD/tháng, người dùng bị tính $1,189.42 cho một tháng mà không có lý do rõ ràng

#2 Trường hợp trang game WebGL bị tấn công DoS

• Sau khi xảy ra tấn công DoS, người vận hành một trang tải lên game WebGL quy mô trung bình đã nhận hóa đơn từ Google Firebase hơn $100,000 chỉ trong một ngày

#3 Vercel Pro và việc vượt quá giới hạn chi tiêu

• Dùng gói Vercel Pro với giá $20/tháng và đặt giới hạn chi tiêu $120, nhưng vẫn phát sinh thêm phí ngoài dự kiến

#4 Tính phí dự án và hóa đơn cực lớn

• Có trường hợp một dự án vốn chỉ trả $50 mỗi tháng nhưng một sáng nọ lại nhận hóa đơn lên tới $70,000

#5 Vấn đề tính phí khi dùng BigQuery và bộ dữ liệu công khai

• Trong môi trường Playgroud, một người dùng BigQuery đã bị tính khoản phí khổng lồ hơn $22,000

#6 Phí hosting quá cao so với lượng truy cập nhỏ

• Dù chỉ có 9,000 lượt truy cập mỗi tháng, dịch vụ vẫn bị tính $250/tháng, tương đương $3,000 mỗi năm

#7 Vấn đề phát sinh sau khi Devin(AI) thay đổi codebase

• Đã có trải nghiệm về những hậu quả ngoài dự kiến khi AI tên Devin thực hiện thay đổi mã nguồn

#8 Bất ngờ bị tính phí sau thời gian dùng miễn phí

• Dù chưa từng thanh toán lần nào, một ngày nọ người dùng vẫn bất ngờ bị tính $530

#9 Tính phí với trang tài liệu và các dự án nhỏ khác

• Có nhiều trường hợp bị tính phí cao ngay cả với dịch vụ sử dụng ít, chẳng hạn một trang tài liệu đơn giản bị tính gần $400

#10 Nỗi kinh hoàng của free tier

• Ngay cả hóa đơn khoảng $103 cũng bị xem là vấn đề; đặc biệt, việc đang dùng free tier mà bất ngờ nhận hóa đơn là yếu tố gây lo ngại

#11 Cloudflare, AWS và các vấn đề khác

• Có trường hợp Cloudflare thông báo phải trả $120,000 trong vòng 24 giờ và đồng thời ngừng dịch vụ
• Trên AWS S3, vẫn phát sinh các khoản phí ngoài dự kiến ngay cả sau khi tạo bucket rỗng, riêng tư
• Nhiều nhà cung cấp khác cũng lặp lại các trường hợp tương tự, như Netlify gửi hóa đơn chưa thanh toán trị giá $104,500

#12 Tấn công DoS, email và mất dữ liệu

• Trong một cuộc tấn công DoS, việc gửi email đã tiêu tốn $11,000, sau đó cơ sở dữ liệu cũng bị mất

#13 Vercel bị tính phí hàng loạt, vấn đề tài khoản và trial

• Trên Vercel, một cuộc tấn công spam đã khiến hóa đơn lên tới $23,000 chỉ trong một ngày, đồng thời kích hoạt 56.000 tài khoản và trial

#14 Khoản phí ngoài dự kiến trong quá trình test/deploy

• Có trường hợp khi deploy tính năng lên Vercel và các dịch vụ tương tự cho mục đích thử nghiệm thì phát sinh khoản phí ngoài dự kiến
• sitemap.txt sử dụng băng thông đến hàng trăm GB, dẫn đến hóa đơn rất lớn

#15 Chi phí test của Firebase và Cloud Run

• Chỉ với hai lần test Firebase và Cloud Run, một dịch vụ đã tiêu tốn $72,000 và rơi vào nguy cơ phá sản

Kết luận và hàm ý

• Cấu trúc chi phí trong môi trường serverless và cloud có thể thiếu minh bạch hoặc rất dễ tổn thương trước tấn công và sai sót
• Có rất nhiều trường hợp bị tính phí ngoài dự kiến, vì vậy khi vận hành dịch vụ cần giám sát chặt chẽ, quản lý mức sử dụng và thiết lập giới hạn cho phép
• Nếu các chức năng tự động hóa và giám sát còn yếu, chỉ một lần thử nghiệm đơn giản hoặc một cuộc tấn công từ bên ngoài cũng có thể gây ra tổn thất ngoài dự kiến lên tới hàng chục nghìn USD
• Với lập trình viên, startup và người dùng SaaS, tầm quan trọng của quản lý chi phí và nhận thức rủi ro đang ngày càng tăng

[ahwjdekf]

Tôi từng phát triển cho DW nội bộ của một tập đoàn lớn, đó là công việc chuyển dữ liệu on-premise hiện có sang AWS. Nhưng dù đã hoàn tất vài tháng phát triển và kiểm thử, cuối cùng dự án vẫn bị hủy. Lý do là chi phí bị tính mỗi tháng có vẻ sẽ cao hơn nhiều so với dự kiến. Ngay cả các tập đoàn lớn cũng không dễ chi tiêu cho cloud.

[regentag]

Tôi cũng từng tạo tài khoản AWS để học, rồi sau đó bị tính phí một khoản nhỏ.
Có vẻ tài khoản đã bị xâm nhập, ai đó đã tạo và chạy instance bằng tài khoản của tôi...
Tôi dừng lại khá nhanh nên chỉ mất một khoản nhỏ thôi. Vì không thể dành thời gian để quản lý, cuối cùng tôi đã chọn cách xóa hẳn tài khoản.

[ifmkl]

Mình muốn khuyên rằng trước khi bắt đầu với cloud, bạn nên dựng môi trường mini server để tích lũy thêm chút kinh nghiệm thử nghiệm hoặc vận hành bằng các máy cấp n100, n150 đang rất phổ biến dạo này.

[crawler]

Có vẻ điều thật sự đáng sợ là dù chỉ là một dự án rất nhỏ, một khi đã đưa lên nền tảng thì nếu có lỗ hổng, nó có thể dẫn đến thiệt hại tài chính.

Tôi đã đặt Cloudflare ở phía trước nội dung của mình, nhưng hacker tìm ra các đối tượng không được cache rồi đánh hơn 100 triệu lần. Khi tôi chặn lại, chúng còn trực tiếp tìm ra cả địa chỉ bucket gốc và tấn công tiếp.

Tôi cũng tò mò không biết trong những trường hợp như thế này họ có hoàn tiền chi phí hay không.

[GN⁺]

Ý kiến trên Hacker News

• Khi học lập trình ở bootcamp, tôi từng thử tạo một instance elastic beanstalk miễn phí. Họ yêu cầu thẻ tín dụng để xác minh danh tính, lúc đó tôi không nghĩ đó sẽ là vấn đề. Nhưng sau đó máy chủ của tôi bị bot spam tấn công và Amazon tính phí tôi 100.000 đô la. Cuối cùng tôi được hoàn tiền, nhưng từ ngày đó tôi ghét Amazon và tự nhủ rằng nếu phải dùng điện toán đám mây thì sẽ chọn dịch vụ khác. Tôi không thích cái cấu trúc bảng điều khiển phức tạp và cách thiết kế dễ khiến khách hàng bối rối rồi mất tiền. Chỉ cần dùng thẻ tín dụng như một phương thức xác minh và chặn bot là đủ rồi. So với việc ở cửa hàng tạp hóa bạn có thể dễ dàng mua vài chiếc bánh quy bằng thẻ tín dụng, tôi thấy fintech lẽ ra có thể được dùng hữu ích hơn nhiều mà họ lại không làm vậy
  • Đây là một trong những lý do khiến cloud hosting đáng sợ. Không chỉ Amazon, Azure hay Google Cloud cũng "thường thì" sẽ hoàn tiền. Nhưng nếu một dự án demo của tôi chỉ có 5 lượt truy cập mỗi tuần bỗng bị DDOS và công ty hosting lần này lại nói đây không phải trường hợp "thường thì" rồi yêu cầu chuyển khoản, tôi có thể rơi vào nguy cơ phá sản
  • Hiện tôi đang bị tính phí 25.000 đô la. Trước đây tôi đã bật data plane auditing của SQS và thực tế lại nối nó vào feed sự kiện audit theo thời gian thực. Kết quả là mỗi sự kiện audit thuần túy lại tạo ra sự kiện ghi log theo kiểu vòng lặp vô hạn. Một tài khoản gần 10 năm nay trung bình chỉ tốn 2 đô la/ngày, bỗng một ngày nhảy lên 3.000 đô la/ngày, và AWS không hề có bất kỳ cảnh báo hay can thiệp nào
  • Tôi thắc mắc vì sao lại ghét Amazon khi họ đã hoàn lại 100.000 đô la. Trường hợp của tôi thì AWS luôn hoàn tiền ngay cả khi hóa đơn đắt đỏ hoàn toàn do lỗi của tôi. Nếu có một chính sách kiểu “vượt ngân sách là tắt hết”, thì hẳn cũng sẽ có vô số bi kịch khác kiểu “bị DDOS nên AWS tắt toàn bộ EC2 và tôi mất luôn dữ liệu trên ephemeral storage”
  • “Đây là chuyện cực kỳ đơn giản, chỉ cần một câu lệnh if là có thể tắt instance khi tài khoản vượt hạn mức và dump dịch vụ sang static drive. Họ chỉ là không muốn làm vậy—họ muốn tận dụng quy mô để tối đa hóa lợi nhuận trên lưng khách hàng. Những kẻ từng làm cả thiên hạ khốn khổ vì cloud compute giờ cũng đang cố trục lợi kinh tế từ chi phí AI nhờ đà chiếm lĩnh thị trường. Dạo này edge compute dễ hơn là vì crypto khiến người ta đầu tư quá mức vào ổ cứng. Cuối cùng thị trường lại khuyến khích bong bóng và hành vi xấu, tạo điều kiện cho những kẻ lạm dụng sức mạnh thị trường thay vì xây dựng niềm tin. Đám phản diện thông minh với thái độ xảo quyệt kiểu ‘mày chỉ là không hiểu thôi! (à mà trước khi thị trường sụp thì nộp thêm tiền đi)’ mới là thứ gây nhức đầu nhất ngành này. Ngay cả hãng taxi cũng không tính bạn một nghìn đô chỉ vì không chở bạn tới nơi. Thật khó tin khi nói không thể thêm một câu if vào máy chủ. Chẳng lẽ Amazon còn tệ hơn cả công ty taxi? Có khi đúng thật. Đây chính là lý do ‘Waymo’ ra đời (có thể là đùa thôi)”
• Tôi cứ tưởng sẽ kể về nỗi đau của serverless trong hosting/phát triển/debug, hóa ra lại là chuyện giá cả bùng nổ. Vì chi phí băng thông chưa từng quá nghiêm trọng với tôi nên tôi thường lướt qua những bài như vậy, nhưng bài này thì khá lạ—trường hợp bucket S3 rỗng cũng có thể làm hóa đơn AWS bùng nổ, kể rằng chỉ cần gọi API không xác thực vào S3 của người khác cũng có thể đẩy phí sang cho họ. Với tôi đây là thông tin mới
  • Tôi nghĩ ngay sau khi bài blog về hiện tượng này gây chú ý thì họ đã xử lý: Amazon S3 ngừng tính phí với một số mã lỗi
  • Một trong những vấn đề thực sự của môi trường serverless là bản thân nền tảng giống như một hộp đen rất thiếu minh bạch (dù đó cũng là giá trị mà serverless bán ra). Chúng tôi thừa hưởng một backend Lambda lớn, và khi gặp các vấn đề nội bộ của nền tảng như lỗi ngắt socket ngắt quãng khi kết nối với secret extension thì việc truy vết cực kỳ khổ sở. Môi trường test local lại quá khác so với môi trường triển khai thực tế nên càng đau đầu. Dùng Google Cloud Functions như món đồ chơi ở nhà thì ổn, nhưng với dự án thật tôi thà tự chạy HTTP server/queue consumer trên container như ECS còn hơn
  • Ý là kiểu “giả sử tôi tạo một private S3 bucket rỗng ở region yêu thích. Tình cờ một công cụ mã nguồn mở nổi tiếng nào đó có cấu hình mặc định lưu backup lên S3, và nó dùng đúng tên bucket mà tôi tạo làm placeholder”, tôi tò mò chuyện này thực tế xảy ra thường xuyên đến mức nào—tôi không rõ xung đột tên thực sự phổ biến ra sao
  • Mức độ này khiến tôi nghĩ người ta có thể dùng cách đó để triệt hạ đối thủ. Đó cũng là lý do tôi không thích AWS. Họ hoàn toàn không nỗ lực bảo vệ khách hàng nhỏ trước các hóa đơn bất ngờ. Azure cũng không khá hơn bao nhiêu nhưng ít ra còn có một chút biện pháp bảo vệ
  • Tôi cũng đã mong chờ một ví dụ về cloud lock-in, nơi mọi thứ bị trói vào serverless, Lambda, DynamoDB đến mức về bản chất thứ lẽ ra chỉ cần chạy trên VPS 20 đô với sqlite lại bị ép thành một giải pháp đồ sộ, nên hơi thất vọng vì bài không nói về điều đó
• Nỗi đau thật sự của serverless không phải là một lần sự cố dẫn đến hóa đơn khổng lồ, mà là hóa đơn tăng dần từng chút mỗi tháng. Tài nguyên rất dễ tạo ra rồi bị bỏ mặc. Cứ mỗi một hai tháng lại tăng thêm vài nghìn đô, đến khi COO nhận ra thì cả công ty báo động và cắt hóa đơn xuống dưới 10.000 đô. Rồi lại lặp lại. Cộng dồn vài năm còn lãng phí hơn cả mất một cục tiền trong một lần
  • Đó thực ra chính là mô hình kinh doanh của AWS. Có ai từng gọi nó là mô hình “Planet Fitness” chưa? Đăng ký hay tiêu tiền thì cực dễ, còn hủy thanh toán thì cực kỳ phiền phức
  • Có vẻ các tổ chức chẳng học được gì từ những kỳ hóa đơn đắt đỏ như vậy. Tôi tự hỏi nguyên nhân khiến phí cứ tăng mãi là gì và liệu có cách nào ngăn từ trước hay không
  • Chuyện này thật ra cũng hay xảy ra ở on-premise. Sẽ có những máy chủ (thường là VM) vẫn tiếp tục chạy cho các ứng dụng không còn dùng nữa. Tất nhiên chi phí VM cũng không phải bằng 0
• Nhiều khi rất khó xác định trách nhiệm thuộc về ai. Khách hàng muốn những công cụ thần kỳ, không ma sát, có thể triển khai hạ tầng phần cứng chỉ bằng một cú nhấp chuột. Nếu người dùng thiếu kinh nghiệm cấu hình sai rồi phát sinh hóa đơn khổng lồ mà cloud cứ tính nguyên như vậy thì danh tiếng sẽ xấu đi; còn nếu sàng lọc và giới hạn người dùng từ trước thì lại thành cánh cửa đóng kín với các lập trình viên nhỏ đang thử thách startup. Trong những trường hợp như vậy, khi một hóa đơn 10.000 đô bất ngờ xuất hiện, tôi luôn băn khoăn về mặt triết học rằng ai nên trả đến mức nào, và phải chịu trách nhiệm đến đâu cho những chi phí phát sinh do nhầm lẫn. Nếu trong code của tôi, tôi dùng tài nguyên kém hiệu quả gấp 10 lần, thì điều đó có nên mặc nhiên là “cấu hình sai thì tự chịu” hay không; hay việc dịch vụ cloud tôi dùng là AWS và các ông lớn hay một startup API nhỏ hơn cũng là thứ mà từ góc nhìn khách hàng lẽ ra không phải bận tâm
  • Nếu có các hệ thống như vượt ngân sách/circuit breaker (trần chi tiêu) thì sao? Có vẻ không phải vấn đề không thể giải quyết
  • Thực ra đáp án rất đơn giản—đặt giới hạn ngân sách
  • Đó cũng là lý do tôi dùng máy chủ thật, không phải serverless thay vì máy chủ thực tế
• Ở Hetzner, bạn có thể dùng 16TBx2 HDD, 1TBx2 SSD, 64GB RAM, 20TB lưu lượng miễn phí với giá 70 đô/tháng. Trong khi đó trên AWS tôi từng dùng một micro instance với 1TB lưu lượng và phải trả 150 đô (nếu tôi nhớ không nhầm). Hoàn toàn không cần thiết phải như vậy
• Về câu chuyện kiểu "tôi đặt cloudflare trước nội dung của mình, nhưng hacker tìm ra các object không được cache rồi đánh hơn 100 triệu lần. Khi tôi chặn lại, hắn còn tìm trực tiếp ra địa chỉ bucket gốc và tiếp tục tấn công", tôi tự hỏi chẳng phải chuyện này có thể xảy ra với bất kỳ ai sao. Tôi cũng không chắc việc để lộ một object chưa cache có phải là sai lầm nghiêm trọng ngang với việc mở cổng 22 bằng mật khẩu yếu hay không, và tài nguyên S3 (đặc biệt là ảnh) chẳng phải bình thường là để ai cũng có thể truy cập bao nhiêu lần cũng được sao?
  • Hoàn toàn không. S3 bucket bắt buộc phải để private và cấu hình luật bảo mật chỉ cho phép truy cập từ CDN. Như vậy mới buộc mọi truy cập phải đi qua CDN
  • Nghe như đang khoe là bỏ mặc lỗ hổng trong OWASP Top 10 vậy. Thiết lập kiểm soát truy cập không khó như nhiều người nghĩ, nên nếu còn phạm sai lầm cơ bản như thế thì rất có thể những chỗ khác cũng làm ẩu. Tôi không thể tin tưởng hệ thống do người như vậy chịu trách nhiệm
  • Điều cơ bản nhất là để S3 object ở chế độ private và ít nhất đặt cloudfront proxy phía trước. Những thứ như hình ảnh thì bắt buộc phải đi qua cache
• Gọi là serverless nhưng thực tế vẫn là chạy máy chủ trên hạ tầng cloud. Về bản chất bạn vẫn viết phần mềm theo mô hình client-server, và máy chủ vẫn phải chạy ở đâu đó để người dùng sử dụng được. Theo tôi, ‘serverless’ thực sự là khi người dùng tải phần mềm một lần rồi có thể dùng tiếp mà không cần Internet. Hoặc dù có gửi dữ liệu lên máy chủ thì vẫn hoạt động mà không phụ thuộc vào một địa điểm cụ thể do nhà phát triển chỉ định
  • Thuật ngữ ‘serverless’ về bản chất có nghĩa là “hệ thống quản lý tự động tăng giảm tài nguyên (máy chủ) theo tải”, và đó mới là cốt lõi. Tải tăng thì máy chủ tăng, tải giảm thì máy chủ giảm. Serverless chỉ thực sự phát huy giá trị khi bạn có thể thay đổi toàn bộ cấu trúc code để phù hợp hiệu quả với môi trường đó. Nói cách khác, đây là kiến trúc chỉ nên dùng khi thực sự cần
  • Thông thường cái đó được gọi là phần mềm ‘local’. ‘Serverless’ là một cái tên không hay lắm, nhưng thực ra nó nói về cấu trúc triển khai của một backend cụ thể. Không phải là ứng dụng không có backend
  • ‘Serverless’ giống như “công ty không có nhân viên”. Thực tế vẫn có người cung cấp dịch vụ, chỉ là tất cả đều làm theo hợp đồng
  • ‘Server’ thường là một máy đơn có một OS cụ thể cùng nhiều lớp phần mềm chạy bên trên (bao gồm cả công cụ giám sát), cho phép người dùng truy cập business logic. Nếu tự dùng server, bạn phải lo mọi thứ như chọn OS, cài đặt/cập nhật phần mềm hỗ trợ, khôi phục khi có sự cố, v.v. Serverless là mô hình ‘function as a service’, nên bạn chỉ cần quan tâm đến business logic (code của mình). Không cần cài OS lên server, cũng không phải để ý phần mềm nền tảng như HTTP server. Cũng không cần lo cập nhật hay bảo trì. Chỉ việc upload code, và khi được gọi nó sẽ chạy. Đây là khái niệm giải phóng hoàn toàn khỏi stress vận hành máy chủ. Vì thế nó mới được gọi là ‘serverless’—máy chủ vẫn tồn tại, nhưng bạn không cần tự vận hành nó
• Từ “serverless” thực ra không có nghĩa là không có server, mà là bạn không cần tự quản lý server hoặc biết code của mình chạy trên server nào. Cảm giác kiểu “đây là ít code, cứ chạy nó mỗi giờ một lần giúp tôi. Chạy ở đâu tôi không quan tâm”
  • Từ này có thể khiến bạn thấy khó chịu, nhưng xét về ngôn ngữ thì nó không phải vấn đề kiểu Orwellian. ‘Newspeak’ trong 1984 là theo hướng xóa bỏ sự đa dạng biểu đạt, còn ‘serverless’ lại là một từ mới được tạo ra để chỉ một danh mục mới. Dĩ nhiên nó có thể là thuật ngữ làm mờ đi sự tồn tại của server, nhưng gọi nó là Orwellian một cách chính xác thì không hợp. Có lẽ cũng có thể dùng từ như “servelet” để chỉ “máy chủ nhẹ”
  • Người ta cũng hay dùng câu mỉa mai kiểu “không có cloud đâu, chỉ là máy tính của người khác thôi”
  • Cuối cùng ‘serverless’ có cảm giác chỉ là phiên bản tech-bro của ‘shared hosting’ ngày xưa, nhưng được gắn thêm ‘biên lợi nhuận 10.000%’ và ‘tính tiền theo từng request’
  • Hệ thống “no-code” cũng thực ra chạy bằng code. Cáu gắt vì PaaS hay thứ gì đó rốt cuộc vẫn có server thì chỉ là cố tìm cớ mà thôi
• Tôi đã dùng AWS serverless, gần như không thể test local, và để chạy serverless run thì bắt buộc phải dùng AWS IAM role, khiến tài khoản bị mở quyền rộng khắp. Cuối cùng dẫn tới một vấn đề rất lớn là trên thực tế không khác gì lúc nào cũng test trực tiếp trên production
  • Tôi cũng đã làm dự án serverless nhiều năm, và việc gần như chẳng chạy thử được gì ở local thực sự là chi phí rất lớn. Thời gian debug cũng kéo dài thảm hại. Những công cụ được đưa ra để thay thế thì trong dự án thực tế gần như vô dụng
  • Nếu cấu hình đúng file ~/.aws/credentials thì bạn có thể test local bằng AWS security key. Có thể tự động hóa việc deploy Lambda bằng makefile, và tạo custom IAM role cho từng Lambda để quản lý yêu cầu bảo mật trong file JSON. Điểm mạnh thực sự của AWS là mọi thứ đều có thể xử lý bằng cùng một API. Bạn có thể tạo và quản lý mọi thứ bằng code
  • 1. Gói trong stack rồi deploy sang tài khoản riêng cho dev (môi trường staging miễn phí) 2) test local bằng Docker runtime chính thức được hỗ trợ 3) viết unit test như bình thường 4) dùng công cụ như localstack để giả lập nguyên môi trường staging trên máy—có rất nhiều lựa chọn như vậy nên tôi không hiểu tại sao lại có thể có trải nghiệm tệ đến thế
  • Đây là nhận định khá xa sự thật
• Tôi nghĩ cái tên ‘serverless’ dù sao cũng là một kiểu đặt tên mang màu sắc Orwellian, tô vẽ cho một hệ thống vốn vẫn dựa trên server
• Tôi không thể tin nổi các công ty này lại thu tới 550 đô cho 1TB băng thông. Ngay cả khi thuê server với cổng đảm bảo 10Gb/s, nếu tính quá 3 đô/TB thì tôi đã xem là lừa đảo. Tôi không hiểu serverless làm sao có thể biện minh mức chi phí cao hơn 150 lần như vậy. Không biết có nhiều người thật sự chấp nhận mức giá này không. Chỉ cần đưa lên VPS 10 đô hoặc GitHub Pages là các thứ như wiki đọc sách/tài liệu kỹ thuật/blog đã chạy hoàn toàn ổn, và nếu setup hợp lý thì 10.000 kết nối đồng thời cũng chẳng thành vấn đề

[benjamin]

Có phải giờ đây, khi những người mới bắt đầu bước vào phát triển tạo ra thứ gì đó bằng AI, phần lớn đều triển khai dịch vụ bằng những thứ như Vercel hay Supabase?

Nhưng có vẻ họ không tính toán kỹ cái giá phải trả cho những bên này khi dịch vụ bắt đầu phát triển lớn hơn.
Với tâm thế là cứ để đến lúc đó rồi tính.

Tôi có cảm giác nhà sáng lập của Vercel hay Supabase sẽ cười tươi và hùa theo kiểu: “Đúng đúng, đến lúc đó tính cũng được mà!”

Tất nhiên, đến lúc đó mới tính cũng được. Miễn là bạn có đủ năng lực để thoát ra thật nhanh.
Nhưng nếu không có kiến thức về khoa học máy tính thì sẽ không dễ đâu.
Bạn có thể rơi vào cảnh đem hết số tiền vừa mới bắt đầu kiếm được dâng cho họ.

Thật ra đó chính là điều đang diễn ra lúc này.
Nói cách khác… một ngành kinh doanh khổng lồ đang mở ra, chuyên lấy tiền của những người mới vào nghề lao vào mà chẳng biết gì về khoa học máy tính.

Đây chính là lý do bạn phải tiếp tục đào sâu vào khoa học máy tính.
Có người dùng một dịch vụ mới chỉ bắt đầu có doanh thu mà phải trả 1 triệu won mỗi tháng, trong khi có người vận hành dịch vụ mà không tốn đồng nào.
Cắt giảm chi phí vận hành cũng là năng lực. Chẳng phải đó là một lợi thế cạnh tranh cực lớn sao?
Việc code bằng AI, thử tạo ra thứ gì đó và cảm thấy vui thì rất tốt, nhưng nếu không cố gắng đi sâu hơn, cuối cùng bạn sẽ không thể tạo ra khác biệt.

https://jeho.page/essay/2025/09/08/sucker-developer.html