Hãy dùng một máy chủ lớn duy nhất (2022)

• Bản chất của cuộc tranh luận không phải là monolithic vs microservices, mà là liệu hệ thống phân tán có đáng với giá trị mang lại so với overhead phát triển/vận hành hay không
• Máy chủ đơn hiện đại có hàng chục đến hàng trăm lõi, bộ nhớ cấp TB, I/O hàng chục đến hàng trăm Gbps, nên có dư địa hiệu năng đủ lớn để gánh phần lớn dịch vụ web
• Các benchmark thực tế cho thấy một máy chủ có thể đạt Nginx 500 nghìn RPS, PostgreSQL 70 nghìn IOPS, NoSQL 1 triệu IOPS, mã hóa 4K 75 FPS và các mức xử lý hiệu năng cao khác
• Dùng cloud giúp tăng tính tiện lợi và độ sẵn sàng, nhưng premium chi phí khá lớn nên cần cân nhắc hiệu quả đầu tư
• Chỉ khi mô hình sử dụng biến động cực lớn thì kiến trúc cloud-native, serverless mới có lợi thế về chi phí
• Tuy nhiên, premium chi phí của serverless/cấu hình microVM là rất lớn, và nếu workload liên tục/có thể dự đoán thì mở rộng theo chiều dọc sẽ kinh tế hơn
• Độ sẵn sàng có thể được giải quyết phần lớn bằng dự phòng chính/phụ (hoặc 2×2) và kết hợp phần cứng khác nhau, còn chiến lược chỉ phân tán CDN và backup là hợp lý

---

Tổng quan: giá trị của “một máy chủ lớn” so với hệ thống phân tán

• Cốt lõi của tranh luận “monolithic vs. microservices” là đánh giá xem việc áp dụng hệ thống phân tán có đáng với thời gian và chi phí thực tế của lập trình viên hay không
• Phần mềm hiện đại chạy trên ảo hóa máy chủ và nhiều lớp trừu tượng khác nhau; ngay cả “serverless” hay “bare metal” rốt cuộc cũng được xây dựng trên tài nguyên máy chủ vật lý
• Máy chủ ngày nay có hiệu năng trên chi phí cao hơn nhiều so với những gì ta thường nghĩ
  • So với trước đây, cấu hình máy chủ đã tăng vọt về số lõi, băng thông bộ nhớ, làn PCIe, lưu trữ NVMe, và nhiều dịch vụ có thể đạt QPS mục tiêu mà không cần phân tán

Hiệu năng mạnh mẽ của phần cứng máy chủ

• Máy chủ ví dụ của Microsoft Azure có cấu hình 2 CPU máy chủ AMD thế hệ 3, tổng cộng 128 lõi 256 luồng
• Một máy chủ đơn có thể đạt mức hiệu năng tính toán khoảng 4 TFLOPs, vượt cả siêu máy tính đầu những năm 2000
• Bố trí 16 khe DDR4-3200 cho mỗi socket RAM cho phép mở rộng tối đa 8TB bộ nhớ, và trên thị trường mua sắm thực tế cũng đã hỗ trợ 1TB RAM
• Tổng cộng 128 làn PCIe Gen4, cùng 30 SSD NVMe và card mạng 50~100Gbps cho phép kết nối lưu trữ và mạng hiệu năng cao

Có thể làm gì với một máy chủ đơn như vậy (trích benchmark)

• Có thể đạt truyền video 400–800 Gbps, NoSQL 1 triệu IOPS, PostgreSQL 70 nghìn IOPS, Nginx 500 nghìn RPS
• Ngay cả với các tác vụ ngốn CPU, bộ nhớ, I/O như build Linux kernel trong 20 giây, mã hóa x264 4K 75FPS, máy chủ vẫn cho throughput cao

So sánh chi phí thuê/mua máy chủ

• OVHCloud: có thể thuê máy chủ 128 lõi/512GB RAM với giá khoảng $1,318/tháng
• Hetzner: cung cấp máy chủ 32 lõi/128GB RAM với giá €140/tháng, mức giá thay đổi theo cấu hình
• AWS m6a.metal: máy chủ 96 lõi vật lý/768GB RAM có giá $8.29/giờ, khoảng $6,055/tháng, cho thấy premium cloud rất lớn
• Nếu mua trực tiếp máy chủ cấu hình tương tự từ Dell thì giá khoảng $40,000, có thể hoàn vốn so với cloud trong khoảng 8 tháng
• Nếu giả định cùng throughput bằng serverless thì ước tính premium chi phí là gấp 5.5 lần so với instance, gấp 25 lần so với hosting giá rẻ

