Tôi quay lại AWS và lại nhớ ra vì sao mình đã rời đi

 (fourlightyears.blogspot.com)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Dù từng ủng hộ AWS từ rất sớm, nhưng sau một thời gian để thư viện client cho cộng đồng tự lo, chậm chuyển sang Python 3, cách tính phí và IAM phức tạp, cùng với tình trạng bị khóa chặt bởi AWS Lambda, dần dần tích tụ khiến tôi không còn thích AWS nữa
  • Sau khi dùng DynamoDB, tôi từng bị tính phí 75 đô la chỉ trong một ngày; chi phí truyền dữ liệu đã giảm từ 20 cent xuống 9 cent mỗi GB, nhưng việc ngay cả luồng dữ liệu nội bộ cũng bị tính phí vẫn khiến cấu trúc này vừa đắt vừa khó hiểu
  • Sau khi rời AWS, tôi đã đóng hầu hết tài khoản nhưng vẫn giữ lại domain trên Route53, một phần bản sao lưu trên S3 và AWS WorkMail; sau đó tôi nhận được thông báo rằng WorkMail sẽ bị ngừng trong vòng 12 tháng
  • Gần đây tôi đăng nhập lại AWS để kiểm tra cách Claude/Anthropic chạy trên AWS Bedrock và thử EC2 Spot 192 lõi, 1TB RAM; tôi thấy Bedrock hoạt động tương tự nhưng chậm hơn và đắt hơn rất nhiều so với đăng ký Anthropic
  • Trong lúc thử EC2 Spot khoảng 3 giờ, sau cảnh báo Suspected security breach, tài khoản của tôi bị hạn chế, khiến email công việc trên WorkMail và việc tạo tài nguyên đều bị chặn; ngay cả sau khi làm theo hướng dẫn và dùng hỗ trợ chat, 4 ngày sau hạn chế vẫn chưa được gỡ, nên tôi quyết định chuyển cả AWS WorkMail lẫn Route53 đi nơi khác

Từ người ủng hộ AWS ban đầu đến lúc rời bỏ

  • Tôi đã ủng hộ AWS rất mạnh từ thời họ mới chỉ là một tập hợp dịch vụ nhỏ xoay quanh SQS, S3, EC2 và SimpleDB, thậm chí còn tổ chức sự kiện đầu tiên tại Melbourne nơi đại diện AWS từ Mỹ sang giới thiệu về AWS
  • Điện toán đám mây là một thay đổi lớn vì nó cho phép startup vận hành hệ thống máy tính của riêng mình chỉ trong vài phút mà không cần tự lắp đặt và vận hành hệ thống trong trung tâm dữ liệu
  • Tôi đã tin tưởng AWS rất nhiều trong khoảng 15 năm, nhưng theo thời gian những điều bất tiện cứ tích tụ lại, đến một lúc nào đó tôi 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à việc chuyển đổi Python

    • Trong 6 năm đầu, AWS không tự xây 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ị cảm nhận như việc đẩy gánh nặng sang các lập trình viên phải bỏ thời gian miễn phí
    • Việc AWS mất quá lâu để chuyển từ Python 2 sang Python 3 cũng để lại sự khó chịu rất lớn

  • DynamoDB và trải nghiệm chi phí

    • Sau khi dùng DynamoDB, đến cuối ngày tôi nhận hóa đơn 75 đô la, và không chỉ chi phí mà chính hệ thống đó cũng cho tôi cảm giác là cách tệ nhất có thể tưởng tượng ra

  • 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 còn 9 cent mỗi GB, nhưng tôi vẫn cho là rất đắt
    • Ngay cả việc di chuyển dữ liệu giữa các hệ thống nội bộ trong AWS cũng bị tính phí, và trong một số trường hợp cấu trúc này tạo cảm giác như bị tính phí hai lần, ba lần; nếu không hiểu rất sâu thì rất khó tránh bẫy tính phí

  • IAM và độ phức tạp nói chung

    • IAM là hệ thống xử lý xác thực và quy tắc truy cập, nhưng bị cảm nhận là có cấu trúc quá phức tạp
    • Những người ủng hộ AWS thường nói rằng 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ôi gần như mọi phần của chính AWS cũng mang độ phức tạp khổng lồ, nên rốt cuộc vẫn cần một đội ngũ chuyên gia đắt đỏ

  • AWS Lambda và tình trạng khóa chặt

    • AWS Lambda quảng bá khả năng mở rộng, nhưng phải đánh đổi bằng thời gian khởi động chậm và độ phức tạp phát triển cao
    • Tôi không thấy nó có lợi ích thực sự nào so với việc tự vận hành web server, trong khi nhược điểm thì rất nhiều; và khi rời AWS, phần khó đảo ngược nhất chính là AWS Lambda
    • Việc dùng AWS Lambda khiến tôi trải nghiệm rõ rằng vendor lock-in là có thật, và nó giống một lựa chọn mà bạn phải liên tục tự thuyết phục bản thân rằng nó tốt hơn

  • Dự án mã nguồn mở và doanh thu lưu trữ

    • Tôi cho rằng AWS đã thúc đẩy OpenSearch, Valkey và DocumentDB dù các dự án như Elasticsearch, Redis và MongoDB 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 dựng 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 tăng lên

