Thay hóa đơn Heroku 3.000 USD/tháng bằng máy chủ 55 USD/tháng

 (disco.cloud)
13 điểm bởi GN⁺ 2025-10-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • Nền tảng tìm việc phi lợi nhuận Idealist đã chuyển sang máy chủ dedicated giá rẻ để giải quyết vấn đề chi phí môi trường staging quá đắt trên Heroku
  • Trên Heroku, do mô hình tính phí theo từng môi trường, mỗi môi trường staging phát sinh chi phí khoảng 500 USD/tháng
  • Thay vào đó, họ dựng nhiều môi trường trên một máy chủ Hetzner CCX33 (55 USD/tháng) và dùng Disco để giữ nguyên trải nghiệm git push và tự động hóa như Heroku
  • 6 môi trường staging đang chạy ổn định trên một máy chủ, với mức sử dụng CPU 2% và bộ nhớ khoảng 14GB trên tổng 32GB, vẫn còn rất dư dả
  • Nhờ vậy, môi trường staging đã chuyển từ “gánh nặng chi phí” sang “tài nguyên có thể tạo tự do”, giúp cải thiện mạnh mẽ văn hóa thử nghiệm và triển khai của đội phát triển

Kinh nghiệm thực tế về chiến lược cắt giảm chi phí Heroku

Vấn đề: môi trường staging 500 USD/tháng

  • Idealist.org là một nền tảng tìm việc phi lợi nhuận quy mô lớn với hàng triệu lượt truy cập mỗi tháng, nên môi trường staging gần như giống hệt môi trường production là điều bắt buộc
  • Trên Heroku, chi phí của một môi trường staging kết hợp web/worker dyno và các add-on cần thiết như Postgres vào khoảng 500 USD/tháng
  • Chỉ cần duy trì hai môi trường dev, main cũng đã phát sinh chi phí cố định hơn 1.000 USD
  • Cách định giá của Heroku là mô hình tính phí theo từng môi trường; ngay cả khi giảm số dyno thì mức tiết kiệm cũng không nhiều, và chi phí tăng vọt khi số lượng ứng dụng tăng lên

Thử nghiệm: chuyển sang một máy chủ duy nhất

  • Để tối ưu chi phí, họ bắt đầu thử nghiệm bằng cách thuê một máy chủ Hetzner CCX33 duy nhất (55 USD/tháng)
  • Họ dùng giải pháp Disco để áp dụng nguyên cách triển khai bằng git push của Heroku lên máy chủ
  • Tất cả môi trường staging cùng dùng một instance Postgres dùng chung trên cùng máy chủ, giúp giảm mạnh gánh nặng chi phí cơ sở dữ liệu được quản lý
  • Xét từ góc độ kiểm thử, cách này cũng phù hợp vì có thể dễ dàng khởi tạo lại cơ sở dữ liệu tách biệt cho từng lập trình viên

Vì sao dùng Disco: khác gì với Docker Compose

  • Chỉ chạy docker-compose up trên máy chủ là chưa đủ để mang lại trải nghiệm tốt cho lập trình viên
  • Disco mang lại các lợi ích sau
    • Quy trình triển khai bằng git push giống hệt Heroku
    • Hỗ trợ tự động zero-downtime deploy cho mọi lần triển khai
    • Tự động cấp và gia hạn chứng chỉ SSL cho URL theo từng nhánh
    • Web UI trực quan để quản lý log và môi trường
  • Nhờ đó, họ không cần tự xây dựng hay duy trì hệ thống tự động hóa quản lý triển khai mà vẫn giữ nguyên sự thuận tiện cho quá trình phát triển

Bùng nổ môi trường staging và hiệu quả tài nguyên máy chủ

  • Với Disco, việc mở rộng môi trường staging trở nên cực kỳ đơn giản
  • Trên một máy chủ, họ đồng thời vận hành các môi trường như sau
    • Nhánh chính
    • Nhánh feature-freeze
    • Môi trường throwaway tạm thời cho PR
    • Môi trường dài hạn cho các tính năng lớn đang phát triển, v.v.
  • Tổng cộng 6 môi trường staging độc lập đang chạy ổn định mà không gặp trở ngại
  • Nếu dùng Heroku thì sẽ tốn 3.000 USD/tháng, nhưng với Hetzner chỉ tiêu thụ CPU 2%, bộ nhớ 14GB (trên 32GB) trong một cấu trúc chi phí thấp