Vì sao hệ thống phân tán từng được ưa chuộng

• Trước đây (quanh năm 2010), do giới hạn về hiệu năng CPU, bộ nhớ và thiết bị lưu trữ, các dịch vụ quy mô lớn buộc phải dùng nhiều máy chủ kết hợp
• Gần đây, nhờ máy chủ đơn cỡ lớn, SSD NVMe, băng thông bộ nhớ cao, giới hạn xử lý của một node đơn đã được nâng lên đáng kể, nhưng các đơn vị VM và container vẫn thường được thiết kế dựa trên tài nguyên máy chủ nhỏ

Khi nào chỉ một máy chủ lớn là đủ

• Phần lớn dịch vụ web dưới 10k QPS chỉ cần một máy là đủ; các dịch vụ đơn giản thậm chí có thể đạt đến mức hàng triệu QPS
• Ngay cả streaming video, control plane trên một máy chủ đơn vẫn là phương án thực tế, và có thể dùng benchmark cùng bảng hiệu năng chung để ước tính kích thước máy chủ phù hợp
• Trừ các tình huống đặc biệt, chỉ cần cấu hình máy chủ chính và máy chủ backup là đủ để đảm bảo độ sẵn sàng

“Cao” hơn là “rộng”: ưu tiên vài máy chủ lớn thay vì cả cụm nhiều máy nhỏ

• Ngay cả khi cần cluster, một vài máy chủ lớn vẫn có overhead điều phối (O(n)) thấp hơn nhiều máy chủ nhỏ
  • Nói cách khác, về dài hạn, giảm số lượng máy và tăng cấu hình thường hiệu quả hơn
• Với serverless và mô hình dựa trên container ngắn hạn, tỷ lệ overhead còn lớn hơn nữa
• Nhược điểm là điểm lỗi đơn, nhưng có thể giảm đáng kể chỉ với mô hình chính/phụ (ở các DC khác nhau)
• Vững chắc hơn nữa là cấu hình 2×2 (2 máy ở DC chính + 2 máy ở DC phụ) kết hợp với triển khai phần cứng/nhà sản xuất khác nhau để tránh lỗi tương quan
• Khi thuê máy chủ, đa dạng hóa model máy chủ giúp giảm rủi ro hỏng dây chuyền của đĩa hoặc SSD cùng lô

Ưu điểm và giới hạn của việc dùng cloud

• Cloud mạnh ở độ sẵn sàng, tốc độ khôi phục, sự tiện lợi trong vận hành, và những điểm này xứng đáng với chi phí premium
  • Có thể khởi động lại nhanh chóng trong phạm vi chi phí mà không bị downtime, đồng thời tận dụng pool tài nguyên quy mô lớn được quản lý như một grid
  • Nhà cung cấp máy chủ thuê riêng có giá rẻ hơn, nhưng bị giới hạn về chất lượng, mạng và hỗ trợ cao cấp
• Tuy nhiên, đội ngũ bán hàng cloud thường khuyến nghị kiến trúc phụ thuộc vendor như VM autoscale, serverless, HA DB managed, nên cần cảnh giác với chi phí và độ phức tạp
• Bản thân việc xử lý lưu lượng lớn không phải là lý do chính để dùng cloud-native; trên thực tế có nhiều trường hợp một máy chủ lớn đơn lẻ vẫn có thể phục vụ hàng triệu người dùng đồng thời

Chi phí tải đỉnh và tiêu chí cho tải bursty

• Luôn sẽ có ai đó phải chuẩn bị năng lực cho tải đỉnh, nên cuối cùng chi phí cho peak sẽ được tính ở đâu đó trong chuỗi cung ứng
• Với các tác vụ bursty hoặc tạm thời (ví dụ: mô phỏng quy mô lớn chạy một lần), serverless/autoscale là kinh tế; nhưng với tải liên tục và có thể dự đoán, vận hành cố định trên máy chủ lớn hiệu quả chi phí hơn
• Nếu tận dụng cam kết 1 năm/spot/đàm phán với sales, chi phí instance còn có thể thấp hơn nữa, và premium so với serverless sẽ còn lớn hơn

Đánh giá định lượng về “premium cloud”

