Mở đầu — vì sao bài này quan trọng
Ở bài trước, chúng ta đã phân biệt IaaS, PaaS và SaaS — tức là bạn mua dịch vụ cloud ở tầng nào. Nhưng còn một câu hỏi lớn không kém, thậm chí quyết định cả kiến trúc lẫn ngân sách của doanh nghiệp: hạ tầng đó đặt ở đâu và ai sở hữu nó?
Đây chính là câu chuyện của deployment models — mô hình triển khai. Nói cho dễ hiểu, cùng một dịch vụ email hay một hệ thống bán hàng, bạn có thể chạy nó trên hạ tầng dùng chung với hàng triệu người khác (Public Cloud), trên hạ tầng riêng chỉ mình bạn động vào (Private Cloud), kết hợp cả hai (Hybrid), hoặc trải ra nhiều nhà cung cấp cùng lúc (Multi-cloud).
Vì sao một mentor bắt bạn phải nắm chắc phần này ngay từ đầu? Bởi vì trong thực tế đi làm, câu hỏi "nên dùng Public hay Private?" không phải là câu hỏi kỹ thuật thuần túy — nó dính đến chi phí, tính tuân thủ pháp luật (đặc biệt với ngành ngân hàng, y tế, chính phủ ở Việt Nam), tốc độ ra thị trường và cả rủi ro bị "khóa chân" vào một nhà cung cấp. Một kiến trúc sư chọn sai mô hình triển khai có thể khiến công ty tốn thêm hàng tỷ đồng mỗi năm, hoặc tệ hơn, vi phạm quy định về lưu trú dữ liệu. Hiểu đúng 4 mô hình này giúp bạn nói chuyện tự tin với sếp, với khách hàng và với đội security.
Khái niệm cốt lõi
Public Cloud — hạ tầng dùng chung
Public Cloud là mô hình mà nhà cung cấp (AWS, Google Cloud, Azure, hay ở Việt Nam là VNG Cloud, FPT Cloud) sở hữu toàn bộ trung tâm dữ liệu, phần cứng, mạng lưới, và cho nhiều khách hàng khác nhau thuê chung trên cùng hạ tầng vật lý đó. Người ta gọi tính chất này là multi-tenant — nhiều "người thuê" cùng ở trong một tòa nhà, nhưng mỗi người có phòng riêng được cô lập bằng công nghệ ảo hóa.
Điểm mạnh của Public Cloud:
- Không tốn chi phí đầu tư ban đầu (CapEx): bạn không mua server, chỉ trả tiền theo mức sử dụng (pay-as-you-go).
- Co giãn gần như vô hạn: cần 100 server trong ngày Black Friday rồi hôm sau trả lại 90 cái — làm được trong vài phút.
- Triển khai nhanh: mở tài khoản là dùng được ngay, không chờ mua và lắp đặt phần cứng.
Private Cloud — hạ tầng riêng
Private Cloud là hạ tầng cloud dành riêng cho một tổ chức duy nhất (single-tenant). Nó vẫn có các đặc tính của cloud — tự phục vụ, co giãn, ảo hóa — nhưng không chia sẻ với ai khác. Private Cloud có thể đặt ngay trong data center của doanh nghiệp (on-premises), hoặc thuê một nhà cung cấp dựng riêng cho bạn (hosted private cloud).
Vì sao người ta chấp nhận tốn kém hơn để làm Private?
- Kiểm soát và bảo mật tối đa: phù hợp dữ liệu nhạy cảm — hồ sơ bệnh án, dữ liệu giao dịch ngân hàng.
- Tuân thủ quy định: nhiều ngành ở Việt Nam yêu cầu dữ liệu phải nằm trong nước và trong hạ tầng do doanh nghiệp kiểm soát.
- Hiệu năng ổn định, có thể tùy biến sâu phần cứng cho những workload đặc thù.
Hybrid Cloud — kết hợp Public và Private
Hybrid Cloud là mô hình kết nối Public và Private lại với nhau thành một môi trường vận hành thống nhất, cho phép dữ liệu và ứng dụng di chuyển giữa hai bên. Đây không phải là "dùng cả hai một cách rời rạc" — điểm mấu chốt là chúng được nối liền bằng đường truyền riêng (Direct Connect, VPN) và quản lý như một hệ thống.
Ý tưởng điển hình: giữ những gì nhạy cảm và ổn định ở Private, đẩy những gì cần co giãn hoặc thử nghiệm sang Public. Một mô hình con nổi tiếng là cloud bursting — chạy bình thường trên Private, khi tải tăng đột biến thì "tràn" phần dư sang Public để không phải mua thừa phần cứng.
Multi-cloud — nhiều nhà cung cấp Public cùng lúc
Multi-cloud nghĩa là dùng dịch vụ từ nhiều nhà cung cấp Public khác nhau — ví dụ vừa AWS vừa Google Cloud, hoặc AWS cho phần chính và Azure cho một số dịch vụ AI. Khác với Hybrid (Public + Private), Multi-cloud tập trung vào việc trải trên nhiều Public cloud.
Lý do phổ biến để làm Multi-cloud:
- Tránh vendor lock-in — không phụ thuộc số phận vào một nhà cung cấp.
- Chọn thứ tốt nhất ở mỗi nơi (best-of-breed) — ví dụ dùng BigQuery của Google cho phân tích dữ liệu, nhưng dùng hạ tầng compute của AWS.
- Tăng độ sẵn sàng — nếu một provider gặp sự cố vùng, hệ thống vẫn còn provider kia.
- Đàm phán giá tốt hơn khi không bị khóa vào một bên.
Bảng so sánh nhanh
| Mô hình | Ai dùng chung hạ tầng | Kiểm soát | Chi phí ban đầu | Use case điển hình |
|---|---|---|---|---|
| Public | Nhiều khách hàng (multi-tenant) | Thấp | Gần như 0 (OpEx) | Startup, web/app co giãn nhanh, môi trường test |
| Private | Một tổ chức (single-tenant) | Cao nhất | Lớn (CapEx) | Ngân hàng, y tế, dữ liệu nhạy cảm, tuân thủ |
| Hybrid | Kết hợp cả hai | Trung bình–cao | Trung bình | Doanh nghiệp có hệ thống cũ + cần co giãn |
| Multi-cloud | Nhiều Public providers | Trung bình | Thấp–trung bình | Tránh lock-in, best-of-breed, độ sẵn sàng cao |
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử chọn Public cho mùa cao điểm
Hãy hình dung một sàn thương mại điện tử tầm trung ở Việt Nam — gọi là ShopViet — có khoảng 500.000 người dùng hoạt động hàng tháng. Ngày thường, hệ thống chỉ cần khoảng 20 server để chạy mượt. Nhưng vào các đợt sale lớn như 11/11 hay 12/12, lượng truy cập tăng gấp 8–10 lần trong vài giờ đồng hồ.
Nếu ShopViet chọn Private Cloud, họ buộc phải mua và duy trì đủ 150–200 server để "gồng" được ngày cao điểm — trong khi 360 ngày còn lại trong năm, phần lớn số server đó nằm không, đốt tiền điện và khấu hao vô ích.
ShopViet chọn Public Cloud với auto-scaling: ngày thường chạy 20 server, đến giờ cao điểm hệ thống tự nâng lên 180 server, sale xong tự hạ về. Họ chỉ trả tiền cho phần dùng thêm trong vài giờ đó. Ước tính chi phí hạ tầng của họ giảm khoảng 60% so với việc tự đầu tư phần cứng cho công suất đỉnh.
Bài học: Khi tải của bạn biến động mạnh và khó đoán, Public Cloud với khả năng co giãn theo nhu cầu gần như luôn là lựa chọn kinh tế nhất. Đừng mua phần cứng cho ngày đông nhất trong năm.
Tình huống 2: Ngân hàng buộc phải dùng Private (và Hybrid) vì tuân thủ
Một ngân hàng thương mại cỡ vừa ở Việt Nam — gọi là Bank An Tín — muốn hiện đại hóa hệ thống. Nhưng dữ liệu cốt lõi (core banking, thông tin tài khoản, lịch sử giao dịch) chịu sự giám sát chặt của Ngân hàng Nhà nước và các quy định về bảo vệ dữ liệu cá nhân. Những dữ liệu này không thể tùy tiện đặt trên hạ tầng dùng chung ở nước ngoài.
Bank An Tín giữ core banking trên Private Cloud đặt tại data center trong nước, kiểm soát hoàn toàn về vật lý lẫn truy cập. Nhưng họ lại có một ứng dụng mobile banking với những đợt khuyến mãi khiến lượng truy cập tăng vọt, cùng một chatbot chăm sóc khách hàng dùng AI. Đầu tư Private cho những phần này thì lãng phí và chậm.
Giải pháp là Hybrid Cloud: phần lõi nhạy cảm ở Private, còn tầng ứng dụng khách hàng (mobile app, chatbot, các dịch vụ phân tích không chứa dữ liệu định danh trực tiếp) chạy trên Public Cloud, nối với nhau qua đường truyền riêng được mã hóa. Dữ liệu nhạy cảm không rời khỏi Private, nhưng công ty vẫn tận dụng được sự linh hoạt của Public.
Bài học: Trong các ngành bị quản lý chặt (tài chính, y tế, chính phủ), mô hình triển khai không phải do kỹ thuật quyết định mà do pháp luật và tuân thủ quyết định trước. Hybrid thường là câu trả lời để vừa an toàn pháp lý vừa không đánh mất sự nhanh nhẹn.
Tình huống 3: Công ty SaaS chọn Multi-cloud để tránh "bỏ trứng một giỏ"
Một công ty SaaS Đông Nam Á cung cấp nền tảng quản lý nhân sự — gọi là PeopleFlow — phục vụ khách hàng ở nhiều quốc gia. Ban đầu họ chạy toàn bộ trên AWS. Nhưng có hai vấn đề nảy sinh: một khách hàng lớn ở khu vực yêu cầu dữ liệu phải nằm trên hạ tầng có hiện diện tại quốc gia của họ mà AWS chưa phủ tốt, và ban lãnh đạo lo ngại việc phụ thuộc 100% vào một nhà cung cấp sẽ yếu thế khi đàm phán gia hạn hợp đồng.
PeopleFlow chuyển sang Multi-cloud: giữ phần lõi trên AWS, nhưng triển khai thêm một số cụm trên Google Cloud để phục vụ khu vực mà Google có ưu thế, đồng thời dùng các dịch vụ phân tích dữ liệu của Google vốn mạnh hơn cho nhu cầu của họ. Kết quả là họ đáp ứng được yêu cầu về vị trí dữ liệu, giảm rủi ro phụ thuộc, và có thêm sức mạnh khi thương lượng giá với cả hai bên.
Tuy nhiên, họ cũng thấm cái giá: đội DevOps phải học và vận hành hai hệ IAM khác nhau, hai kiểu mạng khác nhau, và việc theo dõi chi phí trở nên rối rắm cho đến khi họ đầu tư công cụ quản lý tập trung.
Bài học: Multi-cloud mang lại tự do và độ bền, nhưng chỉ nên chọn khi bạn có lý do rõ ràng (tránh lock-in, yêu cầu vị trí dữ liệu, best-of-breed) và có đủ năng lực đội ngũ để gánh độ phức tạp tăng thêm. Đừng làm Multi-cloud chỉ vì thấy "sang".
Hướng dẫn từng bước
Đây là quy trình tư duy giúp bạn chọn đúng mô hình triển khai cho một dự án cụ thể:
- Xác định yêu cầu tuân thủ và vị trí dữ liệu trước tiên. Hỏi ngay: Dữ liệu này có bị luật ràng buộc phải nằm trong nước không? Có phải dữ liệu cá nhân/nhạy cảm không? Nếu câu trả lời là "có ràng buộc chặt", Private hoặc Hybrid gần như là bắt buộc — bước này quyết định phần lớn hướng đi.
- Đánh giá đặc tính tải (workload). Tải ổn định hay biến động mạnh? Có mùa cao điểm không? Tải biến động mạnh → nghiêng về Public để tận dụng co giãn. Tải ổn định, đều đặn, dài hạn → Private có thể rẻ hơn về lâu dài.
- Cân đối chi phí CapEx và OpEx. Doanh nghiệp có sẵn vốn để đầu tư phần cứng (CapEx) và muốn kiểm soát dài hạn không? Hay muốn trả theo tháng, không đọng vốn (OpEx)? Startup thường chọn OpEx (Public), doanh nghiệp lớn có data center sẵn có thể tận dụng Private.
- Đánh giá năng lực đội ngũ. Multi-cloud và Hybrid đòi hỏi kỹ năng vận hành cao hơn nhiều. Nếu đội bạn còn nhỏ và chưa vững, đừng vội nhảy vào Multi-cloud — bắt đầu với một Public cloud cho gọn.
- Kiểm tra nhu cầu tránh lock-in và độ sẵn sàng. Nếu việc "chết theo" một nhà cung cấp là rủi ro không chấp nhận được với business của bạn, hãy tính đến Multi-cloud — nhưng nhớ chuẩn bị công cụ và quy trình quản lý tập trung.
- Chọn mô hình, rồi thiết kế đường kết nối và ranh giới dữ liệu. Nếu là Hybrid/Multi-cloud, xác định rõ dữ liệu nào ở đâu, luồng dữ liệu di chuyển ra sao, và kết nối bằng gì (VPN, Direct Connect). Vẽ sơ đồ trước khi build.
- Đặt cơ chế giám sát chi phí và tuân thủ ngay từ đầu. Bất kể mô hình nào, hãy gắn tagging, budget alert và kiểm tra tuân thủ định kỳ. Đừng để đến khi nhận hóa đơn mới giật mình.
Lỗi thường gặp & mẹo
- Nhầm Hybrid với Multi-cloud. Rất nhiều người mới lẫn lộn. Nhớ đơn giản: Hybrid = Public + Private nối liền; Multi-cloud = nhiều Public providers. Một hệ thống có thể vừa Hybrid vừa Multi-cloud, nhưng hai khái niệm không đồng nghĩa.
- Tưởng Public Cloud thì luôn rẻ hơn. Không hẳn. Với tải nặng, ổn định và chạy 24/7 trong nhiều năm, tổng chi phí Public có thể vượt Private. Public rẻ khi bạn tận dụng được tính co giãn; nếu bật server chạy full công suất suốt ngày đêm mà không tối ưu, hóa đơn sẽ đắng.
- Nghĩ Private Cloud là "an toàn tuyệt đối". Đặt trong nhà không tự động an toàn. Nếu đội bạn cấu hình sai, không vá lỗi, không phân quyền chặt thì Private còn rủi ro hơn Public được cấu hình tốt. An toàn đến từ vận hành, không đến từ vị trí.
- Nhảy vào Multi-cloud quá sớm. Đây là cái bẫy "sang chảnh". Multi-cloud nhân đôi độ phức tạp về mạng, IAM, chi phí và kỹ năng. Chỉ làm khi có lý do kinh doanh rõ ràng và đội đủ trưởng thành.
- Mẹo — bắt đầu đơn giản, mở rộng sau. Phần lớn dự án nên khởi đầu bằng một Public cloud. Khi business chín muồi và có nhu cầu thực sự (tuân thủ, lock-in, best-of-breed) mới tiến hóa lên Hybrid hoặc Multi-cloud. Kiến trúc nên đi theo nhu cầu, không đi trước nhu cầu.
- Mẹo — luôn để "cửa thoát" trong thiết kế. Ngay cả khi dùng một Public cloud, hãy ưu tiên công nghệ chuẩn mở (container, Kubernetes, PostgreSQL...) thay vì bám chặt dịch vụ độc quyền. Điều này giúp bạn dễ chuyển sang Multi-cloud sau này nếu cần.
Bài tập thực hành
- Phân loại tình huống. Với mỗi tổ chức sau, hãy chọn mô hình triển khai phù hợp nhất và giải thích trong 2–3 câu:
- Phân tích chi phí. Giả sử hệ thống của bạn cần 20 server chạy quanh năm và tăng lên 150 server chỉ trong 5 ngày cao điểm mỗi năm. Hãy lập luận: Public, Private hay Hybrid tiết kiệm hơn? Vì sao? (Gợi ý: tách phần tải nền và phần tải đỉnh ra để so sánh.)
- Vẽ sơ đồ Hybrid. Cho một ngân hàng có: core banking (nhạy cảm), mobile app (tải biến động), hệ thống phân tích marketing (không chứa dữ liệu định danh). Hãy vẽ tay sơ đồ đặt mỗi thành phần ở Public hay Private, và chỉ ra đường kết nối giữa hai bên.
- Tự phản biện Multi-cloud. Viết ra 3 lợi ích và 3 cái giá của Multi-cloud cho một công ty giả định của bạn, rồi kết luận: bạn có nên làm Multi-cloud lúc này không, và điều kiện nào sẽ khiến bạn đổi ý?
Tóm tắt
- Có 4 mô hình triển khai cloud: Public (hạ tầng dùng chung, co giãn nhanh, chi phí ban đầu thấp), Private (hạ tầng riêng, kiểm soát và bảo mật cao, tốn kém hơn), Hybrid (kết hợp Public + Private nối liền), và Multi-cloud (dùng nhiều Public providers cùng lúc).
- Public hợp với tải biến động, startup, môi trường thử nghiệm. Private hợp với dữ liệu nhạy cảm và ngành bị quản lý chặt. Hybrid cân bằng giữa tuân thủ và linh hoạt. Multi-cloud để tránh lock-in, chọn best-of-breed và tăng độ sẵn sàng.
- Yếu tố quyết định lớn nhất thường là tuân thủ và vị trí dữ liệu, sau đó mới đến đặc tính tải, chi phí và năng lực đội ngũ.
- Đừng nhầm Hybrid (có Private) với Multi-cloud (chỉ Public). Đừng tưởng Public luôn rẻ hay Private luôn an toàn. Đừng nhảy vào Multi-cloud khi chưa có lý do và năng lực rõ ràng.
- Nguyên tắc vàng của một mentor: bắt đầu đơn giản, tiến hóa theo nhu cầu, và luôn thiết kế sao cho có "cửa thoát" khỏi sự phụ thuộc.