Service Model và Deployment Model của điện toán đám mây
1. Tổng quan
A. Định nghĩa
Mô hình dịch vụ (Service Model) phân loại đám mây trừu tượng hóa và cung cấp tài nguyên điện toán tới mức nào (IaaS·PaaS·SaaS), còn mô hình triển khai (Deployment Model) phân loại ai sở hữu·vận hành hạ tầng đám mây và cung cấp cho ai (công cộng·riêng·lai·cộng đồng) — đây là hai trục phân loại. Trong định nghĩa đám mây NIST SP 800-145 của Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ, hai mô hình này cùng với 5 đặc tính thiết yếu tạo nên bộ khung định nghĩa đám mây.
Hai mô hình trả lời những câu hỏi khác nhau. Mô hình dịch vụ quyết định vấn đề trừu tượng hóa·trách nhiệm "thuê cái gì, và tự mình quản lý cái gì", còn mô hình triển khai quyết định vấn đề sở hữu·kiểm soát "đặt nó ở đâu, và nắm quyền kiểm soát đến mức nào". Do đó, việc áp dụng đám mây thực tế là quyết định tổ hợp bằng cách nhân hai trục này (ví dụ công cộng×SaaS, riêng×IaaS), và chọn tổ hợp nào sẽ chi phối sự cân bằng giữa chi phí·bảo mật·tính linh hoạt.
B. Bối cảnh ra đời và sự cần thiết
Trước khi có đám mây, để đưa dịch vụ lên, doanh nghiệp phải tự mua máy chủ (chi phí vốn·CAPEX), chịu đựng nhiều tháng mua sắm·lắp đặt, và dự trữ tài nguyên dư thừa (Over-provisioning) theo tải tối đa. Cách này có giới hạn cấu trúc: chi phí ban đầu lớn, phản ứng chậm với biến động nhu cầu và lãng phí tài nguyên nhàn rỗi. Đám mây chuyển điều này sang mô hình theo yêu cầu (On-demand)·trả theo mức dùng (Pay-as-you-go)·mở rộng co giãn (Elasticity), biến chi phí vốn thành chi phí vận hành (OPEX) và cho phép thuê ngay chỉ đúng lượng cần.
Khi đó nảy sinh nhu cầu sắp xếp bằng ngôn ngữ chuẩn hai câu hỏi "thuê tới mức nào (mô hình dịch vụ)" và "đặt ở đâu (mô hình triển khai)", và khi NIST định nghĩa chúng, hệ thống phân loại thông dụng ngày nay được xác lập. Chìa khóa cốt lõi để hiểu hai mô hình này là mô hình trách nhiệm chia sẻ (Shared Responsibility Model). Trong đám mây, nhà cung cấp (CSP) và người dùng chia nhau trách nhiệm quản lý·bảo mật, và đường ranh giới trách nhiệm dịch chuyển tùy theo mô hình dịch vụ được chọn. Tức là chọn mô hình chính là hành vi xác định "tôi quản lý gì và chịu trách nhiệm về điều gì".
2. Service Model (IaaS·PaaS·SaaS)
flowchart TB
I["IaaS<br/>Máy chủ·lưu trữ·mạng"] --> P["PaaS<br/>Runtime·middleware·DB"] --> S["SaaS<br/>Ứng dụng hoàn chỉnh"]
style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
Ba mô hình thường trở nên trực quan khi được ví như "các cách ăn pizza". Phép ví này có hiệu lực vì khác biệt bản chất của ba mô hình nằm ở đường phân chia trách nhiệm quản lý "tôi làm tới đâu và người khác làm từ đâu".
A. IaaS (Infrastructure as a Service). Là cách thuê bột mì·lò nướng (máy chủ ảo·lưu trữ·mạng) rồi tự nhào bột từ đầu. Mức tự do cao nhất nhưng người dùng phải tự cài đặt·vá lỗi·vận hành toàn bộ OS·middleware·runtime·ứng dụng. Tiêu biểu là AWS EC2, Google Compute Engine — nơi người dùng tự khởi chạy máy ảo và cài OS. IaaS thường được dùng làm điểm vào đầu tiên trong di chuyển kiểu "nâng và chuyển (Lift & Shift)" — đưa nguyên ứng dụng cũ lên đám mây.
B. PaaS (Platform as a Service). Là cách nhận đế bánh bán thành phẩm (nền tảng phát triển·thực thi) rồi chỉ thêm topping (mã ứng dụng). Lập trình viên được giải phóng khỏi các việc vặt hạ tầng như vá OS·cấu hình middleware·quản lý dung lượng và chỉ tập trung vào mã. Google App Engine, Heroku, AWS Elastic Beanstalk v.v. thuộc nhóm này; gần đây sự trừu tượng hóa tiến xa hơn với container·serverless (FaaS, ví dụ AWS Lambda), tiến hóa thành dạng "hàm chỉ chạy khi có sự kiện và chỉ tính phí đúng lượng đó".
C. SaaS (Software as a Service). Là cách được giao tận nơi chiếc pizza hoàn chỉnh (Gmail·Salesforce). Người dùng không cài đặt·vận hành phần mềm mà truy cập qua trình duyệt web, chỉ quản lý dữ liệu·cấu hình. Triển khai nhanh nhất và gánh nặng quản lý tối thiểu, nhưng ngược lại, mức tự do tùy biến và quyền kiểm soát bảo mật bị hạn chế nhất. Ngày nay phần lớn công cụ cộng tác·CRM·nhân sự mà doanh nghiệp dùng là SaaS.
Gần đây, FaaS (Function as a Service, serverless) và CaaS (Container as a Service) chen vào giữa ba tầng này khiến phổ trở nên dày đặc hơn. FaaS trừu tượng hóa PaaS tới cực điểm: không "luôn bật" máy chủ mà chỉ chạy hàm vào thời điểm có yêu cầu·sự kiện và tính phí đúng thời gian chạy. Khi nhàn rỗi chi phí tiến về 0 nên rất kinh tế cho tải công việc gián đoạn·theo sự kiện, nhưng cái giá là độ trễ khởi chạy (Cold Start) và phụ thuộc nhà cung cấp tăng. Như vậy, trục IaaS→SaaS nên được hiểu không phải là 3 bậc rời rạc mà là một phổ liên tục trong đó "phần tôi quản lý" giảm dần — cách hiểu này sát với thực tiễn hơn.
Tóm lại, càng đi lên (IaaS→SaaS) thì sự tiện lợi·mức trừu tượng·tốc độ triển khai càng cao, còn gánh nặng quản lý và mức tự do kiểm soát càng thấp. Sự dịch chuyển tầng này chính là sự dịch chuyển ranh giới của mô hình trách nhiệm chia sẻ sẽ xem ở mục tiếp theo.
| Mô hình | Phạm vi cung cấp | Vùng người dùng quản lý | Ví dụ tiêu biểu |
|---|---|---|---|
| IaaS | Hạ tầng ảo (máy chủ·lưu trữ·mạng) | OS·middleware·runtime·ứng dụng·dữ liệu | AWS EC2, GCE, Azure VM |
| PaaS | Nền tảng phát triển·thực thi (runtime·DB·middleware) | Ứng dụng·dữ liệu | App Engine, Heroku, Beanstalk |
| SaaS | Ứng dụng hoàn chỉnh | Chỉ dữ liệu·cấu hình·tài khoản người dùng | Gmail, Salesforce, M365 |
3. Mô hình trách nhiệm chia sẻ — cốt lõi nối hai mô hình
flowchart TB
subgraph LEG["Chủ thể quản lý"]
direction LR
C["■ Trách nhiệm CSP"]
U["□ Trách nhiệm người dùng"]
end
subgraph IAAS["IaaS"]
IA["Ứng dụng·dữ liệu·runtime·middleware·OS = người dùng<br/>Ảo hóa·máy chủ·lưu trữ·mạng·vật lý = CSP"]
end
subgraph PAAS["PaaS"]
PA["Ứng dụng·dữ liệu = người dùng<br/>Runtime·middleware·OS trở xuống = CSP"]
end
subgraph SAAS["SaaS"]
SA["Dữ liệu·tài khoản·quyền truy cập = người dùng<br/>Toàn bộ từ ứng dụng trở xuống = CSP"]
end
IAAS --> PAAS --> SAAS
style SAAS fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
Mô hình trách nhiệm chia sẻ là cây cầu nối mô hình dịch vụ và mô hình triển khai. Nguyên tắc là "bảo mật của chính đám mây (Security of the Cloud) do CSP, bảo mật bên trong đám mây (Security in the Cloud) do người dùng". Cơ sở vật chất·phần cứng·tầng ảo hóa trong mô hình nào cũng do CSP chịu trách nhiệm, nhưng ranh giới trách nhiệm của các tầng phía trên dịch chuyển lên xuống tùy mô hình dịch vụ.
Trong IaaS, phần lớn — từ vá OS, cấu hình tường lửa·nhóm bảo mật đến quản lý lỗ hổng middleware — là phần của người dùng. Lên đến PaaS, việc quản lý OS·runtime chuyển sang CSP nên người dùng chỉ cần tập trung vào mã ứng dụng và bảo mật dữ liệu. Trong SaaS, CSP chịu trách nhiệm tới cả ứng dụng nên người dùng chỉ còn lại quản lý dữ liệu·tài khoản·quyền truy cập. Tuy nhiên điều quan trọng là chính "phần còn lại" này lại là nguyên nhân cốt lõi của sự cố. Phần lớn các vụ xâm phạm đám mây thực tế không xảy ra do hạ tầng của CSP bị thủng, mà ở vùng người dùng chịu trách nhiệm — cấu hình công khai sai S3 bucket, quyền IAM quá mức, chiếm đoạt tài khoản. Dù dùng mô hình nào, nếu không nhận thức chính xác "ranh giới mình chịu trách nhiệm" thì sẽ phát sinh lỗ hổng bảo mật.
| Tầng | IaaS | PaaS | SaaS |
|---|---|---|---|
| Dữ liệu·tài khoản·quyền truy cập | Người dùng | Người dùng | Người dùng |
| Ứng dụng | Người dùng | Người dùng | CSP |
| Runtime·middleware·OS | Người dùng | CSP | CSP |
| Ảo hóa·máy chủ·lưu trữ·mạng·vật lý | CSP | CSP | CSP |
4. Deployment Model (mô hình triển khai)
Mô hình triển khai được quyết định bởi sự đánh đổi giữa bảo mật·kiểm soát và chi phí·khả năng mở rộng. Nếu không hiểu sự đánh đổi này mà mặc định kết luận "công cộng thì rẻ" hay "riêng thì an toàn", rất dễ đưa ra lựa chọn không phù hợp với tải công việc thực tế.
A. Đám mây công cộng. CSP cung cấp chia sẻ tài nguyên cho số đông không xác định. Nhờ lợi thế kinh tế theo quy mô nên rẻ, mở rộng gần như vô hạn và có thể bắt đầu ngay mà không cần đầu tư ban đầu. Tuy nhiên, vì tài nguyên được chia sẻ với các tenant khác (multi-tenancy), việc kiểm soát ở mức cách ly vật lý hay đáp ứng quy định đặc thù bị hạn chế. Phù hợp với dịch vụ web biến động lớn, startup, môi trường phát triển·kiểm thử.
B. Đám mây riêng. Được xây dựng·vận hành dành riêng cho một tổ chức. Vì độc chiếm tài nguyên nên mạnh về bảo mật·kiểm soát·tuân thủ quy định và dễ dự đoán hiệu năng, nhưng phải tự trang bị và vận hành hạ tầng nên chi phí cao và tính co giãn tương đối thấp. Được chọn cho các lĩnh vực có chủ quyền dữ liệu·quy định nghiêm ngặt như hệ thống lõi tài chính, quốc phòng·y tế.
C. Đám mây lai. Kết hợp công cộng và riêng, liên kết chúng bằng điều phối (orchestration). Là dạng chủ đạo mà đa số doanh nghiệp thực tế áp dụng: đặt dữ liệu nhạy cảm·hệ thống lõi ở đám mây riêng, đặt tải công việc biến động lớn·dịch vụ đối ngoại ở đám mây công cộng để tận dụng ưu điểm của mỗi bên. Mẫu sử dụng tiêu biểu là bùng nổ đám mây (Cloud Bursting) — bình thường vận hành bằng đám mây riêng, khi lưu lượng tăng đột biến thì chuyển sang công cộng.
D. Đám mây cộng đồng. Nhiều tổ chức có chung yêu cầu quy định·bảo mật như tài chính·công cùng xây dựng và sử dụng. Đám mây dành riêng cho cơ quan công quyền tại Hàn Quốc (ví dụ vùng dành cho hành chính·công) hay hạ tầng chung của ngành tài chính gần với phạm trù này. Ưu điểm là giảm chi phí nhờ cùng gánh vác mà vẫn đồng thời thỏa mãn quy định chung.
| Mô hình | Hình thức sở hữu·cung cấp | Ưu điểm | Giới hạn | Trường hợp phù hợp |
|---|---|---|---|---|
| Công cộng | CSP cung cấp cho số đông không xác định | Chi phí thấp·mở rộng vô hạn·tức thời | Hạn chế kiểm soát·cách ly | Startup, dịch vụ web đối ngoại |
| Riêng | Dành riêng cho một tổ chức | Mạnh về bảo mật·kiểm soát·tuân thủ | Chi phí cao·co giãn thấp | Lõi tài chính, quốc phòng·y tế |
| Lai | Kết hợp công cộng+riêng | Linh hoạt, cách ly dữ liệu nhạy cảm | Phức tạp liên kết·vận hành | Chủ đạo ở doanh nghiệp lớn |
| Cộng đồng | Chia sẻ giữa các tổ chức cùng mối quan tâm | Chia sẻ quy định·tiêu chuẩn·chi phí | Cần điều phối giữa các tổ chức tham gia | Hạ tầng chung tài chính·công |
Hình dung sự đánh đổi của các mô hình triển khai bằng số liệu cụ thể sẽ dễ hiểu hơn. Ví dụ, giả sử một doanh nghiệp thương mại điện tử bình thường xử lý vài trăm đơn hàng mỗi giây nhưng trong đợt khuyến mãi lớn lại nhận lưu lượng tăng tức thời gấp hàng chục lần. Nếu chỉ dùng đám mây riêng, phải chuẩn bị trước hàng chục máy chủ theo đỉnh tải, và sau khi sự kiện kết thúc, phần lớn tài nguyên đó bị bỏ không, gây lãng phí. Nếu chỉ dùng công cộng, sẽ nảy sinh gánh nặng phải đưa cả dữ liệu nhạy cảm như thanh toán·thông tin cá nhân lên hạ tầng dùng chung. Đám mây lai giải quyết thế lưỡng nan này. Lõi thanh toán·thông tin hội viên đặt ở đám mây riêng để kiểm soát, còn giao diện web tra cứu sản phẩm·khuyến mãi đặt ở công cộng, chỉ mở rộng bằng auto-scaling khi có sự kiện (bùng nổ đám mây) rồi kết thúc để thu hồi tài nguyên. Kết quả là đạt được đồng thời "kiểm soát dữ liệu nhạy cảm" và "hiệu quả chi phí co giãn".
Sự đánh đổi này quan trọng trong thực tiễn vì lựa chọn mô hình triển khai không phải sở thích kỹ thuật đơn thuần mà là quyết định quản trị đồng thời phân định tổng chi phí sở hữu (TCO)·tuân thủ quy định·tính linh hoạt kinh doanh. Lựa chọn chấp nhận chi phí xây dựng ban đầu (CAPEX) để có quyền kiểm soát, hay chuyển sang chi phí vận hành (OPEX) để có sự linh hoạt, sẽ có đáp án khác nhau tùy cấu trúc tài chính và môi trường quy định của tổ chức.
5. Chuyên sâu — Tiến hóa sang đa đám mây·cloud native và xu hướng tại Hàn Quốc
Mô hình triển khai gần đây đang mở rộng vượt qua "lai" sang đa đám mây (Multi-cloud). Đa đám mây là chiến lược sử dụng đồng thời từ hai CSP công cộng trở lên (ví dụ AWS+Azure+GCP), được áp dụng nhằm giảm phụ thuộc vào một nhà cung cấp cụ thể (Vendor Lock-in), chọn dùng dịch vụ thế mạnh của từng CSP và nâng cao tính sẵn sàng khi một region gặp sự cố. Tuy nhiên, do phải quản lý tích hợp các nền tảng không đồng nhất, phát sinh những bài toán mới là quản trị·quản lý chi phí (FinOps)·tính nhất quán của chính sách bảo mật.
Về mặt mô hình dịch vụ, cloud native (Cloud Native) xoay quanh container·Kubernetes·serverless đang làm mờ ranh giới giữa IaaS và PaaS. Thông qua container, doanh nghiệp đồng thời có được tính khả chuyển của IaaS và năng suất của PaaS, hiện thực vận hành lai triển khai giống hệt nhau dù ở on-premises hay công cộng. Thêm vào đó, gần đây tải công việc AI tăng vọt khiến hình thức cung cấp tài nguyên GPU theo mức dùng lan rộng, và nhu cầu đám mây chủ quyền (Sovereign Cloud) — giữ dữ liệu trong một quốc gia·region cụ thể để đáp ứng quy định — cũng ngày càng lớn.
Mặt khác, ranh giới của mô hình triển khai cũng đang mờ đi. Với sự xuất hiện của đám mây phân tán (Distributed Cloud) như AWS Outposts·Azure Stack·Google Anthos — đưa hệ thống quản lý của CSP công cộng vào bên trong trung tâm dữ liệu của khách hàng — hình thức tận dụng "sự kiểm soát của đám mây riêng + sự tiện lợi vận hành của công cộng" tại một điểm đã lan rộng. Điều này cho thấy mô hình triển khai đang đa dạng hóa vượt qua phép nhị phân "đặt ở đâu" sang trục "quản lý từ đâu".
Tại Hàn Quốc, chuyển đổi đám mây khu vực công là sân khấu thực chiến của cuộc thảo luận này. Chính phủ vừa mở rộng việc hệ thống công sử dụng đám mây tư nhân, vừa cải tổ hệ thống kiểm định bảo mật CSAP (Chứng nhận bảo mật đám mây) thành chế độ phân cấp cao·trung·thấp, định hướng áp dụng các mô hình dịch vụ·triển khai khác nhau theo mức độ quan trọng của hệ thống. Chẳng hạn, hệ thống cấp thấp cho phép phân tách logic để mở rộng cánh cửa sử dụng công cộng·SaaS, còn cấp cao yêu cầu phân tách vật lý, về thực chất đòi hỏi hình thức chuyên dụng (riêng·cộng đồng). Đây là ví dụ nguyên lý "chọn tổ hợp mô hình dịch vụ×triển khai theo yêu cầu quy định" được hiện thực thành chính sách thực tế.
6. Những điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)
Cốt lõi là tổ hợp mô hình dịch vụ×triển khai phù hợp với đặc tính tải công việc. Không có đáp án duy nhất. Ngân hàng lõi xử lý thông tin nhạy cảm giữ quyền kiểm soát bằng riêng+IaaS, công cụ cộng tác tận dụng sự tiện lợi bằng công cộng+SaaS, dịch vụ web đối ngoại đạt sự linh hoạt bằng công cộng+PaaS — tức là cần chẩn đoán quy định·hiệu năng·tính biến động của từng hệ thống để thiết kế tổ hợp.
Hiểu mô hình trách nhiệm chia sẻ là điểm khởi đầu của bảo mật đám mây. Phần lớn sự cố đám mây (lỗi cấu hình·chiếm đoạt tài khoản·quyền quá mức) xảy ra ở vùng trách nhiệm của người dùng chứ không phải CSP. Nhận thức rõ "mình chịu trách nhiệm tới đâu" trong mô hình dịch vụ đã chọn và trang bị các biện pháp kiểm soát (IAM·mã hóa·kiểm tra cấu hình) phù hợp với ranh giới đó là điều cơ bản của bảo mật.
Quản lý phụ thuộc nhà cung cấp (Lock-in) và bảo đảm tính khả chuyển là nhiệm vụ chiến lược. Càng phụ thuộc sâu vào dịch vụ đặc thù của một CSP, chi phí chuyển đổi càng lớn. Cần chiến lược giảm phụ thuộc và bảo đảm năng lực đàm phán·tính sẵn sàng bằng thiết kế dựa trên container·API chuẩn·mã nguồn mở và kiến trúc đa đám mây.
Tối ưu chi phí (FinOps) là then chốt của vận hành bền vững. Trả theo mức dùng nếu bỏ mặc thì chi phí lại bùng nổ. Cần thực hành FinOps như thu hồi tài nguyên nhàn rỗi, tận dụng instance đặt trước·spot, auto-scaling, trực quan hóa mức sử dụng để biến "lợi ích của tính co giãn" thành tiết kiệm chi phí thực tế.
Tuân thủ quy định·chủ quyền dữ liệu chi phối lựa chọn mô hình triển khai. Luật Bảo vệ Thông tin Cá nhân·CSAP·yêu cầu phân tách mạng, hạn chế chuyển dữ liệu ra nước ngoài v.v. là những yếu tố mà thể chế chứ không phải công nghệ quyết định mô hình triển khai. An toàn hơn là tiếp cận theo trình tự: chẩn đoán yêu cầu quy định trước, rồi tổ hợp mô hình dịch vụ trong phạm vi thỏa mãn các yêu cầu đó.
Tài liệu tham khảo
- NIST SP 800-145, The NIST Definition of Cloud Computing — https://csrc.nist.gov/pubs/sp/800/145/final
- KISA, Chứng nhận bảo mật đám mây (CSAP) — https://isms.kisa.or.kr
- AWS, Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/
Tóm tắt một câu: Mô hình dịch vụ (IaaS·PaaS·SaaS) quy định mức trừu tượng hóa tài nguyên và phạm vi quản lý·trách nhiệm, còn mô hình triển khai (công cộng·riêng·lai·cộng đồng) quy định hình thức sở hữu·kiểm soát (NIST SP 800-145); hiểu mô hình trách nhiệm chia sẻ nối hai trục này và tổ hợp·lựa chọn chúng theo đặc tính tải công việc·yêu cầu quy định là cốt lõi của việc áp dụng và bảo mật đám mây.