• Điện toán serverless như AWS Lambda có thể phát sinh premium chi phí cao hơn 5 đến 30 lần so với cùng một máy chủ
• Giả định: một máy chủ giá $8.2944/giờ cung cấp 1k QPS, 768GB RAM; nếu thay cùng throughput đó bằng Lambda thì chi phí sẽ vào khoảng $46/giờ, tức premium 5.5 lần
• Ước tính premium gấp 25 lần so với thuê OVH, và chỉ cần đạt 5% mức sử dụng thì hosting giá rẻ đã kinh tế hơn serverless
  • Nếu tận dụng hợp đồng dài hạn, spot instance, v.v. thì chênh lệch premium còn có thể lớn hơn
• Dù QPS khác nhau, nếu quy đổi theo memory-time thì hệ số premium tương tự nhau, và điều cốt yếu là scale máy chủ theo kích thước workload

Những phản biện và ngộ nhận phổ biến

• “Dùng cloud thì không cần nhân sự vận hành hệ thống”: thực tế chỉ là đổi tên vai trò thành Cloud Ops; vẫn cần năng lực về tài liệu, theo dõi thay đổi, xử lý deprecation, nên đây còn có thể là yếu tố làm tăng chi phí nhân sự
• “Dùng cloud thì không cần cập nhật bảo mật”: một phần có thể được miễn, nhưng chỉ giới hạn trong những mảng dễ tự động hóa; còn kiểm toán thư viện và xác minh cấu hình vẫn cần thiết
• “Cloud có thiết kế HA nên có thể yên tâm”: độ phức tạp gia tăng tạo ra điểm yếu mới, và ngay cả dự phòng đa region hoặc đa provider cũng không thể loại bỏ hoàn toàn sự cố tương quan
• “Cloud giúp tốc độ phát triển nhanh hơn”: đây là lợi thế về độ linh hoạt ban đầu, nên cứ dùng; nhưng cần theo dõi điểm bẻ cong chi phí để chuyển đổi đúng thời điểm
• “Lưu lượng của chúng tôi rất bursty”: trong trường hợp này, serverless/autoscale là phù hợp
• “Còn CDN thì sao?”: giảm độ trễ và tiết kiệm băng thông là thứ nên mua dưới dạng phân tán, và backup cũng tương tự, là hạng mục nên mua ngoài

Monolithic vs. microservices và cấu trúc máy chủ

• "Máy chủ lớn" thường gắn với kiến trúc monolithic, nhưng cũng có thể triển khai microservices dưới dạng nhiều container trên cùng một máy chủ
  • Tuy nhiên, overhead của giao tiếp liên tiến trình, triển khai và quan sát vẫn là gánh nặng ngay cả trên một host đơn, nên lợi ích hiệu năng thực tế so với độ phức tạp sẽ giảm đi đáng kể
• Với quy mô ban đầu hoặc vừa và nhỏ, monolithic hoặc một vài service có lợi hơn về độ đơn giản trong vận hành

Kết luận

• Trong đa số trường hợp, thay vì mở rộng ngang hay kiến trúc tập trung vào cloud, chọn mở rộng dọc (một máy chủ lớn) sẽ đơn giản và kinh tế hơn
• Nếu kết hợp dự phòng chính/phụ, phần cứng dị chủng, và tách riêng CDN/backup, có thể đạt được độ tin cậy thực dụng trong vận hành, đồng thời có ưu thế lớn về tổng chi phí sở hữu (TCO) trong môi trường tải liên tục
• Chỉ cần có chiến lược dự phòng phần cứng vững chắc, cách tiếp cận “một máy chủ lớn” sẽ là lựa chọn rất phù hợp cho dịch vụ thực tế

[GN⁺]

Ý kiến Hacker News

