Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như mọi kiến trúc sư hệ thống ở Việt Nam đều gặp ít nhất một lần trong sự nghiệp: "Chúng ta nên chạy hệ thống trên cloud hay tự vận hành trên hạ tầng của mình?" Nghe thì đơn giản, nhưng đằng sau nó là hàng loạt quyết định có thể ảnh hưởng đến chi phí vận hành trong nhiều năm, đến tốc độ ra mắt sản phẩm, đến khả năng tuân thủ pháp luật, và thậm chí đến việc bạn có tuyển được đúng người hay không.
Điều khiến quyết định này khó không phải vì thiếu thông tin — mà vì thừa thông tin thiên lệch. Các nhà cung cấp cloud (AWS, Google Cloud, Azure) có ngân sách marketing khổng lồ và luôn kể câu chuyện "cloud là tương lai, on-prem đã chết". Ngược lại, đội ngũ hạ tầng truyền thống, những người đã đầu tư nhiều năm vào data center, lại có xu hướng bảo vệ mô hình cũ. Là người ra quyết định kiến trúc, bạn phải đứng giữa hai luồng thông tin đó và đưa ra lựa chọn dựa trên bối cảnh cụ thể của tổ chức mình, chứ không phải theo trào lưu.
Bài này không nhằm thuyết phục bạn chọn cloud hay on-prem. Nó trang bị cho bạn một khung tư duy để tự trả lời câu hỏi đó — và quan trọng hơn, để giải thích được quyết định của mình một cách thuyết phục trước ban lãnh đạo cũng như đội kỹ thuật. Đây chính là bản chất của công việc ra quyết định kiến trúc: không có đáp án đúng tuyệt đối, chỉ có đáp án phù hợp với ràng buộc của bạn.
Khái niệm cốt lõi
Trước hết, hãy làm rõ ba mô hình triển khai chính, vì nhiều người vẫn nhầm lẫn khi gộp tất cả thành "cloud" và "không cloud".
Ba mô hình triển khai
On-Premise (On-Prem): Bạn sở hữu và vận hành toàn bộ hạ tầng — máy chủ vật lý, thiết bị mạng, hệ thống lưu trữ — đặt tại data center của công ty hoặc thuê chỗ đặt máy (colocation) ở một trung tâm dữ liệu như FPT, Viettel IDC, hay CMC. Bạn chịu trách nhiệm từ điện, làm mát, bảo mật vật lý, cho đến vá lỗi hệ điều hành.
Public Cloud: Bạn thuê tài nguyên tính toán từ nhà cung cấp qua Internet, trả tiền theo mức sử dụng (pay-as-you-go). Bạn không sở hữu phần cứng; nhà cung cấp lo phần vật lý, bạn lo phần logic bên trên.
Hybrid Cloud: Kết hợp cả hai — giữ một số workload nhạy cảm hoặc ổn định trên on-prem, đẩy phần cần co giãn linh hoạt lên cloud. Đây là mô hình thực tế phổ biến nhất ở các doanh nghiệp lớn Việt Nam, đặc biệt trong ngành ngân hàng và viễn thông.
Ưu điểm của Cloud
Hãy nói thẳng vào những giá trị mà cloud thực sự mang lại, chứ không phải khẩu hiệu marketing.
Co giãn đàn hồi (Elastic scale): Đây là lợi thế mạnh nhất. Bạn có thể tạo mới hoặc thu hồi hàng chục máy chủ trong vài phút. Với một sàn thương mại điện tử chuẩn bị cho ngày sale 12/12, khả năng nhân đôi công suất trong buổi sáng và trả lại vào buổi tối là điều gần như bất khả thi với on-prem.
Dịch vụ được quản lý (Managed service): Thay vì tự cài đặt và vận hành một cụm PostgreSQL với replica, backup, failover, bạn dùng Amazon RDS và để AWS lo. S3 cho lưu trữ, Lambda cho tính toán không cần quản lý máy chủ. Điều này giải phóng đội ngũ vận hành (ops) khỏi những công việc lặp đi lặp lại, để họ tập trung vào giá trị kinh doanh.
Phủ sóng toàn cầu (Global reach): Nếu sản phẩm của bạn cần phục vụ người dùng ở nhiều quốc gia, cloud cho phép triển khai đa vùng (multi-region) chỉ với vài thao tác cấu hình. Xây một data center ở Singapore để phục vụ khách Đông Nam Á là chuyện của nhiều tháng và nhiều triệu đô; bật một region trên AWS Singapore là chuyện của một buổi chiều.
Chi phí đầu tư ban đầu thấp (CapEx thành OpEx): Bạn không cần bỏ ra vài tỷ đồng mua máy chủ trước khi có dòng doanh thu đầu tiên. Với startup, đây là yếu tố sống còn.
Ưu điểm của On-Prem
On-prem không hề lỗi thời — nó vẫn là lựa chọn tối ưu trong nhiều tình huống.
Chi phí có thể dự đoán và rẻ hơn ở quy mô ổn định: Khi workload của bạn ổn định và chạy 24/7 với công suất cao, cloud trở nên đắt đỏ. Một máy chủ mua đứt và khấu hao trong 4-5 năm thường rẻ hơn nhiều so với thuê máy tương đương trên cloud trong cùng thời gian.
Kiểm soát và tuân thủ (Control & Compliance): Một số ngành và quy định pháp luật yêu cầu dữ liệu phải nằm trong lãnh thổ Việt Nam và dưới sự kiểm soát trực tiếp. Nghị định 13/2023 về bảo vệ dữ liệu cá nhân và các quy định của Ngân hàng Nhà nước khiến nhiều tổ chức tài chính buộc phải giữ dữ liệu nhạy cảm on-prem.
Độ trễ thấp và ổn định (Latency): Với các hệ thống cần độ trễ cực thấp và ổn định — ví dụ hệ thống giao dịch chứng khoán, hệ thống điều khiển sản xuất — việc đặt máy chủ ngay cạnh nơi phát sinh dữ liệu là lợi thế.
Không phụ thuộc nhà cung cấp (No vendor lock-in): Bạn không bị ràng buộc vào hệ sinh thái độc quyền của một nhà cung cấp, và không phải lo về việc họ tăng giá hay thay đổi chính sách.
Những chiều cần cân nhắc
Khi ra quyết định, hãy đánh giá theo các trục sau: chi phí tổng thể (TCO — Total Cost of Ownership, bao gồm cả nhân sự vận hành chứ không chỉ tiền thuê máy), yêu cầu tuân thủ và chủ quyền dữ liệu, đặc điểm workload (ổn định hay đột biến), năng lực đội ngũ, tốc độ ra thị trường, và độ chín của sản phẩm. Không có trục nào quan trọng nhất — trọng số phụ thuộc hoàn toàn vào bối cảnh của bạn.
Tình huống thực tế
Tình huống 1: Startup thương mại điện tử chọn cloud
Một startup bán lẻ mỹ phẩm trực tuyến tại TP.HCM, giai đoạn đầu chỉ có 4 kỹ sư và chưa ai chuyên về hạ tầng. Họ đứng trước lựa chọn: mua vài máy chủ đặt tại Viettel IDC hay dùng AWS.
Họ chọn cloud, và đó là quyết định đúng. Lý do: lưu lượng truy cập của họ cực kỳ khó đoán — bình thường vài trăm đơn mỗi ngày, nhưng vào các đợt livestream của KOL có thể tăng gấp 20 lần trong 2 giờ. Nếu mua máy chủ, họ phải mua đủ cho đỉnh điểm và để lãng phí 95% thời gian còn lại. Với AWS, họ dùng Auto Scaling để tự động thêm máy khi lưu lượng tăng và thu hồi khi giảm. Chi phí tháng đầu chỉ khoảng 8 triệu đồng, thay vì phải bỏ ra hơn 300 triệu mua phần cứng.
Bài học rút ra: Với sản phẩm còn non trẻ, workload biến động mạnh và đội ngũ mỏng, cloud gần như luôn là lựa chọn hợp lý. Tính đàn hồi và việc không phải bỏ vốn lớn ban đầu quan trọng hơn nhiều so với chi phí đơn vị trên mỗi giờ máy.
Tình huống 2: Ngân hàng chọn hybrid vì tuân thủ
Một ngân hàng thương mại cổ phần hạng trung tại Việt Nam muốn hiện đại hóa hệ thống. Họ có một core banking chạy on-prem đã ổn định nhiều năm, nhưng muốn xây các ứng dụng mobile banking mới với trải nghiệm hiện đại.
Họ không thể đẩy toàn bộ lên cloud, vì dữ liệu giao dịch tài chính và thông tin khách hàng phải tuân thủ quy định của Ngân hàng Nhà nước về lưu trữ trong nước. Nhưng họ cũng không muốn tự xây toàn bộ hạ tầng cho app mobile vốn có lượng người dùng tăng nhanh và cần triển khai tính năng liên tục.
Giải pháp hybrid: core banking và cơ sở dữ liệu khách hàng ở lại on-prem trong data center đạt chuẩn của họ; lớp API gateway, dịch vụ thông báo đẩy, và phần xử lý hình ảnh eKYC được đặt trên cloud của một nhà cung cấp có region tại Việt Nam. Hai bên kết nối qua đường truyền riêng bảo mật.
Bài học rút ra: Quyết định cloud vs on-prem hiếm khi là "tất cả hoặc không gì cả". Với doanh nghiệp bị ràng buộc bởi quy định pháp lý, hybrid cho phép tận dụng ưu điểm của cloud ở những nơi được phép, đồng thời giữ dữ liệu nhạy cảm dưới sự kiểm soát trực tiếp. Ranh giới phân chia phải dựa trên phân loại dữ liệu, không phải sở thích công nghệ.
Tình huống 3: Công ty SaaS "hồi hương" khỏi cloud vì chi phí
Một công ty SaaS chuyên xử lý và mã hóa video cho các nền tảng học trực tuyến, ban đầu chạy hoàn toàn trên AWS. Khi lượng khách tăng, họ nhận ra workload mã hóa video của mình chạy gần như liên tục 24/7 với công suất cao — đây là loại workload ổn định, dự đoán được, và ngốn rất nhiều CPU.
Hóa đơn AWS của họ leo lên khoảng 45.000 USD mỗi tháng, phần lớn đến từ các máy chủ tính toán chạy không nghỉ và chi phí băng thông truyền dữ liệu ra ngoài (egress) đắt đỏ. Sau khi tính toán TCO, họ chuyển phần mã hóa video sang một cụm máy chủ tự vận hành thuê chỗ đặt tại data center, chỉ giữ lại phần API và giao diện người dùng trên cloud. Chi phí phần tính toán giảm khoảng 60%, dù họ phải tuyển thêm một kỹ sư hạ tầng.
Đây là một phiên bản thu nhỏ của câu chuyện nổi tiếng khi công ty đứng sau Basecamp rời cloud và tiết kiệm hàng triệu đô mỗi năm cho workload ổn định của họ.
Bài học rút ra: Cloud rẻ khi bạn tận dụng được tính đàn hồi. Nhưng với workload chạy đều đặn ở công suất cao, mô hình trả tiền theo giờ của cloud trở thành gánh nặng, và chi phí egress dễ bị bỏ sót khi ước tính. Quyết định không phải là "một lần rồi thôi" — bạn nên tái đánh giá khi quy mô và đặc tính workload thay đổi.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi phải ra quyết định cloud vs on-prem cho một hệ thống cụ thể.
Bước 1 — Phân loại workload. Trả lời: workload này ổn định hay biến động? Chạy liên tục hay theo đợt? Cần co giãn nhanh không? Workload biến động mạnh nghiêng về cloud; workload ổn định công suất cao nghiêng về on-prem.
Bước 2 — Rà soát ràng buộc tuân thủ và chủ quyền dữ liệu. Dữ liệu có chứa thông tin cá nhân, tài chính, y tế không? Có quy định nào bắt buộc lưu trong nước hoặc dưới sự kiểm soát trực tiếp không? Nếu có, phần dữ liệu đó có thể buộc phải on-prem hoặc dùng cloud có region tại Việt Nam.
Bước 3 — Tính TCO cho cả hai phương án trong 3 năm. Với cloud: cộng chi phí compute, storage, egress băng thông, và các dịch vụ managed. Với on-prem: cộng chi phí phần cứng khấu hao, điện, chỗ đặt máy, giấy phép phần mềm, và đặc biệt là chi phí nhân sự vận hành. Đừng quên egress ở phía cloud và nhân sự ở phía on-prem — đây là hai khoản hay bị bỏ sót nhất.
Bước 4 — Đánh giá năng lực đội ngũ. Bạn có người biết vận hành Kubernetes, mạng, lưu trữ, bảo mật ở mức on-prem không? Nếu không và không định tuyển, cloud với dịch vụ managed sẽ an toàn hơn.
Bước 5 — Cân nhắc tốc độ ra thị trường. Nếu bạn đang chạy đua để ra mắt sản phẩm, cloud giúp bạn khởi động nhanh hơn nhiều. Tối ưu chi phí bằng on-prem là bài toán để dành cho khi đã có quy mô ổn định.
Bước 6 — Ghi lại quyết định dưới dạng ADR. Viết rõ bối cảnh, các phương án đã cân nhắc, tiêu chí đánh giá, và lý do chọn phương án cuối cùng. Điều này giúp bạn và những người kế nhiệm hiểu được vì sao đã chọn như vậy, và biết khi nào nên tái đánh giá.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ so sánh giá thuê máy, quên chi phí ẩn. Người ta thường lấy giá một instance EC2 so với giá một máy chủ vật lý rồi kết luận. Nhưng bức tranh đầy đủ phải bao gồm: chi phí egress (rất đắt trên cloud), chi phí nhân sự vận hành (rất đáng kể với on-prem), chi phí đào tạo, và chi phí downtime. Luôn tính TCO đầy đủ.
Lỗi 2 — Chọn theo trào lưu, không theo bối cảnh. "Ai cũng lên cloud nên chúng ta cũng phải lên" là lý do tệ. Quyết định kiến trúc phải xuất phát từ ràng buộc của chính bạn.
Lỗi 3 — Bỏ qua vendor lock-in. Nếu bạn xây toàn bộ hệ thống bằng các dịch vụ độc quyền của một nhà cung cấp (ví dụ dùng sâu vào một loại database serverless riêng), việc chuyển đi sau này sẽ rất tốn kém. Mẹo: với các thành phần cốt lõi, ưu tiên công nghệ mở (PostgreSQL, Kafka, Kubernetes) để giữ khả năng dịch chuyển.
Lỗi 4 — Quên chi phí egress khi thiết kế hệ thống nhiều dữ liệu. Với hệ thống truyền tải nhiều dữ liệu ra ngoài (video, file lớn), chi phí băng thông ra khỏi cloud có thể vượt cả chi phí tính toán. Ước tính khối lượng egress ngay từ đầu.
Mẹo — Đừng coi đây là quyết định vĩnh viễn. Đặt lịch tái đánh giá mỗi 12-18 tháng hoặc mỗi khi quy mô tăng đáng kể. Nhiều công ty bắt đầu bằng cloud để đi nhanh, rồi chuyển phần workload ổn định sang on-prem khi đã đủ lớn — và đó là một lộ trình hoàn toàn hợp lý.
Mẹo — Bắt đầu bằng hybrid nếu bạn phân vân. Không nhất thiết phải chọn cực đoan một bên. Đẩy phần biến động lên cloud, giữ phần nhạy cảm hoặc ổn định ở on-prem thường là điểm cân bằng thực tế.
Bài tập thực hành
Bài tập 1 — Phân loại workload. Cho ba hệ thống sau, hãy quyết định mỗi hệ thống nên đặt trên cloud, on-prem, hay hybrid, và giải thích bằng ít nhất hai tiêu chí: (a) Một website tin tức có lượng truy cập tăng đột biến khi có sự kiện lớn. (b) Một hệ thống lưu trữ hồ sơ bệnh án của bệnh viện. (c) Một dịch vụ render đồ họa 3D chạy liên tục 24/7 công suất cao.
Bài tập 2 — Tính TCO đơn giản. Giả sử bạn cần 10 máy chủ tương đương chạy 24/7 trong 3 năm. Trên cloud, mỗi máy tốn 200 USD/tháng. On-prem, mỗi máy tốn 4.000 USD mua đứt (khấu hao 3 năm) cộng 50 USD/tháng chi phí vận hành mỗi máy, cộng một kỹ sư hạ tầng 2.000 USD/tháng cho toàn cụm. Hãy tính tổng chi phí 3 năm cho từng phương án và cho biết phương án nào rẻ hơn. Sau đó thảo luận: kết quả sẽ thay đổi thế nào nếu workload chỉ chạy 8 giờ mỗi ngày?
Bài tập 3 — Viết ADR. Chọn một hệ thống bạn đang làm hoặc quen thuộc, và viết một ADR ngắn (khoảng một trang) cho quyết định cloud vs on-prem, bao gồm: bối cảnh, các phương án cân nhắc, tiêu chí đánh giá, quyết định, và điều kiện nào sẽ khiến bạn tái đánh giá.
Tóm tắt
Quyết định cloud vs on-prem không có đáp án đúng chung cho tất cả — nó phụ thuộc vào bối cảnh cụ thể của tổ chức bạn. Cloud tỏa sáng với tính co giãn đàn hồi, dịch vụ được quản lý giúp tiết kiệm công sức vận hành, phủ sóng toàn cầu nhanh chóng, và chi phí đầu tư ban đầu thấp — lý tưởng cho startup, sản phẩm non trẻ, và workload biến động. On-prem lại chiếm ưu thế khi workload ổn định công suất cao (rẻ hơn ở quy mô lớn), khi có ràng buộc tuân thủ và chủ quyền dữ liệu, khi cần độ trễ cực thấp, và khi muốn tránh phụ thuộc nhà cung cấp. Trong thực tế Việt Nam, hybrid thường là điểm cân bằng, đặc biệt trong ngành tài chính và viễn thông.
Khi ra quyết định, hãy đi qua sáu bước: phân loại workload, rà soát tuân thủ, tính TCO đầy đủ trong 3 năm (nhớ egress và nhân sự vận hành), đánh giá năng lực đội ngũ, cân nhắc tốc độ ra thị trường, và ghi lại thành ADR. Tránh những lỗi kinh điển như chỉ so giá thuê máy, chạy theo trào lưu, và bỏ quên vendor lock-in cùng chi phí egress. Cuối cùng, hãy nhớ rằng đây không phải quyết định vĩnh viễn — hãy tái đánh giá định kỳ, vì phương án tối ưu hôm nay có thể không còn tối ưu khi quy mô của bạn thay đổi.