Tôi quay lại AWS và lại nhận ra vì sao mình đã rời đi
(fourlightyears.blogspot.com)- Từng ủng hộ AWS từ rất sớm, nhưng vì những bất mãn tích tụ như *cơ chế tính phí phức tạp và sự phức tạp trên toàn bộ nền tảng, tác giả không còn yêu thích AWS nữa
- Chi phí cao của DynamoDB, phí egress lên tới 9 cent mỗi gigabyte, cùng việc bị tính phí hai lần, ba lần cho di chuyển dữ liệu nội bộ vẫn bị xem là đắt đỏ và khó hiểu
- Tác giả quay lại để thử Claude trên AWS Bedrock và benchmark máy 192 lõi, nhưng hoạt động đột ngột trên một tài khoản gần như ngủ đông đã kích hoạt cảnh báo nghi ngờ xâm phạm bảo mật và khiến tài khoản bị đình chỉ
- Việc đình chỉ tài khoản còn khiến cả AWS WorkMail dùng cho công việc bị ngừng hoạt động, và với gói hỗ trợ miễn phí, việc khôi phục tài khoản vẫn chưa diễn ra sau 4 ngày
- Tác giả đi đến kết luận rằng phải chuyển nốt mọi dịch vụ còn lại trên AWS và rời đi hoàn toàn
Từ người ủng hộ AWS ban đầu đến lúc rời bỏ
- Tác giả đã ủng hộ AWS rất mạnh từ thời dịch vụ này còn nhỏ, chủ yếu xoay quanh SQS, S3, EC2 và SimpleDB, thậm chí còn tổ chức sự kiện đầu tiên tại Melbourne khi đại diện AWS từ Mỹ sang giới thiệu AWS
- Điện toán đám mây là một thay đổi lớn, cho phép startup vận hành hệ thống máy tính riêng chỉ trong vài phút mà không cần tự cài đặt và vận hành hệ thống trong trung tâm dữ liệu
- Trong khoảng 15 năm, tác giả tin tưởng AWS rất nhiều, nhưng theo thời gian những điểm khó chịu dần tích tụ, và đến một lúc nào đó tác giả không còn thích AWS nữa
Những bất mãn với AWS tích tụ theo thời gian
-
Thư viện client và quá trình chuyển sang Python
- Trong 6 năm đầu, AWS không tự xây dựng thư viện client của riêng mình mà để cộng đồng tự triển khai thư viện cho các ngôn ngữ như Python, điều này bị xem như đẩy gánh nặng sang các lập trình viên làm việc miễn phí
- Việc AWS mất quá nhiều thời gian để chuyển từ Python 2 sang Python 3 cũng là một điểm bất mãn lớn
-
DynamoDB và trải nghiệm chi phí
- Ngay ngày đầu dùng DynamoDB, tác giả đã bị tính 75 USD, và không chỉ chi phí mà cả hệ thống này cũng bị cảm nhận là tệ theo cách tồi nhất có thể tưởng tượng
-
Chi phí truyền dữ liệu và cơ chế tính phí phức tạp
- Trước đây chi phí truyền dữ liệu ra ngoài của AWS là 20 cent mỗi GB, sau đó giảm xuống 9 cent mỗi GB, nhưng theo tác giả thì vẫn cực kỳ đắt
- Ngay cả việc di chuyển dữ liệu giữa các hệ thống nội bộ của AWS cũng bị tính phí, và trong một số trường hợp cấu trúc đó tạo cảm giác bị tính phí hai lần, ba lần, khiến rất khó tránh bẫy tính phí nếu không hiểu thật sâu
-
IAM và sự phức tạp tổng thể
- IAM (hệ thống xác thực và kiểm soát truy cập) là một hệ thống cực kỳ phức tạp
- Những người ủng hộ AWS thường nói rằng việc tự vận hành Linux, phần cứng, mạng và bảo mật là quá phức tạp nên phải dùng AWS, nhưng theo tác giả thì gần như mọi phần của chính AWS cũng mang mức độ phức tạp khổng lồ, và cuối cùng vẫn cần một đội ngũ chuyên gia đắt đỏ
-
AWS Lambda và lock-in
- Tác giả từng bị hấp dẫn bởi ưu điểm “có thể mở rộng”, nhưng cold start chậm và độ phức tạp phát triển rất lớn lại là vấn đề
- So với web server tự vận hành, gần như không có lợi ích thực chất mà còn nhiều nhược điểm hơn, và khi rời AWS thì Lambda là phần khó tháo gỡ nhất, cho thấy mức độ vendor lock-in rất nghiêm trọng
-
Dự án mã nguồn mở và doanh thu từ hosting
- Theo tác giả, AWS đã thúc đẩy OpenSearch, Valkey và DocumentDB dù các dự án như Elasticsearch, Redis và MongoDB từng bày tỏ rằng họ không muốn bị sao chép và kiếm tiền theo cách đó
- Sau khi các cộng đồng và công ty đó tạo ra thị trường, AWS lại lấy phần doanh thu từ dịch vụ hosting, và kết quả là các giấy phép phòng thủ như SSPL, Elastic License, RSAL cùng mô hình source-available ngày càng tăng
Một số dịch vụ còn để lại sau khi rời AWS
- Sau khi không còn gắn bó với AWS, tác giả đã chuyển mọi thứ ra khỏi AWS và đóng gần hết tài khoản
- Tuy vậy, vẫn để lại một vài dịch vụ mà vào thời điểm đó được xem là giải pháp thực sự phù hợp
- Domain để ở Route53, một số bản sao lưu để ở S3, và email công việc để ở AWS WorkMail
- AWS WorkMail hiện đã nhận thông báo sẽ ngừng dịch vụ trong vòng 12 tháng
Lý do tạm thời quay lại AWS
- Gần đây tác giả đăng nhập lại AWS để phục vụ nghiên cứu và thử nghiệm
- Tác giả muốn kiểm tra xem Claude/Anthropic hoạt động tốt đến mức nào trên AWS Bedrock; xét theo tiêu chuẩn của Claude Code thì hoạt động tương tự, nhưng chậm hơn và đắt hơn rất nhiều so với gói thuê bao Anthropic
- Thiết bị gia đình nhanh nhất mà tác giả có chỉ là CPU 20 lõi và RAM 32GB, nên tác giả muốn benchmark xem code chạy nhanh đến đâu trên máy 192 lõi và 1TB RAM
- Khoảng một tháng trước, việc thử AWS Bedrock đã kết thúc suôn sẻ, và sau khi thử xong tác giả tắt toàn bộ
- AWS Bedrock có thể hữu ích nếu cần quyền riêng tư, nhưng vì chi phí nên tác giả sẽ không dùng Claude trên AWS Bedrock nữa
Hạn chế tài khoản xảy ra khi thử EC2 Spot
- Sau đó, trong lúc chạy một EC2 Spot instance 192 lõi để thử nghiệm khoảng 3 giờ, tác giả nhận được email từ AWS với nội dung “Suspected security breach of your account”
- Tác giả cho rằng việc một tài khoản gần như ngủ đông đột ngột bắt đầu dùng tài nguyên tính toán đắt đỏ có thể đã kích hoạt cảnh báo bảo mật nội bộ của AWS
- Tác giả hiểu và đánh giá tích cực mục đích bảo vệ người dùng của AWS
- Tuy nhiên, AWS đã đình chỉ hoặc hạn chế tài khoản, và kết quả là tài khoản email công việc chính dùng AWS WorkMail không còn hoạt động
- Không ai có thể gửi email cho tác giả nữa, và cũng không thể tạo bất kỳ tài nguyên AWS nào, khiến bài thử nghiệm ban đầu cũng không thể tiếp tục
Cách hỗ trợ phản hồi và sự chậm trễ
- Tác giả đã trả lời thông báo hỗ trợ của AWS để nói rằng tài khoản không bị hack, không có vấn đề hay bất thường về tính phí, nhưng không nhận được phản hồi
- Vì không dùng gói hỗ trợ cao cấp, tác giả phải chờ thời gian phản hồi 24 giờ như AWS thông báo, nhưng sau 3 ngày vẫn không có trả lời từ bộ phận hỗ trợ
- Sau khi lên diễn đàn AWS nhờ giúp đỡ, tác giả được khuyên làm theo hướng dẫn trong email và dùng chat thay vì web
- Tác giả đã thực hiện đầy đủ các bước được yêu cầu như đổi mật khẩu, xóa access token, kiểm tra lịch sử thanh toán, rồi chờ khoảng 30 phút để kết nối chat và trò chuyện khá lâu với nhân viên AWS
- Nhân viên có vẻ đã hài lòng và nói sẽ chuyển xử lý cho đội nội bộ liên quan, nhưng sau 24 giờ nữa hạn chế vẫn không được gỡ
- Khi tác giả hỏi tiếp sau 8 giờ, câu trả lời duy nhất nhận được là “hãy chờ thêm”
Kết luận một lần nữa được xác nhận
- Đến thời điểm tài khoản bị hạn chế đã 4 ngày, tác giả vẫn còn những việc muốn thử trên máy lớn, và bắt đầu lo rằng để làm điều đó sẽ lại phải gửi yêu cầu “quota” một lần nữa
- Hệ thống email công việc vẫn chưa hoạt động trở lại
- Trải nghiệm quay lại lần này đã một lần nữa xác nhận lý do tác giả rời AWS, và tác giả cho rằng cần thoát khỏi AWS WorkMail, chuyển cả domain khỏi Route53 và không bao giờ quay lại nữa
- Tác giả thấy rất may vì trước đây đã đưa phần lớn mọi thứ ra khỏi AWS, nhưng hệ thống email được tin tưởng để lại thì lại bị gián đoạn trong quá trình quay lại AWS, dẫn tới thiệt hại thực tế
- AWS có thể rồi sẽ gỡ hạn chế tài khoản, nhưng không ai biết là vào lúc nào
1 bình luận
Ý kiến trên Hacker News
Vài năm trước tôi gia nhập một công ty, phụ trách đội phát triển và được yêu cầu ra mắt sản phẩm trong vòng 3 tháng. Khi định thêm máy mới trên AWS, tôi thấy ngay việc giá không hiển thị trong UI là dấu hiệu của một mối quan hệ vốn đã mang tính đối kháng và bóc lột.
Tôi phải mở riêng bảng thông số và bảng giá để đối chiếu, và theo kinh nghiệm trước đây, nếu nhìn thấy kiểu tín hiệu này mà vẫn không rời đi thì hậu quả về sau là lỗi của chính mình.
Vì vậy tôi tạo tài khoản DigitalOcean, chuyển toàn bộ sang đó rồi cấu hình CI/CD triển khai về bên ấy, và dành 2 tháng còn lại tập trung vào sản phẩm để ra mắt sớm hơn cam kết 1 tháng.
Trước đây tôi từng xem một video đào hố bên bờ sông rồi nối hố với con sông bằng ống để cá tự bơi vào bẫy; từ đó tôi luôn ấn tượng mạnh rằng chọn con đường ít cản trở nhất và không sửa lại sai lầm chính là bí quyết để kết cục giống như con cá kia.
Tôi vẫn chưa từng bị bất ngờ vì hóa đơn.
Trước đây tôi từng tuyển một dev junior vừa thực tập ở AWS xong, và cậu ấy cho xem dashboard tự làm một mình trong mùa hè mà không có PM hay designer hỗ trợ; trông thật sự khủng khiếp.
Một số dev có cảm quan sản phẩm/UX tốt, nhưng đa số rất yếu về UX, nên có lẽ đây không hẳn là cố ý mà chỉ là văn hóa UX tệ.
AWS tốt, nhưng không phải hợp với tất cả mọi người; đâu đó giữa các dịch vụ như Heroku và bare metal là mức trừu tượng hóa kha khá phần bảo trì nhưng vẫn cho bạn một phần quyền kiểm soát kiến trúc mở rộng.
Nói cách khác, với tư cách nhà cung cấp cloud thì AWS giúp mở rộng tốt, nhưng không phải công cụ để tạo ra cấu hình rẻ nhất và đơn giản nhất.
Nếu có vốn VC và ưu tiên tăng trưởng, AWS có thể là lựa chọn an toàn, và nhờ startup credit 2 năm từ các accelerator, 18 tháng đầu có thể tập trung xây dựng hơn là lo ngân sách hạ tầng.
Nếu là bootstrap hoặc indie developer thì cứ chọn thứ đơn giản, chịu nổi chi phí; Hetzner hay DigitalOcean là đủ chạy rất ổn.
Có thể Amazon muốn tạo một chút ma sát để việc xem giá không quá dễ dàng, nhưng lý do chính có vẻ giống định luật Conway hơn.
AWS đến giờ vẫn đang xuất bản sơ đồ tổ chức của chính họ thành sản phẩm.
Nếu việc phải mở hai tab để đối chiếu chi phí đã là bất tiện thì có lẽ nên tránh không chỉ AWS mà cả mọi nhà cung cấp cloud khác.
Khi có NAT gateway, CloudFront, S3, auto scaling, load balancer thì tính chi phí gần với nghệ thuật hơn là khoa học chính xác.
Nếu bạn không dùng những thứ đó thì cũng chẳng có nhiều lý do để dùng AWS, vì có rất nhiều nhà cung cấp VPS rẻ hơn.
Nếu chỉ xét OpenSearch và Valkey thì cách nói “AWS tạo fork nên mới dẫn tới đổi license” là hoàn toàn ngược lại.
AWS chỉ tạo fork sau khi dự án upstream đã đổi license, và riêng Valkey thì là do các thành viên cốt lõi trước đây của đội Redis tạo ra.
AWS cung cấp managed service để lách qua họ, nên trong vụ này tôi đứng về phía những người đã tạo ra dự án.
Về cơ bản là AWS đã lấy miếng cơm của họ, nên họ buộc phải đổi license.
Cũng tò mò không biết số đó có thành khoản tiền đáng kể nào cho các đội open source hay không, và có lẽ còn khiến họ đóng góp cải tiến sản phẩm mà không phải gánh quá nhiều rủi ro.
Họ xứng đáng gặp Valkey.
Tôi vẫn còn nhớ cả JBoss và Marc Fleury.
Đó chính là cốt lõi vấn đề.
Tôi đã qua lại vài lần giữa cloud service và tự host.
Ban đầu tôi dùng Vercel, và vì dự án là Next.js nên trải nghiệm khá ổn, nhưng phải trả 20 USD/tháng cho một dự án còn chưa tới 100 người dùng khiến tôi thấy đắt so với nhu cầu hiệu năng thấp.
Sau đó tôi tự dựng server bằng Hetzner và Coolify; vì Coolify là open source nên tôi chỉ phải trả chi phí VPS, và với 5 USD/tháng đã có thể chạy một instance PostgreSQL cùng web server.
Nhưng việc bảo trì PostgreSQL và Redis vẫn rất tốn công, và kể cả khi ở trong Docker container thì việc truyền biến hệ thống và biến môi trường giữa các service vẫn rất phiền.
Vì thế về sau tôi chuyển sang Cloudflare Workers, D1 Database, Cloudflare KV, có thể gọi trực tiếp trong Worker nên không cần truyền biến môi trường nữa.
Trải nghiệm dev local cũng tốt, giá cả hợp lý nên từ đó tôi tiếp tục dùng cả hệ sinh thái Cloudflare.
Triển khai ứng dụng full-stack và file cơ bản đơn giản hơn nhiều, còn AWS thì giờ thậm chí còn khó hơn cả tự host.
Vấn đề duy nhất tôi từng gặp với PostgreSQL chỉ là đôi chút công việc migration khi lên major version mới.
Cũng tò mò liệu chính Docker có làm việc truyền biến hệ thống và biến môi trường giữa các service khó hơn không.
Muốn bật email thì phải cấu hình binding cần thiết, nhưng trên console dường như không cấu hình được, mà sau khi Wrangler thiết lập xong thì cũng có vẻ không xem lại được.
Tôi ngạc nhiên khi tác giả ghét DynamoDB.
Đây là một trong những dịch vụ AWS tôi thích nhất: tính sẵn sàng cao, không có gánh nặng vận hành, và mỗi lần dùng thì chi phí cũng khá thấp.
Chỉ có điều bạn phải bỏ thời gian thiết kế data model từ trước, và để làm được thì phải đọc và hiểu tài liệu của dịch vụ.
Về cơ bản nên xem nó là một key-value store tương đối đơn giản với độ bền dữ liệu tốt và khả năng mở rộng kích thước bảng gần như vô hạn, chứ đừng cố dùng nó như cơ sở dữ liệu SQL.
Cách dễ nhất để tạo ra hóa đơn 75 USD từ code prototype là vibe coding nó như một cơ sở dữ liệu SQL có JOIN và GROUP BY.
Nó thật sự tỏa sáng khi bạn cần 1-2 bảng nhỏ để lưu trữ lâu dài nhưng không muốn quản cả một RDBMS, hoặc khi bạn có một bảng rất lớn cần truy vấn theo cách đơn giản mà không muốn ép cho vừa với RDBMS.
Đừng dùng một key-value store vui vẻ làm database.
Chi phí nạp dữ liệu ban đầu khoảng 50 USD, và sau đó chi phí duy trì chỉ cỡ 10 cent mỗi tháng.
Đọc mấy bài kiểu này lúc nào tôi cũng buồn cười.
Nó vừa đúng vừa sai, và hệ thống nên được làm “đơn giản nhất có thể, nhưng không đơn giản hơn thế”.
Nếu bạn nghĩ có thể lướt qua chi tiết thì về sau sẽ phải trả giá bằng nhiều rắc rối hơn.
IAM đơn giản là phức tạp.
Tôi không nghĩ ra ví dụ nào mà user, group, role, policy, identity provider, OIDC lại có thể được hiện thực một cách thật sự đơn giản.
Tôi từng thấy một người phản đối triển khai Kubernetes vì “quá phức tạp”, rồi cuối cùng lại tái tạo Kubernetes theo kiểu thô sơ và chắp vá bằng Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash cùng nước bọt và băng dính, đồng thời mắc rất nhiều sai lầm.
Có những tính năng bạn nghĩ mình không cần, nhưng rồi cuối cùng vẫn cần.
Với tư cách người từng làm hạ tầng một mình ở startup, tôi thấy AWS phần lớn vẫn nằm trong phạm vi có thể học được, và những phần dở thì thường có thể né.
Nếu ghét Lambda thì đừng dùng nó; dùng EKS, ECS, EC2 là được.
Nhìn từ độ cao 10.000 feet thì chỉ có vậy thôi.
IAM tốt vì nó áp dụng như nhau cho cả bên ngoài lẫn bên trong.
Đội nội bộ AWS không có nhiều quyền truy cập hơn chỉ vì họ là nội bộ; nếu họ có quyền làm gì đó trong tài khoản của khách hàng để vận hành một dịch vụ cụ thể, thì là vì khách hàng đã cho phép bằng cách thêm service principal vào quan hệ trust của IAM, và khách hàng có thể xem cũng như audit điều đó.
Ví dụ, Lambda có Lambda role, bởi vì bạn sẽ không muốn dịch vụ Lambda đọc S3 bucket chỉ vì “chúng tôi là AWS nên tự động có quyền”.
Ngay cả quyền truy cập nội bộ của AWS thì khách hàng vẫn có thể nhìn thấy và kiểm soát rõ ràng.
Có những thứ giờ đã rõ ràng là tiêu chuẩn, vậy mà nhiều người vẫn từ chối bỏ thời gian để học cho đúng.
Nếu một infra engineer khá phải dành 2 tháng cho một cấu hình OVH nhằm “tiết kiệm tiền”, thì số đó còn đắt hơn khoản bạn có thể tiết kiệm được nhờ không dùng Fargate hay RDS.
Tôi tự hỏi đến khi nào người ta cũng sẽ bắt đầu nói điều tương tự về Anthropic hay OpenAI.
Làn sóng AI hiện tại có mùi khá giống thời đầu AWS, và có lẽ ai cũng sẽ nhảy lên rồi sau này mới nhận ra mình đã tích lũy một phụ thuộc khổng lồ rất khó gỡ bỏ.
Lambda thật sự rất tuyệt, và theo tôi đây là cách tốt nhất để vận hành dịch vụ triển khai với chu kỳ lặp nhanh mà không phải đau đầu.
Bạn không nhất thiết phải chuyển hẳn sang microservices hay chẻ code thành hàng tỷ repository tí hon.
Nếu bạn không trông đợi chia sẻ trạng thái trong server giữa các request, thì có thể chuyển một web server tiêu chuẩn sang Lambda.
Tôi không làm việc trong lĩnh vực đó nên AWS chỉ thỉnh thoảng được đụng tới cho mấy dự án vui cá nhân, và lần nào cũng như ác mộng.
Tôi chỉ muốn dựng một game server thẻ bài thử nghiệm chứ không phải thành lập một định chế tài chính mới, nhưng mọi thứ trông như thể đều được chuẩn bị để ngày mai mở rộng vô hạn và mặc định tổ chức 1.000 người cùng ngân sách VC.
May mà có mấy dịch vụ như Netlify phủ lớp ngoài để không phải đun sôi cả đại dương.
Có thể đến một lúc nào đó tôi sẽ phải học thật về IAM, VPN và những thứ trời biết gì nữa, nhưng tới lúc đó thì mỗi lần chạm vào AWS tôi vẫn thấy như muốn lồi cả mắt.
Không phải lúc nào cũng cần triển khai mọi pattern enterprise.
Có đủ mọi thứ tôi cần và giá cả hợp lý.
Dự án cá nhân rốt cuộc chỉ quan tâm đến chi phí nên không mang lại doanh thu đủ ý nghĩa cho AWS.
Từ sau năm 2023, nhân lực kỹ thuật ở AWS đang bị rút cạn một cách có hệ thống.
Điều đó diễn ra qua các đợt sa thải lớn hoặc hai vòng PIP, và nhiều đồng nghiệp giỏi ở mảng presales hay support đã không còn ở AWS nữa.
Ngược lại, tôi thường thấy những người có thành tích công việc mơ hồ nhất lại ở lại và được thăng tiến.
AWS là thứ ai dùng thì tự chịu rủi ro, và Paul Vixie sẽ không đến cứu đâu.
Từ rất lâu rồi tôi đặc biệt khó chịu với ElastiCache.
RDS còn mang lại giá trị như khả năng mở rộng, cấu hình tối ưu ở mức vừa phải và backup khỏi phải bận tâm, nên tôi còn có thể cắn răng trả tiền.
Nhưng ElastiCache thì gần như không có mấy giá trị gia tăng mà giá lại mang cảm giác bóc lột.
Nó chậm hơn, kém tối ưu hơn, kém ổn định hơn so với cài Redis cơ bản, và Redis mặc định không cấu hình gì còn hỗ trợ nhiều DB trong khi ElastiCache chỉ hỗ trợ một.
Nó có cải thiện đôi chút về khả năng mở rộng, nhưng Redis cơ bản trên các instance tương đương vốn đã vượt ElastiCache quá xa nên những cải thiện đó hiếm khi thực sự cần thiết.
AWS không bổ sung thêm quá nhiều về API hay mức độ hoàn thiện, trong khi Redis/Valkey lại là một trong những dịch vụ đơn giản nhất để tự host.