• Một trong những vấn đề lớn nhất của chi phí đám mây (Cloud Tax) là nó tự thân đã giới hạn một cách nhân tạo phạm vi giải pháp mà kỹ sư có thể cân nhắc. Ví dụ, nếu trả khoảng $200/tháng cho AWS thì bạn có được một máy chủ 4 vCPU và 16GB RAM, tức cấu hình cỡ một chiếc laptop phát triển cách đây 5 năm. Trong khi đó, ở Hetzner, với cùng số tiền đó bạn có thể thuê một máy chủ 48 lõi, 128GB RAM. Chênh lệch về năng lực tính toán là cực lớn. Có dung lượng lớn hơn gấp 10 lần thì những phương pháp vốn đủ hiệu quả cũng trở nên vô nghĩa trên các node nhỏ. Trong nhiều trường hợp, những điều kiện như vậy còn là cách tiết kiệm thời gian kỹ thuật phải bỏ ra để xây hệ thống phức tạp hơn. Tất nhiên vẫn cần cân nhắc thêm những yếu tố khác như độ bền vững, nhưng ngược lại, máy chủ chuyên dụng lại đảm bảo hiệu năng ổn định mà không phải lo noisy neighbor
  • Đến năm 2025, đã có thể dùng các dịch vụ như fly.io cho mục đích chung mà không cần đánh đổi sự tiện lợi hay phải qua quy trình phức tạp, còn với một số framework cụ thể thì cũng có lựa chọn như Vercel (một phương án tốt, tối ưu cho stack nhất định). Nếu cần hơn thế nữa thì có thể thuê những cỗ máy thực sự quái vật với giá rẻ từ OVH/Hetzner/Latitude. Nếu chỉ vận hành blog thì VPS thật sự rất nhiều. Đám mây truyền thống giờ gần như chỉ còn dùng cho các mục đích như tuân thủ quy định, quy trình nội bộ hoặc sự kém hiệu quả. Cả năng suất phát triển lẫn giá phần cứng đều bằng 0. Trừ khi đội ngũ hoàn toàn không có ràng buộc nào mà vẫn thích các hệ thống phê duyệt kiểu DMV, các node Intel ồn ào, biên lợi nhuận đắt đỏ và hỗ trợ tệ hại, còn không thì hầu như chẳng có ý nghĩa gì
  • Còn hơn cả thế—nếu dùng máy chủ bare metal thì không cần lo độ trễ mạng (latency), độ trễ/tranh chấp băng thông bộ nhớ của VM, hay các tầng cache riêng biệt; chẳng hạn chỉ cần cấp thật nhiều RAM cho Postgres và dùng cache đĩa của Linux. Đơn giản hơn rất nhiều mà lại nhanh hơn
  • Tôi không hiểu vì sao với những dịch vụ nhỏ nhặt người ta lại mặc định phải dùng AWS. Tôi không phức tạp tới mức như bạn, nhưng có một khách hàng đang dùng tổ hợp ứng dụng web PHP nhỏ + AWS server/SQS/S3 với chi phí $100/tháng. Tôi đã triển khai lại bằng Python/Django/PostgreSQL (ban đầu là SQLite) rồi chuyển sang VPS $25/tháng. OCR PDF, cập nhật giá, tìm sản phẩm thiếu, phục vụ website... tất cả đều chạy tốt trên 4 lõi và 6GB RAM. Đây là ứng dụng nội bộ, sẽ không bao giờ vượt xa 100 người dùng, nên kể cả sau này có lớn lên thì việc di trú cũng rất dễ. Ở quy mô hiện tại thì không có lý do gì để dùng server AWS $100 cả, ít nhất là cho tới khi thật sự cần mở rộng cực lớn
  • Hoàn toàn đồng ý. Nếu dùng cơ sở dữ liệu nhúng như sqlite và tối ưu ghi theo lô (batch) thì với Hetzner cũng đi được rất xa. Lập luận kiểu “đặt trước quá nhiều dung lượng nên lãng phí” không còn đúng nếu bước ra ngoài AWS (giá/hiệu năng vượt trội hoàn toàn). Thậm chí hệ thống càng phức tạp thì đôi khi độ tin cậy và khả năng phục hồi lại còn kém hơn một node đơn. Rất hiếm khi chỉ có đúng một thành phần bị cô lập rồi hỏng hẳn
  • Tôi lại nghĩ ngược lại. Tôi thấy Hetzner rất tốt cho website nhỏ, nhưng với dự án lớn thì đám mây mang lại cảm giác gần như không có ràng buộc. Nếu là dự án mà thời gian của tôi đủ giá trị, thì chi phí hosting $200 hay $2000 cũng chẳng đáng kể. Tôi cũng không thấy khác biệt quá lớn về thời gian phát triển giữa AWS CDK/Terraform+GitHub Actions và Docker/K8s/Ansible+pipeline CI. Tôi không cảm nhận bare metal giúp tiết kiệm thời gian kỹ thuật nhiều hơn hẳn. IaC với Fargate+RDS cũng tiện. Nếu thật sự cần tách biệt, mở rộng, đảm bảo độ bền cho lưu trữ file, hay phải tích hợp nhiều dịch vụ hạ tầng chuyên biệt như tạo subdomain động, thì ngược lại, chi phí học và tích hợp thêm các dịch vụ mới còn lớn hơn nhiều. Thực ra tôi đã làm việc này từ trước thời đám mây, và nếu là dự án kiếm ra tiền thì tôi cho rằng chi phí cloud đáng để đầu tư. Nếu dự án còn thấy chi phí đó quá nặng thì có lẽ nó thiên về sở thích hơn là kinh doanh. Việc quản lý RAID hay nhiều hệ thống file cluster là thứ tôi không muốn đụng tới với nguồn lực của đa số startup/công ty hay với thời gian của chính mình. Cảm giác giống như sở thích vọc Arch+Emacs so với kiểu hài lòng với MacBook vậy. Nếu bạn muốn đổi cả kernel scheduler thì tôi sẽ bảo dùng Arch, còn không thì tôi khuyên MacBook. Mặt khác, tôi cũng từng có trải nghiệm rằng nếu thật sự không có ngân sách mà raw throughput là yếu tố quan trọng thì server dedicated là lựa chọn hoàn hảo (tiết kiệm được hàng nghìn đô). Nếu thành công thì từ lúc đó có lẽ tôi sẽ scale theo chiều dọc, nhưng đây là trường hợp hiếm