Một số dịch vụ vẫn giữ lại sau khi rời AWS

  • Sau khi không còn thiện cảm với AWS, tôi chuyển mọi thứ ra khỏi AWS và đóng gần hết tài khoản
  • Tuy vậy, lúc đó tôi vẫn giữ lại một số dịch vụ mà tôi cho là thực sự phù hợp
  • Những thứ giữ lại là domain trên Route53, một phần backup trên S3 và AWS WorkMail
  • Sau đó tôi nhận được thông báo rằng AWS WorkMail sẽ bị ngừng trong vòng 12 tháng

Lý do tôi tạm quay lại AWS

  • Gần đây tôi đăng nhập lại AWS để phục vụ nghiên cứu và thử nghiệm
  • Tôi muốn kiểm tra Claude/Anthropic chạy tốt đến mức nào trên AWS Bedrock, và theo tiêu chuẩn Claude Code thì nó hoạt động giống nhau nhưng chậm hơn và đắt hơn rất nhiều so với gói đăng ký Anthropic
  • Thiết bị mạnh nhất ở nhà tôi chỉ có CPU 20 lõi và 32GB RAM, nên tôi muốn benchmark xem mã của mình chạy nhanh đến mức nào trên máy 192 lõi với 1TB RAM
  • Khoảng một tháng trước, bài thử AWS Bedrock đã hoàn tất mà không có vấn đề gì, và sau khi thử xong tôi đã tắt hết mọi thứ
  • AWS Bedrock có thể hữu ích nếu cần quyền riêng tư, nhưng vì chi phí quá cao nên tôi nghĩ mình sẽ không dùng Claude trên AWS Bedrock nữa

Tài khoản bị hạn chế trong lúc thử EC2 Spot

  • Sau đó tôi khởi chạy một EC2 Spot instance 192 lõi và đang thử trong khoảng 3 giờ thì nhận được email từ AWS với nội dung “Suspected security breach of your account”
  • Tôi cho rằng có thể hệ thống cảnh báo bảo mật nội bộ của AWS đã bị kích hoạt vì một tài khoản gần như ngủ yên bỗng nhiên bắt đầu dùng tài nguyên tính toán đắt đỏ
  • Tôi hiểu mục tiêu bảo vệ người dùng của AWS và đánh giá điều đó là tích cực
  • Nhưng AWS đã tạm dừng 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 tôi dùng trên AWS WorkMail không còn hoạt động
  • Không ai có thể gửi email cho tôi nữa, và tôi cũng không thể tạo bất kỳ tài nguyên AWS nào, nên không thể tiếp tục bài thử ban đầu

Cách hỗ trợ phản hồi và sự chậm trễ

  • Tôi đã trả lời thông báo hỗ trợ của AWS để nói rằng tài khoản không bị hack và cũng 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 nào
  • Vì tôi không dùng gói hỗ trợ cao cấp nên phải chờ thời gian phản hồi 24 giờ mà AWS nói tới, nhưng sau 3 ngày vẫn không có phản hồi từ bộ phận hỗ trợ
  • Sau khi cầu cứu trên diễn đàn AWS, tôi được khuyên làm theo chỉ dẫn trong email và dùng chat thay vì web
  • Tôi đã 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à trao đổi khá lâu với nhân viên AWS
  • Nhân viên đó có vẻ đã hài lòng và nói sẽ nhờ đội nội bộ liên quan xử lý, nhưng sau 24 giờ nữa hạn chế vẫn không được gỡ
  • Khi tôi hỏi lại sau 8 giờ, tôi chỉ nhận được câu trả lời là “hãy chờ thêm”

