Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn muốn có một bữa tối. Bạn có bốn lựa chọn: tự trồng rau nuôi gà rồi nấu ở nhà, ra chợ mua nguyên liệu về nấu, gọi đồ ăn giao tận nhà, hoặc ra nhà hàng ngồi ăn. Cả bốn cách đều cho bạn no bụng, nhưng khác nhau ở chỗ: bạn phải tự làm bao nhiêu, và nhà cung cấp làm hộ bạn bao nhiêu.
Đây chính xác là cách tư duy về ba mô hình dịch vụ cloud: IaaS, PaaS và SaaS. Đây có lẽ là khái niệm nền tảng quan trọng nhất trong toàn bộ thế giới điện toán đám mây. Nếu bạn không phân biệt rõ ba mô hình này, bạn sẽ liên tục gặp khó khăn khi đọc tài liệu, khi so sánh giá dịch vụ, khi thiết kế hệ thống, và đặc biệt là khi trả lời một câu hỏi cực kỳ thực tế: "Cái gì tôi phải tự lo, và cái gì nhà cung cấp lo hộ?"
Câu trả lời cho câu hỏi đó quyết định trực tiếp đến chi phí, tốc độ triển khai, mức độ linh hoạt và cả rủi ro bảo mật của hệ thống bạn xây dựng. Một startup Việt Nam chọn sai mô hình có thể đốt hàng trăm triệu đồng thuê kỹ sư vận hành cho việc mà lẽ ra nhà cung cấp đã lo hộ. Ngược lại, một ngân hàng chọn SaaS cho phần lõi nhạy cảm có thể vi phạm quy định về chủ quyền dữ liệu.
Trong bài này, chúng ta sẽ mổ xẻ ba mô hình theo đúng định nghĩa chuẩn của NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ) — bộ định nghĩa được cả ngành công nghiệp coi là kim chỉ nam. Bạn sẽ hiểu ranh giới trách nhiệm giữa bạn và nhà cung cấp ở từng tầng, biết cách nhìn một dịch vụ bất kỳ và xếp nó vào đúng nhóm, và quan trọng nhất là biết chọn mô hình phù hợp cho từng bài toán cụ thể.
Khái niệm cốt lõi
"Ai quản lý cái gì" — trục xương sống của cả bài
Cách dễ nhất để hiểu ba mô hình là hình dung một "chồng" (stack) các thành phần cần thiết để chạy một ứng dụng, xếp từ dưới lên trên:
- Networking (mạng)
- Storage (lưu trữ)
- Servers (máy chủ vật lý)
- Virtualization (ảo hóa)
- Operating System (hệ điều hành)
- Middleware / Runtime (môi trường chạy: Java, Node.js, .NET...)
- Data (dữ liệu)
- Application (ứng dụng)
Điện toán đám mây ra đời để "cắt" chồng này ở những vị trí khác nhau. Nhà cung cấp (provider) lo phần bên dưới đường cắt, bạn lo phần bên trên. Đường cắt càng cao thì bạn càng nhàn nhưng càng ít quyền kiểm soát; đường cắt càng thấp thì bạn càng cực nhưng càng linh hoạt.
IaaS — Infrastructure as a Service (Hạ tầng dưới dạng dịch vụ)
Với IaaS, nhà cung cấp lo phần hạ tầng vật lý và ảo hóa: máy chủ, lưu trữ, mạng, trung tâm dữ liệu, điện, làm mát. Đường cắt nằm ngay trên tầng ảo hóa.
Bạn nhận được một máy chủ ảo trống trơn (Virtual Machine) và tự quản lý từ hệ điều hành trở lên: bạn chọn cài Ubuntu hay Windows, tự vá lỗi bảo mật OS, tự cài web server, tự cài database, tự deploy ứng dụng, tự cấu hình firewall ở tầng OS.
Ví dụ điển hình: Amazon EC2, Google Compute Engine, Azure Virtual Machines, và ở Việt Nam là Viettel Cloud Server, FPT Cloud Compute. Về cơ bản, IaaS giống việc bạn thuê một cái nhà trống — nhà cung cấp lo móng, tường, mái; bạn tự kê giường, lắp điều hòa, sơn tường theo ý mình.
IaaS phù hợp khi bạn cần toàn quyền kiểm soát môi trường, cần cài phần mềm đặc thù, hoặc đang di chuyển (migrate) một ứng dụng cũ lên cloud mà không muốn viết lại code.
PaaS — Platform as a Service (Nền tảng dưới dạng dịch vụ)
Với PaaS, nhà cung cấp lo thêm một tầng nữa: hệ điều hành, middleware và runtime. Đường cắt nằm trên tầng runtime. Bạn không còn phải lo cài đặt và vá lỗi hệ điều hành, không lo cấu hình môi trường chạy Node.js hay Java — nhà cung cấp đã dựng sẵn.
Bạn chỉ tập trung vào hai thứ: code ứng dụng và dữ liệu. Bạn đẩy code lên, nền tảng tự lo phần còn lại: chạy nó, scale nó khi lượng truy cập tăng, vá bảo mật bên dưới.
Ví dụ điển hình: AWS Elastic Beanstalk, Google App Engine, Azure App Service, Heroku, và các nền tảng như Vercel, Render mà nhiều lập trình viên Việt Nam đang dùng. PaaS giống như thuê một căn hộ dịch vụ có đủ nội thất — bạn chỉ việc dọn vào ở (đẩy code lên) và sống (chạy ứng dụng), còn bảo trì tòa nhà là việc của ban quản lý.
PaaS phù hợp với đội ngũ dev muốn ra sản phẩm nhanh, không muốn tốn người nuôi hạ tầng.
SaaS — Software as a Service (Phần mềm dưới dạng dịch vụ)
Với SaaS, nhà cung cấp lo toàn bộ chồng — kể cả ứng dụng và phần lớn việc quản lý dữ liệu. Đường cắt nằm ở tận trên cùng. Bạn không cài đặt gì, không code gì, không vận hành gì. Bạn chỉ mở trình duyệt, đăng nhập và dùng.
Ví dụ điển hình mà ai cũng dùng hàng ngày: Gmail, Google Workspace, Microsoft 365, Salesforce, Slack, Zoom, và các sản phẩm Việt như Base.vn, MISA AMIS, KiotViet. Bạn chỉ quản lý phần rất mỏng: dữ liệu bạn nhập vào, tài khoản người dùng, và cấu hình tùy chọn trong ứng dụng. SaaS giống như đi ăn nhà hàng — bạn không cần biết bếp vận hành ra sao, chỉ gọi món và thưởng thức.
Bảng so sánh trách nhiệm theo định nghĩa NIST
Đây là bảng cốt lõi bạn nên thuộc lòng. Dấu ✅ nghĩa là bạn (khách hàng) quản lý, dấu ☁️ nghĩa là nhà cung cấp quản lý:
| Tầng | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Application (ứng dụng) | ✅ | ✅ | ✅ | ☁️ |
| Data (dữ liệu) | ✅ | ✅ | ✅ | ☁️ |
| Runtime / Middleware | ✅ | ✅ | ☁️ | ☁️ |
| Operating System | ✅ | ✅ | ☁️ | ☁️ |
| Virtualization (ảo hóa) | ✅ | ☁️ | ☁️ | ☁️ |
| Servers (máy chủ) | ✅ | ☁️ | ☁️ | ☁️ |
| Storage (lưu trữ) | ✅ | ☁️ | ☁️ | ☁️ |
| Networking (mạng) | ✅ | ☁️ | ☁️ | ☁️ |
Một điểm cần nhớ về ranh giới: dù dùng mô hình nào, bảo mật dữ liệu và quản lý danh tính người dùng (ai được truy cập) gần như luôn thuộc trách nhiệm của bạn. Nhà cung cấp lo "bảo mật của đám mây" (an toàn hạ tầng), còn bạn lo "bảo mật trong đám mây" (cấu hình đúng, phân quyền đúng, không để lộ dữ liệu).
Tình huống thực tế
Tình huống 1: Startup thương mại điện tử ở TP.HCM chọn PaaS để ra mắt nhanh
Một startup bán mỹ phẩm online tên "Glowbox" (tình huống giả định hợp lý) có đội ngũ 3 lập trình viên và 1 thời hạn gắt: phải kịp ra mắt trước dịp sale 11/11, còn đúng 6 tuần. Họ không có ai chuyên về vận hành hạ tầng (DevOps/SysAdmin).
Ban đầu founder tính thuê 2 con VPS (IaaS) trên FPT Cloud để tự dựng. Nhưng khi ước tính công việc, họ nhận ra: chỉ riêng việc cài đặt hệ điều hành, cấu hình web server, thiết lập tự động scale khi tải cao, vá bảo mật... sẽ ngốn của 3 dev khoảng 2 tuần — tức một phần ba quỹ thời gian, chưa viết dòng code sản phẩm nào.
Họ chuyển hướng sang PaaS: deploy backend lên Render, frontend lên Vercel, và dùng database quản lý (managed database) đi kèm. Kết quả: chỉ mất nửa ngày để có môi trường chạy được. Toàn bộ 6 tuần dồn vào làm tính năng. Đêm 11/11 lượng truy cập tăng gấp 8 lần, nền tảng tự scale, không ai phải thức trắng canh server.
Bài học: Khi thời gian và nhân lực là nút thắt, PaaS mua cho bạn tốc độ. Cái giá phải trả là ít quyền kiểm soát hơn và chi phí trên mỗi đơn vị tính toán thường cao hơn IaaS — nhưng với một startup đang đua thời gian, đó là khoản đầu tư quá hời.
Tình huống 2: Ngân hàng chọn IaaS cho hệ thống core nhạy cảm
Một ngân hàng thương mại tại Việt Nam cần chuyển một phần hệ thống lên cloud nhưng phải tuân thủ quy định của Ngân hàng Nhà nước về an toàn thông tin. Phần mềm lõi của họ là một ứng dụng Java cũ, cần một phiên bản hệ điều hành cụ thể, cấu hình bảo mật đặc thù, và phải cài agent giám sát riêng của bộ phận an ninh.
PaaS không phù hợp: nền tảng PaaS che giấu hệ điều hành, nên họ không thể cài agent bảo mật tùy chỉnh hay kiểm soát chính xác từng tham số của OS. SaaS lại càng không — không thể mua "phần mềm core banking dùng chung" ngoài chợ.
Họ chọn IaaS trên hạ tầng cloud trong nước (để dữ liệu nằm trong lãnh thổ Việt Nam, đáp ứng yêu cầu chủ quyền dữ liệu). Đội ngũ hạ tầng của ngân hàng dựng VM, cài đúng phiên bản OS đã được kiểm định, cài agent giám sát, cấu hình firewall theo chuẩn nội bộ. Họ chấp nhận vất vả hơn để đổi lấy toàn quyền kiểm soát — thứ bắt buộc phải có trong môi trường bị quản lý chặt.
Bài học: Khi yêu cầu tuân thủ và kiểm soát cao hơn tốc độ, IaaS là lựa chọn đúng. Sự "vất vả" của IaaS ở đây không phải nhược điểm mà là tính năng: nó cho phép bạn chạm tay vào từng tầng.
Tình huống 3: Công ty 40 nhân viên chọn SaaS thay vì tự dựng email
Một công ty logistics vừa 40 người ở Hải Phòng cần hệ thống email công ty, lịch chung, lưu trữ tài liệu. Phương án tự dựng (on-premises hoặc IaaS): mua server, cài mail server, lo chống spam, lo backup, lo bảo mật, thuê 1 IT chuyên trách — ước tính vài trăm triệu đồng năm đầu và rủi ro email rơi vào hộp spam của đối tác.
Họ chọn SaaS: đăng ký Google Workspace khoảng vài chục nghìn đồng/người/tháng. Trong một buổi chiều, toàn bộ 40 tài khoản email theo tên miền công ty được dựng xong, có chống spam đẳng cấp Google, có lịch, có Drive lưu trữ. Không server, không IT chuyên trách, không lo vá bảo mật.
Bài học: Với những bài toán phổ biến, "đã được giải sẵn" (email, CRM, kế toán, chat nội bộ), SaaS gần như luôn là lựa chọn kinh tế và an toàn nhất. Chẳng có lý do gì để một công ty logistics tự viết phần mềm email.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn chọn đúng mô hình cho một bài toán bất kỳ:
Bước 1 — Xác định bài toán đã có lời giải sẵn chưa. Hỏi: "Nhu cầu của tôi (email, CRM, kế toán, quản lý bán hàng, họp online...) có phải là thứ hàng triệu công ty khác cũng cần không?" Nếu có, khả năng cao đã có một sản phẩm SaaS tốt. Đừng phát minh lại bánh xe. Dừng ở đây.
Bước 2 — Nếu cần phần mềm riêng, hỏi về nhu cầu kiểm soát. Bạn đang xây một ứng dụng của riêng mình. Câu hỏi tiếp theo: "Tôi có cần đụng đến hệ điều hành, cài phần mềm hệ thống đặc thù, hay tuân thủ quy định bắt buộc kiểm soát hạ tầng không?" Nếu có → nghiêng về IaaS. Nếu không → nghiêng về PaaS.
Bước 3 — Đánh giá nguồn lực vận hành. Đội của bạn có người chuyên vận hành hạ tầng không? Nếu không có và không muốn thuê → ưu tiên PaaS (hoặc dịch vụ managed). Nếu có đội DevOps mạnh → IaaS trở nên khả thi và thường rẻ hơn ở quy mô lớn.
Bước 4 — Ước tính chi phí tổng, không chỉ giá niêm yết. IaaS có giá thuê máy rẻ hơn nhưng cộng thêm chi phí nhân sự vận hành. PaaS đắt hơn trên đầu máy nhưng tiết kiệm nhân sự. Hãy tính tổng chi phí sở hữu (TCO) = tiền hạ tầng + tiền người vận hành + chi phí cơ hội của thời gian.
Bước 5 — Cân nhắc chủ quyền dữ liệu và tuân thủ. Dữ liệu của bạn có bị ràng buộc phải nằm trong lãnh thổ Việt Nam (theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân) không? Nếu có, ưu tiên nhà cung cấp có trung tâm dữ liệu trong nước như Viettel IDC, FPT Cloud, VNG Cloud — bất kể bạn chọn mô hình nào.
Bước 6 — Cho phép kết hợp nhiều mô hình. Đây là điểm nâng cao quan trọng: một hệ thống thực tế thường trộn cả ba. Ví dụ: chạy ứng dụng chính trên PaaS, phần xử lý dữ liệu đặc thù trên IaaS, và dùng SaaS (Google Workspace) cho vận hành nội bộ. Đừng nghĩ bạn phải chọn duy nhất một.
Lỗi thường gặp & mẹo
Lỗi 1: Nghĩ rằng dùng cloud là hết trách nhiệm bảo mật. Rất nhiều vụ lộ dữ liệu không phải do nhà cung cấp bị hack, mà do khách hàng cấu hình sai — ví dụ để một kho lưu trữ (bucket) ở chế độ public. Nhớ nguyên tắc: nhà cung cấp bảo vệ hạ tầng, bạn bảo vệ dữ liệu và cấu hình của mình.
Lỗi 2: Chọn IaaS vì "rẻ" mà quên chi phí nhân sự. Giá thuê VM nhìn thì rẻ, nhưng nếu bạn phải thuê một kỹ sư 25 triệu/tháng chỉ để vá lỗi và canh server, thì tổng chi phí có khi đắt hơn PaaS nhiều lần. Luôn tính TCO.
Lỗi 3: Lạm dụng PaaS cho mọi thứ rồi bị "khóa chân" (vendor lock-in). PaaS tiện nhưng thường ràng buộc bạn vào cách làm riêng của nhà cung cấp. Chuyển đi nơi khác có thể tốn kém. Mẹo: với phần lõi quan trọng, hãy giữ code càng "chuẩn mực" (portable) càng tốt, tránh dùng quá sâu các tính năng độc quyền.
Lỗi 4: Nhầm lẫn "managed database" thuộc mô hình nào. Một dịch vụ database quản lý (như Amazon RDS) về bản chất là PaaS thu nhỏ — bạn không lo OS, không lo cài đặt, chỉ dùng. Đừng cứng nhắc xếp mọi thứ vào đúng một ô; hãy nhìn theo trục "ai quản lý cái gì".
Mẹo vàng để phân loại nhanh: Khi gặp một dịch vụ lạ, hãy hỏi ba câu: (1) Tôi có phải quản lý hệ điều hành không? Nếu có → IaaS. (2) Tôi có phải viết/deploy code không nhưng không lo OS? Nếu có → PaaS. (3) Tôi chỉ đăng nhập và dùng? → SaaS.
Mẹo về chi phí: Với workload chạy đều đặn 24/7 và ổn định, IaaS với gói cam kết dài hạn thường rẻ nhất. Với workload biến động mạnh hoặc dự án ngắn hạn, PaaS/serverless linh hoạt hơn về chi phí.
Bài tập thực hành
Bài 1 — Phân loại nhanh. Xếp các dịch vụ sau vào IaaS, PaaS hay SaaS: (a) Dropbox, (b) Amazon EC2, (c) Heroku, (d) KiotViet, (e) Google Compute Engine, (f) Vercel. Ghi lý do cho mỗi câu dựa trên câu hỏi "tôi phải quản lý hệ điều hành không, tôi phải deploy code không".
Bài 2 — Vẽ lại bảng trách nhiệm. Không nhìn lại bài, hãy tự vẽ bảng 8 tầng (từ Networking đến Application) và điền vào cột IaaS/PaaS/SaaS xem tầng nào bạn quản lý, tầng nào nhà cung cấp quản lý. Sau đó đối chiếu với bảng trong bài.
Bài 3 — Tình huống ra quyết định. Bạn là CTO của một phòng khám tư nhân sắp mở, cần: (1) hệ thống đặt lịch khám online cho bệnh nhân, (2) email nội bộ cho 15 nhân viên, (3) một ứng dụng quản lý hồ sơ bệnh án tự phát triển với yêu cầu dữ liệu phải lưu tại Việt Nam. Với mỗi nhu cầu, hãy chọn mô hình dịch vụ (IaaS/PaaS/SaaS) và nhà cung cấp phù hợp, giải thích lý do trong 2-3 câu.
Bài 4 — Tính TCO đơn giản. Giả sử phương án A là IaaS: 3 triệu/tháng tiền VM + cần 0,5 người vận hành (lương 20 triệu/tháng). Phương án B là PaaS: 8 triệu/tháng, không cần người vận hành riêng. Tính tổng chi phí mỗi tháng của hai phương án và cho biết phương án nào rẻ hơn. Sau đó thử tăng quy mô lên 10 VM và tính lại — kết luận có thay đổi không?
Tóm tắt
Ba mô hình dịch vụ cloud khác nhau ở một điều duy nhất nhưng cực kỳ quan trọng: ranh giới trách nhiệm giữa bạn và nhà cung cấp.
- IaaS — nhà cung cấp lo hạ tầng và ảo hóa, bạn quản lý từ hệ điều hành trở lên. Nhiều quyền kiểm soát nhất, vất vả nhất. Hợp với migrate hệ thống cũ, yêu cầu tuân thủ cao, cần cài đặt đặc thù.
- PaaS — nhà cung cấp lo thêm OS, runtime, middleware; bạn chỉ lo code và dữ liệu. Cân bằng giữa tốc độ và kiểm soát. Hợp với đội dev muốn ra sản phẩm nhanh, ít người vận hành.
- SaaS — nhà cung cấp lo tất cả; bạn chỉ đăng nhập và dùng. Ít việc nhất, ít kiểm soát nhất. Hợp với những bài toán phổ biến đã có lời giải sẵn (email, CRM, kế toán).
Nắm chắc bài này, bạn đã có "bộ khung tư duy" để đọc hiểu và đánh giá bất kỳ dịch vụ cloud nào gặp trong suốt phần còn lại của khóa học. Ở các bài tiếp theo, chúng ta sẽ đi sâu vào các mô hình triển khai (public, private, hybrid, multi-cloud) và từng hệ sinh thái nhà cung cấp cụ thể.