• HN (Hacker News) vận hành 2 máy: một máy cho dịch vụ thực tế và một máy dự phòng. Đây là một mô hình hữu ích vì khi có sự cố phần cứng hoặc cần nâng cấp thì có thể failover ngay. Tuy nhiên, nếu hai máy là bản sao hoàn toàn giống nhau thì cũng phải cẩn thận vì cả hai có thể cùng hỏng một lúc
  • Không nghiêm trọng kiểu như SSD, nhưng CPU AMD cũng từng có một lỗi khá thú vị. Sau khoảng 1044 ngày thì một lõi cụ thể có thể treo hẳn trường hợp CPU AMD EPYC Rome bị treo
  • Không biết có thống kê nào về downtime của HN (Hacker News) không. Tôi chỉ nhớ trong 10 năm qua nó bị sập một hai lần, nên cảm giác uptime phải trên 99.99%
• Tôi đã dùng mô hình hybrid colo + public cloud hơn 10 năm, và từ một quy mô nhất định trở đi thì đó luôn là cách tối ưu chi phí nhất. Hiệu suất phần cứng cũng đang tiếp tục tốt lên. Cần có quản trị viên mạng/hạ tầng, nhưng thực ra bây giờ việc quản lý rất dễ, mà ngược lại cũng gần như luôn cần “quản trị viên cloud”, nên hiệu quả tiết kiệm nhân sự hầu như không có. Có rất nhiều lựa chọn colo, và các nhà cung cấp thường bán gộp băng thông. Có thời tôi từng chạy 8 cụm dell vrtx, SAN, hơn 500 VM (từ msSQL cỡ lớn tới kube), mà nếu đặt trên public cloud thì kể cả có giảm giá đặt trước cũng sẽ ra hóa đơn hơn 6 chữ số. Trong khi đó chi phí colo là $2,400/tháng (chủ yếu do điện). Điều luôn làm tôi ngạc nhiên là node public cloud chậm đi rõ rệt thế nào (dù cùng thế hệ CPU/VCPU). Tất nhiên phải theo sát các deal thiết bị, cập nhật, giấy phép và hợp đồng hỗ trợ, nhưng trên thực tế hoàn toàn có thể quản lý được. Và giờ thì cũng dễ nối cloud với mạng riêng, chỉ cần kéo fiber rồi nối với VPC là xong
  • Tôi hiểu colo là tự mua phần cứng, rồi chỉ thuê điện/rack/đường truyền ở datacenter; không biết có đúng không. Tôi muốn biết nó tốt hơn thuê bare metal server thông thường ở điểm nào