Kết luận được xác nhận lại

  • Đến thời điểm tài khoản bị hạn chế đã 4 ngày, tôi vẫn còn những công việc muốn thử trên máy lớn, và lại phải lo việc sẽ còn phải gửi yêu cầu “quota” để làm điều đó
  • 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 khiến tôi xác nhận lại lý do mình đã rời AWS, và tôi quyết định phải rời AWS WorkMail, chuyển luôn các domain trên Route53 và không quay lại nữa
  • Việc trước đây đã kịp đưa phần lớn thứ ra khỏi AWS là điều rất may mắn, nhưng việc hệ thống email mà tôi tin tưởng giữ lại lại bị gián đoạn trong quá trình quay lại AWS thì với tôi là một thất bại
  • Có thể một lúc nào đó AWS sẽ gỡ hạn chế tài khoản, nhưng tôi không biết là khi nào

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý 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.

    • Một điểm tôi thích ở Azure là mỗi khi tạo từng mục riêng lẻ, họ không cố nhồi giá vào mặt bạn quá mức, nhưng với các hạng mục có thể tốn kém thì nhìn chung vẫn có sự cân bằng ở chỗ hiển thị giá.
      Tôi vẫn chưa từng bị bất ngờ vì hóa đơn.
    • Tôi đoán văn hóa kỹ thuật của Amazon là kiểu văn hóa sản phẩm do kỹ sư dẫn dắt, nên nhiều khi lập trình viên còn phải chịu trách nhiệm cả UX và luồng sử dụng.
      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ệ.
    • Cách đúng đắn là chọn nhà cung cấp hạ tầng giúp bạn ra mắ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.
    • AWS có một công cụ tính giá khá ổn cùng vài preset dùng được, nhưng tất nhiên nó là một ứng dụng hoàn toàn tách biệt.
      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.
    • Tôi đồng ý phần nào, nhưng giá của AWS không đơn giản đến mức chỉ cần một con số tĩnh hiện trong UI là tính ra bạn phải trả bao nhiêu.
      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.

    • Khá nhiều dự án kiểu này vận hành theo mô hình công bố sản phẩm lõi dưới dạng open source rồi kiếm tiền bằng dịch vụ cao cấp, cài đặt, bảo trì và managed service.
      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.
    • Việc đổi license đó tự nó đã là phản ứng trước chuyện AWS kiếm tiền từ công việc của dự án upstream theo cách không bền vững đối với họ.
    • Tôi tò mò nếu Amazon chỉ trả cho những người tạo ra và duy trì phần mềm mã nguồn mở mà họ bán, mỗi chu kỳ tính phí trả 1 cent, thì sẽ ảnh hưởng đến họ đến mức nào.
      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.
    • Kể từ lần đầu tôi gửi patch cho Redis mà một committer không trả lời tin nhắn của tôi, rồi đưa patch đó vào dưới tên của chính anh ta, thì tôi đã mất phần lớn sự đồng cảm với triết lý của nhiều dự án open source.
      Họ xứng đáng gặp Valkey.
      Tôi vẫn còn nhớ cả JBoss và Marc Fleury.
    • Dĩ nhiên AWS chỉ tạo fork sau khi license bị đổi để họ không thể tiếp tục kiếm tiền từ code của dự án đó nữa.
      Đó 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.

    • Những gì Cloudflare cung cấp đã tiến gần hơn tới thứ tôi từng mong ở AWS.
      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.
    • Tôi tò mò Docker có thực sự làm việc quản lý PostgreSQL dễ hơn không.
      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.
    • Tôi đã muốn thích Cloudflare Workers, và chắc cũng có lý do kỹ thuật để thích, nhưng cách họ bắt bạn dùng Wrangler project cho những việc như kích hoạt email khiến tôi thấy như đang ở ngay trước ngưỡng bị khóa chặt vào nền tả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ụ.

    • DynamoDB khá tốt nếu dùng đúng theo cách nó được thiết kế.
      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.
    • Nhiều dịch vụ như DynamoDB hay Lambda có trường hợp sử dụng rất cụ thể.
      Đừng dùng một key-value store vui vẻ làm database.
    • Vài năm trước khi làm một ứng dụng, tôi cần một DB để lưu khoảng 50 triệu record, với khoảng 10 nghìn lượt đọc+ghi mỗi tháng và 1 index.
      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ừ bên trong thì IAM có lẽ có tới hàng nghìn tùy chọn, nhưng bản chất chỉ là “role này có thể làm gì trên thứ gì (action + resource)” và “ai có thể truy cập role này”.
      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.
    • Mẫu hình “X quá phức tạp” nên chặn không cho dùng, rồi cuối cùng lại tái tạo X theo kiểu tệ hại, là chuyện phổ biến đến đáng kinh ngạc trong công nghệ và phần mềm.
      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.
    • AWS có thể đắt hơn tự host, nhưng khoản tiết kiệm đó thường nhỏ bé trước chi phí kỹ thuật.
      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.

    • Chỉ cần bật một VPS thô trên EC2 hoặc Lightsail, gán public IP rồi xong.
      Không phải lúc nào cũng cần triển khai mọi pattern enterprise.
    • Thật đáng kinh ngạc khi Heroku gần như đã chạm rất chuẩn vào những gì phần lớn web app cần từ gần 20 năm trước.
    • Nếu bạn chưa từng dùng Azure thì có thể sẽ nghĩ chỉ mỗi AWS mới giống ác mộng.
    • Tôi đã chuyển sang Cloudflare và thật sự thấy dễ thở hẳn.
      Có đủ mọi thứ tôi cần và giá cả hợp lý.
    • AWS nhắm tới enterprise, chứ không phải dự án cá nhân.
      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.

    • ElastiCache đúng là một trong những dịch vụ đáng để cân nhắc tự host.
      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.