Trade-off và các cân nhắc thực tế

  • Đây không phải là giải pháp thay thế hoàn hảo, và sẽ phát sinh thêm một số gánh nặng vận hành
  • Các tác vụ hạ tầng như cấu hình DNS, CDN cho từng môi trường mới vẫn chưa được tự động hóa
  • Nhóm phải gánh trách nhiệm vận hành như giám sát máy chủ, cập nhật bảo mật, và ứng phó khi có sự cố
  • Do Hetzner bị hạn chế về region tại Mỹ, nó có thể không phù hợp cho dịch vụ production phục vụ người dùng tại Mỹ
  • Khi máy chủ gặp sự cố, sẽ có trade-off về tính sẵn sàng khi phải chấp nhận cài đặt lại
  • Việc điều chỉnh ứng dụng để phù hợp với Docker networking cần khoảng một ngày công kỹ sư

Insight và thay đổi đạt được

  • Sau hơn 6 tháng vận hành, hạ tầng này đã trở thành cấu trúc thường trực
  • Thay đổi lớn nhất không chỉ là tiết kiệm chi phí, mà còn là việc môi trường staging giờ được nhìn nhận như một tài nguyên dồi dào và linh hoạt
  • Lập trình viên có thể tự do tạo môi trường cho từng pull request bất cứ khi nào cần mà không phải xin phép hay lo về chi phí
  • Cả đội rút ra bài học rằng không chỉ chi phí mới là gánh nặng, mà sự ngần ngại khi sử dụng mới chính là tổn thất thực sự
    • "Gánh nặng tài chính đã kìm hãm tốc độ phát triển và khả năng thử nghiệm"

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-10-22
Ý kiến trên Hacker News

  • Nhìn ảnh chụp htop thì điều dễ thấy là không có swap, nên tôi khuyên bật earlyoom để tránh cả máy chủ bị sập khi dịch vụ ngốn bộ nhớ bất thường; Linux kernel OOM killer thường phản ứng quá muộn. Cũng có thể bật zram để nén RAM và overprovision như dân chuyên. Phần mềm chạy lâu dài thường hay bị rò rỉ bộ nhớ, và việc nén khá hiệu quả trong trường hợp này. Tôi đã ghi lại trong một gist cách áp dụng bằng Ansible cho máy chủ bare metal của Hetzner, và nó cũng hoạt động y như vậy trên VM.

    • Hoàn toàn không đồng ý. Khi đã chạm tới swap thì đa số ứng dụng sẽ gặp vấn đề nghiêm trọng; đây là điều ai cũng biết, và AWS EC2 cũng mặc định tắt swap. Đúng là AWS cũng muốn bán thêm RAM, nhưng swap không còn phù hợp với kỳ vọng hiện nay. Những năm 90 người ta còn chờ 2–3 giây cho một cú nhấp chuột, còn bây giờ chỉ cần không phản hồi là người ta tưởng hệ thống chết rồi và khởi động lại ngay.

    • Một phương án khác là thêm RAM và điều chỉnh oom_score theo từng ứng dụng, đặt trọng số bị kill cao cho ứng dụng kém quan trọng và trọng số âm cho ứng dụng quan trọng. Ví dụ OpenSSH đã được đặt oom_score_adj là -1000. Việc gần như vô hiệu hóa overcommit trên máy staging/production cũng rất hữu ích. Tôi tính các giá trị min_free và reserve theo công thức dựa trên dung lượng RAM rồi cấu hình chúng. Tôi đã vận hành hơn 50.000 máy chủ vật lý không swap trong hơn 10 năm và thấy cách này hiệu quả ngoài thực tế. OOM chỉ xảy ra khi triển khai mã mà tính sai nhu cầu bộ nhớ, hoặc khi không tuân theo best practice của Java, nhưng chuyện đó thì dài. Cũng có thể đặt giới hạn bộ nhớ theo từng ứng dụng bằng cgroup, nhưng tôi xin bỏ qua phần giải thích. Nếu là máy chủ hoàn toàn in-memory và không cần ghi ra đĩa, tôi còn khuyên thiết kế để OOM không bao giờ xảy ra và hệ thống tự self-heal. Việc cấu hình panic reboot (kernel.panic, vm.panic_on_oom v.v.) để có thời gian chụp thông báo crash qua DRAC/iLO cũng hữu ích. Nhân tiện, trong hệ thống NFS diskless, nó còn có thể được dùng để cố ý kích hoạt khởi động lại toàn bộ farm khi xử lý sự cố.

    • Cảm ơn vì thông tin hữu ích. Tôi đang kiểm soát bằng ngưỡng RAM trong giới hạn hệ thống (systemd), nhưng tự hỏi liệu earlyoom có phải lựa chọn tốt hơn để ngăn cả instance bị treo khi tiến trình hoạt động bất thường không.

    • Tôi nghĩ giữ một lượng swap rất nhỏ để phòng hờ, ví dụ khoảng 1GB, là ý hay.

    • Từ năm 2010 đến giờ tôi không dùng swap.

  • Hôm qua tôi có thấy Nate Berkopec viết về chủ đề tương tự liên quan đến hiệu năng Rails, nói rằng Heroku đắt hơn 25–50 lần nếu tính theo hiệu năng. Thật sự là họ gần như không hề có ý định cạnh tranh về giá, và nếu họ chỉ cấp phép toàn bộ stack với mức giá hợp lý như Sidekiq thì dù phần cứng tách riêng vẫn tốt hơn nhiều. Năm 2025 mà dyno 1GB RAM giá $50 thì gần như là cướp. Đặc biệt là ứng dụng Rails tiêu chuẩn giờ không biến động tài nguyên lớn hơn trước, thậm chí còn hiệu quả hơn, thế mà giá lại cao hơn và chất lượng thì giảm. Buồn cười là biết bao nhiêu lập trình viên đang vận hành ứng dụng trên Heroku với chi phí hàng trăm đô mỗi tháng nhưng lại chạy trên phần cứng còn chậm hơn cả MacBook dùng để phát triển. Cuối cùng, cũng không khác gì xu hướng chung hiện nay: thay vì cung cấp sản phẩm tốt với giá hợp lý cho số đông, họ chỉ tập trung vào nhóm khách hàng giàu nhất và tiếp tục tăng giá.

    • Không chỉ là vấn đề tăng giá. Tôi nghĩ Heroku và các nhà cung cấp cloud đang hưởng lợi từ hiệu ứng mốc neo giá trong tâm lý học. Khi người dùng bắt đầu sử dụng dịch vụ, họ đặt một mức tham chiếu về giá và sau đó kỳ vọng chỉ thay đổi tuyến tính. Trong khi đó, hiệu năng phần cứng tính toán thực tế lại tăng theo cấp số nhân, nhưng người dùng chỉ cảm nhận tuyến tính. Giá Heroku hầu như không đổi suốt ít nhất 7 năm, trong khi phần cứng đã tiến bộ rất nhiều. Vì thế cảm giác bị lừa thực ra đến từ việc so mốc tham chiếu của năm 2025 với mức giá giữa thập niên 2010. Các nhà cung cấp cloud lớn thường đặt ra rào cản như mở khóa hiệu năng phần cứng mới hoặc cập nhật SKU. Heroku thì không có kiểu cạnh tranh đó nên giữ nguyên giá, và những bài như thế này cứ lặp lại mỗi khi kỹ sư mới bắt đầu cảm nhận được sức mạnh phần cứng hiện đại.

    • Bạn nói dyno 1GB RAM giá $50 là cướp, nhưng AWS cũng chẳng khá hơn bao nhiêu. Với $50/tháng thì m7a.medium mang lại 1 vCPU và 4GB RAM. RAM nhiều hơn thật, nhưng cũng đủ hiểu vì sao AWS kiếm được nhiều tiền đến vậy.

    • Tôi cũng đồng cảm với ý kiến rằng nên có mô hình cấp phép toàn bộ stack phần mềm với giá hợp lý như Sidekiq, nên chúng tôi đã open source canine.sh. Chúng tôi nghĩ các nhà cung cấp PaaS không nên áp thêm biên lợi nhuận quá mức lên trên một lớp cloud vốn đã có biên lợi nhuận rồi.

    • Cũng giống như nói thay dầu ở gara địa phương hay gọi steak ở nhà hàng thì tự làm ở nhà luôn rẻ hơn.

  • Cloud khiến người ta quên mất chỉ với một máy chủ có thể làm được bao nhiêu việc. Ngay cả môi trường staging mà cũng đưa lên cloud đắt đỏ thì tôi thấy khó hiểu, dù tôi cũng hiểu vì cloud hiện nay là một mớ phức tạp gồm nhiều thành phần đan xen.

    • Việc dạy nền tảng cloud cho nhiều lập trình viên và có vài chuyên gia cloud trong nhóm là cách tiết kiệm chi phí trong một khoảng thời gian khá dài. Nếu staging/prod được làm cho giống nhau thì cũng phát hiện sai sót nhanh hơn. Về sau bạn sẽ trả tiền cloud còn nhiều hơn tiền nhân sự, và khi đó thoát cloud mới thực sự có lợi. Tôi nghĩ cuối cùng sẽ đến lúc chuyển sang máy chủ riêng có ý nghĩa vì chi phí vượt quá cả giá đội ngũ lẫn phần cứng.

    • Có cảm giác cloud khiến lập trình viên sợ chính các máy chủ Linux. Tôi nghĩ phần lớn biên lợi nhuận là cái giá của nỗi bất an từ phía lập trình viên. Trong khi đó, self-hosting thực ra dễ và thú vị. Tôi chưa bao giờ thấy hấp dẫn với Heroku hay Vercel, và tin rằng không có trải nghiệm nào tốt hơn việc tự dựng máy chủ ngay từ đầu. Tôi khuyên mọi lập trình viên nên thử trực tiếp một lần.

    • Việc sao chép đầy đủ môi trường prod để giống thực tế rất hữu ích. Quy trình triển khai tương tự nên cũng tiết kiệm thời gian, đồng thời có thể kiểm thử trong điều kiện sát prod hơn.

    • Nếu làm một trang học hạ tầng dựa trên ý tưởng này thì sẽ khá thú vị: được cấp X tài nguyên trên cloud và phải cấu hình để chịu được một tải xác định, rồi cho mọi người thi điểm hiệu năng với nhau.

    • Khoảng năm 2006, máy nhỏ nhất của AWS có quy mô như một desktop dev khá ổn nên phải thuê hơn 2 năm mới đáng tiền. Còn phần cứng AWS ngày nay cỡ điện thoại di động hoặc laptop giá rẻ, nên chỉ cần thuê 3–6 tháng là mua phần cứng còn có lợi hơn. Trừ khi được giảm giá 75%, còn không thì on-premise tiết kiệm cả nhân lực lẫn chi phí hơn cloud.

  • Xin chào, tôi đang phát triển một PaaS mã nguồn mở tên là Disco cùng với bạn tôi Antoine Leclair. Dạo này có rất nhiều cuộc thảo luận về self-hosting và thoát cloud. Nếu có gì tò mò thì cứ hỏi nhé.

    • Nếu nhớ rằng trong câu “mức sử dụng tài nguyên máy chủ rất thấp” thì load average trong htop được tính theo số lõi CPU, điều đó còn ấn tượng hơn nữa. Ví dụ, nếu là 8 lõi thì load average 0.1 chỉ tương đương khoảng 1,25% tổng năng lực CPU. Tôi đọc blog rất thích, và bản thân cũng học được nhiều từ kiểu mẫu này.

    • Tôi tò mò không biết so với công cụ như Coolify thì Disco mang lại điều gì đặc biệt hơn. Tôi đang host phần lớn dịch vụ trên VPS của Hetzner, nên nếu Disco có điểm mạnh riêng thì tôi rất muốn biết.

  • Chúng tôi ở Hack Club cũng có trải nghiệm tương tự. Tổ chức phi lợi nhuận của chúng tôi tập trung giúp học sinh trung học tiếp cận lập trình và điện tử. Trước đây chúng tôi dùng Heroku, nhưng không chỉ là chi phí mà còn là câu hỏi liệu ứng dụng tiện ích nhỏ này có đáng để trả $15/tháng hay không. Năm nay chúng tôi self-host bằng Coolify và đang chạy 300 dịch vụ trên một máy chủ Hetzner giá $300/tháng. Kết quả là chúng tôi có thể triển khai nhiều mã hơn rất nhiều. Bài học lớn nhất là nếu bạn chỉ cần uptime 99% thay vì 99,99% thì thế giới sẽ rộng mở hơn rất nhiều. Hầu hết công cụ cho lập trình viên đều ám ảnh với 99,99%, nhưng nếu 99% là đủ thì có thể vận hành cực kỳ hiệu quả. Tôi cũng thấy hứng thú với Disco và chắc chắn sẽ thử.

    • Cảm ơn nhé, nếu có điều gì thắc mắc về dịch vụ Disco thì cứ hỏi trên Discord bất cứ lúc nào. Có hai ví dụ tương tự: một bootcamp/trường đào tạo lập trình ở Puerto Rico đã triển khai toàn bộ dự án cuối khóa của học viên lên một VPS duy nhất, và tại Recurse Center họ đang host 75 dự án web trên một chiếc Raspberry Pi (liên kết).

    • Và nếu thực sự cần 99,99% thì tôi nghĩ tốt nhất là nên tránh hyperscaler (các nhà cung cấp cloud siêu lớn). Vụ AWS ngừng hoạt động vài giờ gần đây là một ví dụ.

    • 300 cái thì tôi tò mò mỗi dịch vụ đảm nhiệm vai trò gì.

  • Nhìn vào tình hình hiện tại, tôi cũng thấy self-hosting là một giải pháp rất hấp dẫn, nhưng tôi muốn nói một điểm về chính bài viết này. Bài này có cảm giác bị AI biên tập rất mạnh, và thực tế phần “Bridging the Gap: Why Not Just Docker Compose?” là sao chép nguyên xi 1:1 mục “Powerful simplicity” trên landing page sản phẩm Disco. Bài blog này cũng là case study duy nhất được đưa ra trên trang chủ của họ.

    • Nói hoàn toàn đúng. Tôi muốn đưa ra ba lý do để biện hộ (đùa thôi), nhưng thư viện của chúng tôi là mã nguồn mở và chúng tôi tự hào vì Idealist đã tiết kiệm được chi phí. Nếu việc khoe điều đó bị tính là quảng bá thì tôi vẫn rất tự hào.

    • Có người nói bài viết marketing là vấn đề, nhưng tôi tò mò vì sao lại là vấn đề. Điều đó có bị cấm trong hướng dẫn của Hacker News không, hay bạn nghĩ mọi nội dung marketing đều cần được gắn nhãn? Trên đời này có rất ít thứ không phải là marketing.

    • Viết một bài blog marketing về cạnh tranh giá cả, nhưng trên website công ty mình lại không công khai giá mà chỉ cho đặt lịch họp, nên với tôi đó là red flag lớn nhất liên quan đến giá.

    • Tôi cũng đi tìm ngay mô hình doanh thu của họ, nhưng chỉ có cảm giác là chắc sẽ sớm được công bố.

    • Đây đâu phải lần đầu có một bài viết pha yếu tố marketing, nên tôi không hiểu case-study-driven marketing thì có gì sai. Đây là một case khá nhẹ nhàng, và dù mang tính marketing thì tôi vẫn thấy nó thú vị và hữu ích.

  • Giá Heroku thật sự điên rồ. Khoảng 10 năm trước, tôi đã sốc khi thấy startup nơi mình làm chi hơn $10.000 mỗi tháng chỉ để vận hành dịch vụ tạo mã QR dưới dạng bảng HTML rồi hiển thị trong email. Tính ra là khoảng $0,15 mỗi cái. Trưởng nhóm dev lúc đó còn chưa từng profile code, sau này hạ được xuống $0,01 mỗi cái nhưng vẫn rất phi lý.

    • Tôi không hiểu vì sao chỉ tạo một mã QR lại tốn đến mức đó, trong khi ngay cả dùng edge cloud hosting cũng có thể làm miễn phí.

  • Tôi không thực sự hiểu vì sao cần tới 6 máy staging (mỗi máy $500). Nếu là vì đội ngũ lớn thì $3.000 tiền máy chủ cũng chẳng đáng kể so với hơn $100.000 mỗi năm tiền nhân sự, đúng không? Tôi xem idealist.org rồi, chỉ là một bảng tin việc làm nên cảm giác hơi quá tay.

    • Sáu máy staging là để phục vụ main, dev, và nhiều nhánh khác để QA không thuộc nhóm phát triển có thể tự kiểm tra trực tiếp. Mỗi lần triển khai staging là chi phí tăng rất nhanh với dyno Performance-M, nhiều dyno Standard, RabbitMQ, cơ sở dữ liệu, v.v. Dịch vụ của Idealist có tới 100.000 người dùng mỗi ngày nên có rất nhiều kỹ thuật phía sau để bảo đảm độ tin cậy và tốc độ.

    • Đọc kỹ thì có vẻ họ đã dựng các máy staging để làm môi trường dev, nơi mỗi lập trình viên có thể chạy đồng thời nhiều dịch vụ, nên mới cần nhiều máy như vậy.

    • Mọi người thường bỏ qua việc tính chi phí nhân công (man-day) trong bài toán tổng chi phí thực tế.

  • Tôi đang muốn thay Heroku nhưng chỉ cần chỗ để dump site Django và cơ sở dữ liệu lên đó mà không phải tự quản trị hệ thống. Không biết đâu là lựa chọn tốt nhất trong trường hợp này.

    • Render.com có lẽ là thứ gần nhất, và tôi thực sự hài lòng khi dùng nó. Workflow giống Heroku, rẻ hơn, và tôi cũng hài lòng với việc khởi động lại ban đêm cũng như hỗ trợ các phiên bản Python mới nhất.

    • Tôi cũng khuyên nên học Docker Swarm. Việc triển khai chỉ là push container một lần rồi chạy một lệnh. Tôi còn tự làm rove.dev, một công cụ CLI miễn phí vừa để triển khai vừa để diff service. Hoặc bạn cũng có thể cân nhắc PaaS dựa trên VM như Semaphore, Dokku, Dokploy.

    • Chỉ cần chọn VPS phù hợp với nhu cầu về giá/hiệu năng/vị trí/hỗ trợ rồi gắn công cụ triển khai như Coolify, Dokploy là dùng được. Gần đây tôi đã chuyển Django/Postgres từ Google App Engine sang bằng Coolify và Mythic Beasts khá dễ dàng. Dù kỹ năng đã mai một nhiều nhưng quá trình migration vẫn thật sự rất nhẹ nhàng.

    • Tôi nghĩ chỉ cần dựng một máy trên Hetzner rồi cấu hình nginx với các dịch vụ systemctl là đủ.

    • PythonAnywhere(liên kết) cũng ổn.

  • Dự án rất hay. Tôi đọc tài liệu thì thấy có vẻ tích hợp GitHub là yêu cầu bắt buộc của Disco, không biết có đúng không? Và liệu có thể triển khai trực tiếp image Docker sẵn có trong registry của tôi mà không cần quy trình build riêng không, kiểu giống --skip-push --version latest của Kamal?

    • Đúng vậy, hiện tại cần tích hợp GitHub. Tuy nhiên, Disco cũng có thể kéo trực tiếp và triển khai image Docker đã tồn tại sẵn (chúng tôi self-host RabbitMQ theo cách này). Ví dụ cách triển khai image Meilisearch có thể xem tại đây và hướng dẫn này. Nhân tiện tôi cũng tò mò không biết quy trình của bạn thường là build rồi push lên registry, hay là cách nào khác; tôi rất muốn nghe chi tiết hơn về quy trình triển khai của bạn.