• Tôi đã tranh luận chuyện này với bạn bè nhiều năm rồi. Nhược điểm lớn nhất của hạ tầng cục bộ là bạn cần nhân sự chuyên môn để vận hành nó cho đúng. Bài này tập trung vào quy mô cao, nhưng ở phân khúc thấp hơn, nếu đã có sẵn chút thiết bị thì với một rack nhỏ hoặc mạng nhỏ là có thể hòa vốn sau 1 năm. Với mức premium của cloud hiện nay, có lẽ ngay cả khi thuê thêm một quản trị viên thì hạ tầng cục bộ vẫn kinh tế hơn
• Ở một công ty tôi từng tham gia khởi nghiệp, chúng tôi làm một engine tự động hóa cho doanh nghiệp, và cả đội muốn triển khai giải pháp dưới dạng SaaS để tối đa hóa doanh thu. Thực ra chỉ cần schema DB multi-tenant + VPS là đủ, nhưng cả đội lại mải mê học kubernetes và stack cloud-native, dành suốt 1 năm cho môi trường phát triển và tự động hóa vận hành. Cuối cùng công ty chẳng tồn tại được bao lâu rồi đóng cửa
  • Nhưng các kỹ sư thì nhờ trải nghiệm đó mà có thêm kinh nghiệm k8s trong CV và lại tìm được việc mới
  • Tôi cũng có trải nghiệm tương tự—đã lãng phí quá nhiều thời gian để giải quyết trước những vấn đề có khi 5 năm nữa mới cần. Phần lớn dự án và startup giai đoạn đầu chỉ cần PaaS hoặc cùng lắm là nginx+container docker là đủ. Khi nào pain point thực sự xuất hiện thì lúc đó hẵng nghĩ tiếp
  • Vì thế nên tôi thích dùng PaaS cho tới khi “hóa đơn thật sự bắt đầu đau”. Trả tiền cho heroku/render/fly để tập trung vào PMF (Product-Market Fit). Hoặc cũng có con đường là đốt tiền VC vào K8s vì thích làm server cho vui, rồi lặp lại vòng chuyển việc sang công ty tiếp theo
• Nhiều doanh nghiệp thật ra không quan trọng đến mức đó. Rất nhiều người tự tạo áp lực vì sợ gián đoạn vận hành, nhưng dịch vụ họ đang xử lý thực ra không hề quá sống còn. Kể cả môi trường production có biến mất giữa ban ngày thì cũng chỉ hơi phiền chứ thế giới không sụp đổ. Những công ty như vậy trước đây hoàn toàn có thể để 250 người dùng thoải mái trên một server văn phòng đơn giản, vậy mà lại cố chuyển lên cloud để rồi ngân sách phình to. Cloud xuất sắc cho một số tác vụ nhất định, còn phần còn lại khá giống phóng đại marketing. Tuy nhiên, nhiều kỹ sư lại có xu hướng ám ảnh với “khả năng mở rộng hoàn hảo”, nên thay vì chọn giải pháp đủ tốt thì cứ đi tìm kiến trúc lý tưởng
  • Một đồng nghiệp cũ của tôi lúc nào đi làm cũng hay nói thế này: “Ít nhất thì nếu mình mắc lỗi cũng không có ai chết cả, nên không cần phải lo quá.” Anh ấy từng làm những công việc có trách nhiệm nặng nề hơn nhiều, nên tư duy đó đã giúp ích rất lớn trong những tình huống khó khăn
• Khi cố xây cấu trúc phức tạp để đạt mục tiêu uptime 100%, người ta lại thường mắc những lỗi khiến độ tin cậy giảm đi. Phần lớn doanh nghiệp thực ra chịu được việc thỉnh thoảng downtime 1–2 giờ hoặc mất dữ liệu. Chỉ cần thống nhất kỳ vọng này trước thì có thể kỹ thuật theo hướng cấu trúc đơn giản hơn mà vẫn đáng tin cậy hơn nhiều
  • Chi phí cũng rẻ hơn rất nhiều. Tuy nhiên, những kỳ vọng như vậy thường không dễ được lãnh đạo phi kỹ thuật chấp nhận (đặc biệt là chuyện mất dữ liệu gần như không được chấp nhận). Kỹ sư thì bảo chỉ quản lý môi trường thôi, nhưng thực tế không dễ tách bạch như vậy, và nếu xảy ra lỗi thì rất dễ bị xem là thiếu năng lực
