Mở đầu — vì sao bài này quan trọng
Năm năm trước, khi bạn viết một bản đặc tả hệ thống, câu hỏi "Server đặt ở đâu?" thường được trả lời gọn lỏn: "Phòng IT lo." Nhưng hôm nay, gần như mọi dự án phần mềm mới ở Việt Nam — từ một ví điện tử fintech ở TP.HCM đến hệ thống quản lý kho của một chuỗi bán lẻ — đều chạy trên cloud (điện toán đám mây). Và bạn, với vai trò Technical BA, sẽ liên tục gặp những câu hỏi mà nếu không hiểu cloud, bạn sẽ chỉ biết gật đầu: "Cái này deploy lên môi trường nào? Chi phí một tháng bao nhiêu? Dữ liệu khách hàng có bị đưa ra nước ngoài không? Khi nào hệ thống auto-scale?"
Bài này không biến bạn thành Cloud Architect — đó không phải việc của BA. Mục tiêu của bài là giúp bạn hiểu đủ sâu để đọc được, hỏi được và viết spec đúng khi làm việc với đội kỹ thuật. Cụ thể, bạn sẽ phân biệt được ba mô hình dịch vụ IaaS/PaaS/SaaS, biết ba nhà cung cấp lớn (AWS, Azure, GCP) khác nhau ra sao, hiểu vì sao quyết định chọn dịch vụ cloud lại có hệ quả lớn về chi phí và tuân thủ pháp lý. Đây là nền tảng để bạn theo kịp các bài sau về containerization, microservices và data warehouse.
Khái niệm cốt lõi
Cloud thực chất là gì?
Cloud đơn giản là việc bạn thuê tài nguyên tính toán (máy chủ, lưu trữ, mạng, phần mềm) qua Internet thay vì tự mua phần cứng đặt trong văn phòng. Bạn trả tiền theo mức sử dụng — giống như trả tiền điện theo số kWh thay vì tự mua một máy phát điện. Ba đặc tính quan trọng nhất với BA:
- On-demand (theo nhu cầu): Cần thêm server thì bật trong vài phút, không cần đợi mua hàng 3 tuần.
- Pay-as-you-go (trả theo dùng): Dùng nhiều trả nhiều, đêm khuya ít người dùng thì tắt bớt để tiết kiệm.
- Elastic (co giãn): Hệ thống tự phình to khi tải tăng (ví dụ ngày sale 12/12) và tự thu nhỏ khi tải giảm.
Ba mô hình dịch vụ: IaaS, PaaS, SaaS
Đây là phần quan trọng nhất bạn cần nắm chắc. Hãy hình dung bạn muốn có một bữa pizza:
- Tự nấu ở nhà (On-premise): Bạn mua bột, lò nướng, tự làm tất cả. Tương đương việc tự dựng data center riêng — kiểm soát tối đa nhưng tốn công và vốn lớn.
- IaaS (Infrastructure as a Service): Người ta cho bạn thuê cái bếp đã có sẵn lò, điện, nước. Bạn mang nguyên liệu tới và tự nấu. Trong cloud, bạn thuê máy ảo (Virtual Machine) trống — ví dụ Amazon EC2, Azure Virtual Machine, Google Compute Engine. Bạn phải tự cài hệ điều hành (OS), tự cài database, tự vá lỗi bảo mật OS. Linh hoạt cao, nhưng đội bạn phải tự quản nhiều.
- PaaS (Platform as a Service): Người ta cho bạn cái bếp đã set up hoàn chỉnh, bạn chỉ cần bỏ pizza vào. Bạn chỉ lo code, còn OS, database, mạng nhà cung cấp lo hết. Ví dụ: AWS Elastic Beanstalk, Google App Engine, Azure App Service, Heroku. Đội dev triển khai nhanh hơn nhiều, nhưng kiểm soát ít hơn.
- SaaS (Software as a Service): Người ta giao tận tay cái pizza đã nấu chín. Bạn chỉ việc dùng phần mềm qua trình duyệt, không lo gì về kỹ thuật phía sau. Ví dụ: Salesforce (CRM), Microsoft 365, Google Workspace, Slack, Gmail. Bạn chỉ trả phí thuê bao theo người dùng.
Ba "ông lớn": AWS, Azure, GCP
Thị trường cloud toàn cầu do ba nhà cung cấp thống trị, mỗi ông có "tính cách" riêng:
- AWS (Amazon Web Services): Lớn nhất, ra đời sớm nhất (2006), danh mục dịch vụ đồ sộ nhất (hơn 200 dịch vụ). Nhiều startup và fintech Việt Nam chọn AWS vì cộng đồng đông, tài liệu nhiều. Dịch vụ tiêu biểu: EC2 (máy ảo), S3 (lưu trữ file), RDS (database), Lambda (serverless).
- Microsoft Azure: Mạnh ở mảng doanh nghiệp lớn vốn đã dùng sản phẩm Microsoft (Windows Server, Active Directory, Office). Các ngân hàng và tập đoàn lớn ở Việt Nam thường nghiêng về Azure vì tích hợp sẵn hệ sinh thái Microsoft và có cam kết hỗ trợ doanh nghiệp tốt.
- GCP (Google Cloud Platform): Mạnh nhất về dữ liệu lớn, AI/ML và phân tích — nhờ nền tảng BigQuery và Kubernetes (do Google phát minh). Các công ty làm nhiều về data analytics thường thích GCP.
Vùng (Region) và chủ quyền dữ liệu — điểm cực kỳ quan trọng ở Việt Nam
Mỗi nhà cung cấp đặt data center ở nhiều Region (vùng địa lý) khác nhau: Singapore, Tokyo, Mumbai, US East... Đây là điểm BA Việt Nam phải đặc biệt lưu ý. Nghị định 13/2023/NĐ-CP về Bảo vệ dữ liệu cá nhân và Luật An ninh mạng đặt ra yêu cầu về lưu trữ và xử lý dữ liệu của công dân Việt Nam. Nếu hệ thống của bạn xử lý dữ liệu cá nhân nhạy cảm (đặc biệt trong ngân hàng, fintech, y tế), việc chọn Region nào — và liệu dữ liệu có "rời khỏi Việt Nam" hay không — là một yêu cầu phi chức năng (NFR) mà bạn phải làm rõ ngay từ đầu, không thể để đến cuối dự án.
Tình huống thực tế
Tình huống 1 — Startup giao đồ ăn chọn IaaS hay PaaS
Một startup giao đồ ăn ở Hà Nội (gọi là FoodGo) có 6 lập trình viên, đang xây MVP. CTO ban đầu định thuê 3 máy ảo EC2 (IaaS) trên AWS để tự cài tất cả. BA của dự án — sau khi hiểu về mô hình dịch vụ — đặt câu hỏi trong buổi họp: "Với đội chỉ 6 người và áp lực ra mắt trong 8 tuần, chúng ta có thực sự đủ người để tự vá lỗi OS, tự backup database mỗi đêm, tự cấu hình load balancer không?"
Câu hỏi đó khiến đội nhìn lại. Họ chuyển sang dùng PaaS (Google App Engine + database được quản lý Cloud SQL). Kết quả: đội không còn ai phải thức đêm vá Linux, tốc độ deploy nhanh gấp đôi, và tiết kiệm được khoảng 1 nhân sự DevOps trong giai đoạn đầu.
Bài học: BA không quyết định kiến trúc, nhưng câu hỏi đúng lúc về "ai sẽ vận hành cái này" giúp đội chọn mô hình dịch vụ phù hợp với nguồn lực thực tế. PaaS thường là lựa chọn thông minh cho team nhỏ, ưu tiên tốc độ.
Tình huống 2 — Ngân hàng và bài toán chủ quyền dữ liệu
Một ngân hàng tầm trung ở TP.HCM triển khai ứng dụng mobile banking mới, dự định dùng AWS Region Singapore vì độ trễ thấp và chi phí hợp lý. Trong buổi rà soát yêu cầu, BA phụ trách phần tuân thủ nêu vấn đề: dữ liệu định danh khách hàng (eKYC) và lịch sử giao dịch là dữ liệu cá nhân nhạy cảm, theo Nghị định 13 và quy định của Ngân hàng Nhà nước, có những loại dữ liệu cần lưu trữ trong nước.
Đội kỹ thuật vốn chỉ nghĩ về hiệu năng đã bỏ sót yêu cầu này. Kết quả của cuộc thảo luận: hệ thống được thiết kế theo mô hình lai (hybrid) — dữ liệu nhạy cảm lưu trên hạ tầng đặt tại Việt Nam (data center của một nhà cung cấp trong nước), còn các thành phần không nhạy cảm như giao diện, cache vẫn chạy trên cloud Singapore. Việc phát hiện sớm này tránh được một đợt thiết kế lại tốn kém ở giai đoạn cuối, ước tính hàng trăm triệu đồng và trễ 2 tháng.
Bài học: Region không chỉ là câu hỏi kỹ thuật về độ trễ — nó là câu hỏi pháp lý. BA là người duy nhất trong phòng họp có trách nhiệm kết nối yêu cầu kinh doanh/pháp lý với lựa chọn hạ tầng. Đừng bao giờ coi việc chọn vùng là "chuyện của dev".
Tình huống 3 — Cú sốc hóa đơn cuối tháng
Một công ty thương mại điện tử ở Đông Nam Á chạy chiến dịch flash sale. Đội kỹ thuật bật auto-scaling để hệ thống tự thêm máy ảo khi traffic tăng vọt — điều này hoạt động hoàn hảo về mặt kỹ thuật. Nhưng cuối tháng, CFO nhận hóa đơn AWS gấp 4 lần dự kiến: 18.000 USD thay vì 4.500 USD. Nguyên nhân: ngoài việc scale máy ảo, hệ thống còn chuyển một lượng dữ liệu khổng lồ ra ngoài (data egress / data transfer out) — phần phí mà ít ai để ý vì nó "ẩn" trong cách tính giá cloud.
Sau sự cố, BA được giao xây dựng một mục bắt buộc trong mọi spec mới: phần "Cost Implication" (Hệ quả chi phí), trong đó mô tả rõ những hoạt động nào sẽ phát sinh chi phí cloud lớn và đặt ngưỡng cảnh báo (budget alert).
Bài học: Trên cloud, "trả theo dùng" là con dao hai lưỡi. Một quyết định kỹ thuật tưởng nhỏ có thể thổi bay ngân sách. BA cần đưa chi phí thành một yêu cầu phi chức năng được theo dõi, chứ không phải bất ngờ cuối tháng.
Hướng dẫn từng bước
Khi bạn được giao một dự án sẽ chạy trên cloud, đây là quy trình để bạn làm việc hiệu quả với đội kỹ thuật:
- Xác định mô hình dịch vụ phù hợp. Hỏi đội: chúng ta dùng IaaS, PaaS hay SaaS cho từng thành phần? Ghi rõ vào tài liệu ai chịu trách nhiệm vận hành phần nào (mô hình "shared responsibility" — trách nhiệm chia sẻ giữa bạn và nhà cung cấp cloud).
- Làm rõ yêu cầu về Region và chủ quyền dữ liệu. Lập danh sách các loại dữ liệu hệ thống xử lý, đánh dấu loại nào là dữ liệu cá nhân/nhạy cảm, rồi cùng bộ phận pháp chế xác định loại nào bắt buộc lưu trong nước. Đây phải là NFR được viết rõ.
- Đối chiếu tên dịch vụ giữa các nhà cung cấp. Nếu tài liệu kỹ thuật nhắc đến "S3", "Lambda", "Cloud Run", hãy lập một bảng tra cứu nhỏ để bạn hiểu nó là loại dịch vụ gì (lưu trữ, serverless, container...). Bạn không cần thuộc, chỉ cần tra được.
- Đưa chi phí vào tài liệu. Yêu cầu đội kỹ thuật ước tính chi phí vận hành hàng tháng cho các kịch bản: tải bình thường, tải cao điểm. Ghi rõ những hoạt động "đắt đỏ ẩn" như data egress, backup, snapshot.
- Xác định môi trường (environments). Làm rõ dự án cần bao nhiêu môi trường: Dev (phát triển), Staging (thử nghiệm giống thật), Production (chạy thật). Mỗi môi trường tốn chi phí riêng.
- Ghi nhận yêu cầu về co giãn và sẵn sàng cao. Hệ thống có cần auto-scale không? Mức sẵn sàng (availability) mục tiêu là bao nhiêu — 99.9% hay 99.99%? Con số này ảnh hưởng trực tiếp đến kiến trúc và chi phí.
Lỗi thường gặp & mẹo
- Lỗi: Nhầm lẫn "lên cloud" nghĩa là tự động rẻ hơn. Cloud có thể đắt hơn on-premise nếu dùng sai mô hình hoặc không tối ưu. Mẹo: luôn yêu cầu so sánh chi phí theo kịch bản cụ thể, đừng tin câu nói chung chung "cloud rẻ hơn".
- Lỗi: Coi việc chọn Region là chuyện kỹ thuật thuần túy. Như tình huống ngân hàng cho thấy, đây là vấn đề pháp lý. Mẹo: luôn kéo bộ phận pháp chế vào sớm khi dữ liệu cá nhân được liên quan.
- Lỗi: Bỏ qua chi phí data transfer. Nhiều BA chỉ nghĩ đến phí máy ảo và lưu trữ. Mẹo: hỏi cụ thể về phí truyền dữ liệu ra ngoài (egress) — đây là "cái bẫy" hóa đơn phổ biến nhất.
- Lỗi: Lẫn lộn IaaS với PaaS khi viết phân chia trách nhiệm. Nếu spec ghi dùng PaaS nhưng lại bắt đội tự vá OS, bạn đã hiểu sai mô hình. Mẹo: nhớ quy tắc pizza — PaaS thì nhà cung cấp lo "bếp", bạn chỉ lo "pizza" (code).
- Mẹo vàng: Bạn không cần biết cách cấu hình một server, nhưng bạn cần biết đặt câu hỏi đúng. Câu hỏi mạnh nhất của BA về cloud là: "Ai vận hành cái này, chạy ở vùng nào, và chi phí một tháng là bao nhiêu cho kịch bản tải cao điểm?"
Bài tập thực hành
- Phân loại mô hình dịch vụ. Với mỗi hệ thống sau, hãy xác định nó thuộc IaaS, PaaS hay SaaS và giải thích: (a) công ty thuê Gmail cho toàn nhân viên; (b) đội dev thuê một máy ảo Ubuntu trống rồi tự cài MySQL; (c) đội dev đẩy code Python lên Google App Engine và không quản OS.
- Viết một mục NFR về Region. Giả sử bạn làm BA cho một ứng dụng ví điện tử tại Việt Nam. Viết một đoạn yêu cầu phi chức năng (3–5 câu) mô tả ràng buộc về nơi lưu trữ dữ liệu cá nhân khách hàng, có dẫn chiếu cơ sở pháp lý.
- Lập bảng tra cứu dịch vụ. Tạo bảng 4 cột (Loại dịch vụ | AWS | Azure | GCP) cho ít nhất ba loại: máy ảo, lưu trữ file/object, hàm serverless. Tra tài liệu để điền đúng tên.
- Phân tích tình huống chi phí. Đọc lại Tình huống 3. Hãy đề xuất ba biện pháp cụ thể mà BA có thể đưa vào spec để tránh cú sốc hóa đơn tương tự xảy ra lần nữa.
Tóm tắt
Cloud không còn là lựa chọn mà đã trở thành mặc định cho hầu hết dự án phần mềm mới ở Việt Nam, vì vậy Technical BA buộc phải hiểu nền tảng của nó. Ba điều cốt lõi cần nhớ:
- Ba mô hình dịch vụ — IaaS (thuê bếp, tự nấu), PaaS (bếp sẵn, chỉ lo pizza), SaaS (pizza giao tận tay). Càng lên cao càng đỡ việc kỹ thuật nhưng càng ít kiểm soát. Biết mình ở mô hình nào giúp viết đúng phần phân chia trách nhiệm.
- Ba nhà cung cấp — AWS (lớn nhất, cộng đồng đông), Azure (mạnh doanh nghiệp Microsoft), GCP (mạnh dữ liệu và AI). Họ cung cấp dịch vụ tương đương, chỉ khác tên; BA cần biết đối chiếu, không cần thuộc lòng.
- Hai vấn đề BA phải chủ động nêu — chủ quyền dữ liệu (Region và tuân thủ Nghị định 13, Luật An ninh mạng) và chi phí (đưa hệ quả chi phí thành NFR có theo dõi, đặc biệt là phí data egress ẩn).