• Đây là một bài viết khá hay. Khi scale theo hướng này (không dùng cloud) thì cũng nên cân nhắc thêm CDN. Dùng CDN còn có thêm tác dụng như WAF và DNS failover. Tuy nhiên, điểm hơi tiếc của cách không dùng cloud là phải tự vận hành DB. Vì vậy có thể cân nhắc nhà cung cấp cho sẵn tùy chọn cloud DB, hoặc nếu chạy mô hình active/passive thì có thể đặt node passive trên VM cloud + autoscale để tiết kiệm hơn. Giá thuê server bây giờ thực sự rất rẻ, VPS 4GB chỉ khoảng $6, còn bare metal 32GB quad-core khoảng $90. Dùng các trang so sánh giá như serversearcher.com sẽ khá hữu ích
  • Tôi từng chạy Postgres trong container Docker và chỉ thiết lập backup định kỳ thôi mà không gặp vấn đề gì lớn. Vận hành cũng đơn giản nên thật sự không có gì bất tiện đáng kể
  • Trên máy đơn, sqlite cho hiệu năng cao hơn nhiều và dễ quản lý hơn Postgres/MySQL
• Tôi cũng đang chạy dịch vụ trên VPS. Tôi đã bỏ cloud từ lâu rồi. Nếu dự án của tôi bắt đầu kiếm được tiền, tôi định sẽ mua thiết bị rồi mang đi colo. Cloud từng giống như một app hẹn hò đối với tôi—giờ hết vui rồi, tôi muốn làm thứ gì đó thật sự có ích hơn
  • Bản thân colo cũng đầy vấn đề. Chuyện phần cứng chết vì mất điện ở datacenter thực ra rất thường gặp. Trớ trêu là điện ở nhà tôi còn ổn định hơn. Nếu không phải loại hình kinh doanh mà vài phút downtime có thể ảnh hưởng tới doanh thu hàng triệu đô, thì phần lớn trường hợp chạy server ở tầng hầm cũng chẳng sao. Nhiều người đánh giá quá cao nhu cầu về uptime 99.999% hay băng thông lớn. Colo cũng không rẻ như mọi người nghĩ. Giá điện ở datacenter đôi khi còn đắt hơn điện dân dụng hoặc điện doanh nghiệp thông thường. Thứ thật sự rẻ chỉ là Internet/đường cáp quang, và giờ ở nhiều nước đã có thể dùng đường truyền doanh nghiệp 5–10Gbit với giá khoảng 100 euro (trong khi trước đây chỉ 1Gbit thôi đã hơn 2.000 euro)
• Bỏ qua mọi phân tích chi phí hay dung lượng, việc đi ngược xu hướng chung của ngành vốn đã không dễ. Lợi thế “không phải bận tâm đến phần cứng” đúng là có thật. Thêm nữa, cũng tồn tại tư duy rằng phải tránh capex (chi tiêu vốn) bằng mọi giá, vì phần cứng server đòi hỏi chi phí đầu tư ban đầu lớn. Và cũng có một cơ chế tâm lý là nếu AWS region gặp sự cố thì nó không giống như “lỗi của mình”, còn nếu server nội bộ hỏng thì lại có cảm giác đó là “trách nhiệm của mình”
  • Việc cực kỳ e ngại capex gần như là hệ quả từ cấu trúc đầu tư VC—nếu nhà đầu tư chỉ đòi tăng trưởng cực nhanh thì việc đầu tư trước (mua server) về mặt logic rất khó biện minh. Ngược lại, doanh nghiệp ổn định thì có thể hấp thụ những khoản capex nhỏ hằng năm một cách bình thường
  • Không nhất thiết phải mua phần cứng server—thuê từ những nơi như Hetzner cũng hoàn toàn đủ. Tôi muốn nghe giải thích cụ thể hơn về cái gọi là lợi thế “không phải bận tâm đến phần cứng”
  • Tư duy né capex đúng là có thật. Chỉ cần biết dùng máy tính bỏ túi là cũng thấy giá server ngày nay không còn là khoản có ý nghĩa lớn với toàn bộ doanh nghiệp. Thứ thật sự đắt là “không gian” xung quanh server, nên đa số trường hợp người ta không thuê server mà thuê chỗ đặt server (rack/điện)
  • Suy cho cùng, thứ doanh nghiệp thật sự trả tiền là “sự trừu tượng hóa trách nhiệm” (abstraction of responsibility). Các lãnh đạo cấp cao ở tập đoàn lớn cảm thấy yên tâm hơn khi chọn giải pháp từ những tên tuổi lớn như MS hay AWS
  • Nếu thuê bare metal server thì cũng không cần lo capex hay bảo trì