Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là kỹ sư DevOps của một chuỗi bán lẻ ở TP.HCM. Sếp gọi bạn vào phòng họp và nói một câu ngắn gọn: "Quý sau công ty lên cloud, em lo phần kỹ thuật." Nghe thì đơn giản, nhưng đằng sau câu nói đó là hàng trăm câu hỏi. Ứng dụng bán hàng viết bằng .NET chạy trên máy chủ vật lý trong phòng server tầng hầm sẽ đi đâu? Con database Oracle 12 năm tuổi, không ai dám đụng vào vì sợ sập, xử lý thế nào? Phần mềm chấm công mua bản quyền vĩnh viễn có nên bỏ đi để dùng dịch vụ SaaS không?
Đây chính là lúc bạn cần một cái khung tư duy để phân loại và ra quyết định. Nếu không có khung, bạn sẽ "bê nguyên xi" mọi thứ lên cloud — và ba tháng sau nhận hóa đơn gấp đôi chi phí phòng server cũ, trong khi hệ thống vẫn ì ạch như trước. Đây là sai lầm kinh điển mà rất nhiều doanh nghiệp Việt Nam mắc phải khi "lên mây" mà không có chiến lược.
Bài học hôm nay giới thiệu framework 6 Rs do AWS phổ biến (thực ra bắt nguồn từ nghiên cứu của Gartner với "5 Rs", sau đó AWS mở rộng thành 6). Đây là bộ công cụ chuẩn để bạn nhìn vào từng ứng dụng, từng thành phần trong hệ thống và trả lời câu hỏi: "Với cái này, ta nên làm gì khi di chuyển lên cloud?" Nắm vững 6 Rs, bạn sẽ chuyển từ vai trò "người khuân vác server" thành "kiến trúc sư di trú" — người biết cân đo giữa chi phí, rủi ro và giá trị dài hạn.
Khái niệm cốt lõi
Cloud Migration là quá trình chuyển ứng dụng, dữ liệu và hạ tầng từ môi trường hiện tại (thường là on-premise — máy chủ tự vận hành) sang môi trường cloud. Nhưng "chuyển" không có nghĩa là chỉ có một cách. Với mỗi workload (một ứng dụng hoặc dịch vụ cụ thể), bạn có sáu lựa chọn khác nhau. Đó là 6 Rs.
Tổng quan 6 Rs
| R | Chiến lược | Công sức | Ý nghĩa ngắn gọn |
|---|---|---|---|
| Rehost | Lift & shift | Thấp | Bê nguyên VM lên cloud VM, không sửa code |
| Replatform | Lift, tinker & shift | Trung bình | Chuyển lên nhưng tối ưu vài chỗ (ví dụ đổi DB tự quản sang managed DB) |
| Repurchase | Drop & shop | Trung bình | Bỏ hệ thống cũ, mua SaaS thay thế |
| Refactor | Re-architect | Cao | Viết lại kiến trúc cho cloud-native |
| Retire | Loại bỏ | Thấp | Cái gì không dùng nữa thì tắt luôn |
| Retain | Giữ lại | Không | Chưa chuyển, để nguyên on-premise |
Rehost — "Lift & shift" (nhấc lên và đặt xuống)
Đây là cách đơn giản nhất: bạn lấy máy ảo (VM) đang chạy on-premise và copy y nguyên lên một VM tương đương trên cloud (ví dụ AWS EC2, GCP Compute Engine, Azure VM). Code không đổi, cấu hình gần như giữ nguyên, hệ điều hành cũng vậy. Các công cụ như AWS Application Migration Service (MGN) hay Azure Migrate giúp tự động hóa việc sao chép ổ đĩa và khởi động lại trên cloud.
Ưu điểm: nhanh, ít rủi ro về mặt logic ứng dụng, phù hợp khi bạn bị deadline gấp (ví dụ hợp đồng thuê datacenter sắp hết hạn). Nhược điểm: bạn không tận dụng được lợi thế cloud — vẫn phải tự quản lý OS, tự vá lỗi, và thường không tiết kiệm chi phí ngay. Rehost là "bước một" của nhiều doanh nghiệp: lên cloud trước, tối ưu sau.
Replatform — "Lift, tinker & shift" (nhấc lên, chỉnh chút, đặt xuống)
Giống Rehost nhưng bạn thay một vài thành phần bằng dịch vụ managed của cloud để giảm gánh nặng vận hành, mà không đụng vào phần lõi ứng dụng. Ví dụ điển hình: ứng dụng vẫn chạy trên VM, nhưng thay vì tự cài MySQL trên VM đó, bạn chuyển database sang Amazon RDS hoặc Cloud SQL — dịch vụ database do nhà cung cấp quản lý, tự backup, tự vá lỗi, tự thay thế khi hỏng.
Đây là điểm ngọt (sweet spot) mà nhiều đội DevOps hướng tới: công sức vừa phải nhưng đã hưởng được kha khá lợi ích cloud. Một biến thể phổ biến khác là đóng gói ứng dụng vào container để chạy trên dịch vụ quản lý container.
Repurchase — "Drop & shop" (bỏ và mua mới)
Thay vì di chuyển phần mềm cũ, bạn ngừng dùng nó và mua một sản phẩm SaaS tương đương. Ví dụ: bỏ hệ thống CRM tự phát triển để chuyển sang Salesforce; bỏ email server tự dựng để dùng Google Workspace hoặc Microsoft 365; bỏ phần mềm chấm công cài trên máy chủ để dùng dịch vụ HR trên cloud.
Chiến lược này hợp lý khi phần mềm cũ không phải lợi thế cạnh tranh của bạn — nó chỉ là công cụ nội bộ. Rủi ro chính là dữ liệu và quy trình phải map lại theo mô hình của nhà cung cấp SaaS, và bạn bị phụ thuộc vào họ (vendor lock-in).
Refactor / Re-architect — Viết lại cho cloud-native
Đây là chiến lược tốn công nhất nhưng mang lại giá trị dài hạn lớn nhất. Bạn thay đổi căn bản kiến trúc ứng dụng để tận dụng tối đa cloud: tách monolith thành microservices, dùng serverless (như Lambda), dùng managed queue, auto-scaling... Refactor thường được chọn khi ứng dụng cũ không còn đáp ứng nổi nhu cầu về khả năng mở rộng, hoặc khi doanh nghiệp muốn tăng tốc độ ra tính năng mới.
Lưu ý: Refactor đắt và rủi ro. Bạn chỉ nên làm khi có lý do kinh doanh rõ ràng, không phải chỉ vì "muốn cho hiện đại".
Retire — Loại bỏ
Khi kiểm kê hệ thống, bạn sẽ luôn phát hiện những ứng dụng chẳng ai còn dùng: một cái portal nội bộ từ 2015, một con server chỉ chạy cron job đã lỗi thời. Với những thứ này, câu trả lời đơn giản là: tắt đi. Retire giúp giảm ngay chi phí và giảm bề mặt cần bảo mật. Theo thống kê của AWS, thường khoảng 10–20% workload trong một danh mục có thể retire.
Retain — Giữ lại
Không phải cái gì cũng nên lên cloud ngay. Có những workload bạn quyết định giữ nguyên on-premise: vì lý do tuân thủ pháp lý (dữ liệu nhạy cảm phải nằm trong nước), vì vừa mới đầu tư phần cứng chưa khấu hao xong, hoặc vì hệ thống quá phức tạp và chưa đến lượt. Retain là một quyết định có chủ đích — "tạm chưa chuyển" — chứ không phải bỏ quên.
Tình huống thực tế
Ví dụ 1 — Chuỗi bán lẻ Việt: từ Rehost sang Replatform
Một chuỗi cửa hàng mỹ phẩm có 40 chi nhánh (gọi là "BeautyMart", giả định) đang chạy hệ thống POS và quản lý kho trên 6 máy chủ vật lý tại văn phòng Hà Nội. Hợp đồng thuê chỗ đặt máy chủ (colocation) hết hạn sau 4 tháng, giá gia hạn tăng 30%. Đội IT quyết định lên AWS.
Vì thời gian gấp, họ chọn Rehost cho toàn bộ: dùng AWS MGN sao chép 6 máy chủ thành 6 EC2 instance, chạy được sau 6 tuần. Hệ thống hoạt động, kịp deadline. Nhưng ba tháng sau, hóa đơn AWS lên tới 4.500 USD/tháng — cao hơn dự kiến vì các instance chạy 24/7 với cấu hình dư thừa, và con MySQL tự quản trên EC2 thường xuyên đầy ổ đĩa lúc nửa đêm khiến kỹ sư trực phải dậy xử lý.
Sang giai đoạn hai, họ Replatform: chuyển MySQL sang Amazon RDS (hết cảnh trực đêm vì RDS tự quản lý ổ đĩa và backup), gộp 6 instance xuống còn 3 với cấu hình đúng nhu cầu, bật auto-scaling cho giờ cao điểm mua sắm cuối tuần. Hóa đơn giảm còn 2.700 USD/tháng và độ ổn định tăng rõ rệt.
Bài học: Rehost là bước đệm hợp lý khi gấp, nhưng đừng dừng lại ở đó. Hãy lên kế hoạch giai đoạn hai để Replatform, nếu không bạn chỉ "chuyển vấn đề on-premise lên cloud" kèm hóa đơn cao hơn.
Ví dụ 2 — Startup fintech Đông Nam Á: Repurchase và Retire
Một startup fintech ở Singapore mở rộng sang Việt Nam ("PayLink", giả định) có khoảng 30 ứng dụng nội bộ tích lũy sau 5 năm. Khi hợp nhất hạ tầng lên GCP, đội platform làm một buổi kiểm kê (application portfolio assessment) và phát hiện:
- 5 ứng dụng không còn ai truy cập trong 6 tháng qua — họ Retire ngay, tiết kiệm khoảng 800 USD/tháng.
- Hệ thống quản lý nhân sự và bảng lương tự viết đầy lỗi — họ Repurchase, chuyển sang một dịch vụ HR SaaS khu vực. Đội kỹ thuật không còn phải bảo trì phần mềm không phải chuyên môn cốt lõi của công ty.
- Hệ thống chấm điểm tín dụng (core business) — họ Refactor thành microservices trên GKE để mở rộng theo lượng giao dịch.
Ví dụ 3 — Ngân hàng và bài toán Retain vì tuân thủ
Một ngân hàng cỡ vừa tại Việt Nam muốn hiện đại hóa hạ tầng. Họ chuyển được website, ứng dụng mobile banking (phần front-end và các API không nhạy cảm) lên FPT Cloud và AWS. Tuy nhiên, hệ thống core banking và dữ liệu định danh khách hàng (KYC) thì họ Retain — giữ nguyên trong datacenter nội bộ.
Lý do: quy định của Ngân hàng Nhà nước và Nghị định về bảo vệ dữ liệu cá nhân (PDPD) yêu cầu một số loại dữ liệu tài chính phải được lưu trữ và xử lý theo tiêu chuẩn nghiêm ngặt, và ngân hàng đánh giá rủi ro tuân thủ khi đưa core banking lên public cloud là quá cao ở thời điểm hiện tại. Kết quả là mô hình hybrid: phần "mặt tiền" linh hoạt trên cloud, phần lõi nhạy cảm giữ tại chỗ.
Bài học: Retain không phải là "thất bại migration". Với ngành có quy định chặt như tài chính, y tế, Retain là quyết định trưởng thành. Yếu tố tuân thủ và chủ quyền dữ liệu (data residency) phải được cân nhắc ngay từ đầu chứ không phải để đến phút chót.
Hướng dẫn từng bước
Đây là quy trình áp dụng framework 6 Rs vào một dự án migration thực tế.
Bước 1 — Kiểm kê danh mục (Discovery & Portfolio Assessment). Liệt kê tất cả ứng dụng, server, database, và các phụ thuộc giữa chúng. Dùng công cụ tự động như AWS Application Discovery Service, Azure Migrate, hoặc đơn giản là bảng Excel với: tên ứng dụng, công nghệ, mức độ quan trọng, lượng truy cập, phụ thuộc. Đây là bước không được bỏ qua — bạn không thể quyết định "R" nào nếu không biết mình đang có gì.
Bước 2 — Đánh giá từng workload theo hai trục. Với mỗi ứng dụng, hỏi hai câu: (a) Giá trị kinh doanh của nó cao hay thấp? (b) Độ phức tạp kỹ thuật để migrate cao hay thấp? Ứng dụng giá trị thấp, ít dùng → nghiêng về Retire. Giá trị cao, cốt lõi cạnh tranh → cân nhắc Refactor. Công cụ nội bộ không phải lợi thế → Repurchase.
Bước 3 — Gán chiến lược R cho từng workload. Điền vào cột "6R" trong bảng kiểm kê. Đừng cầu toàn — với đa số doanh nghiệp, phần lớn workload sẽ rơi vào Rehost hoặc Replatform. Refactor chỉ dành cho số ít ứng dụng chiến lược.
Bước 4 — Ưu tiên và lập làn sóng (wave planning). Chia migration thành nhiều đợt. Đợt đầu nên chọn ứng dụng đơn giản, ít rủi ro để cả đội "làm nóng" và xây dựng quy trình. Để dành các workload phức tạp cho đợt sau khi đội đã có kinh nghiệm.
Bước 5 — Chạy thử (Proof of Concept) và migrate một wave. Làm với một nhóm nhỏ trước, kiểm tra kỹ, rồi mới nhân rộng. Luôn có kế hoạch rollback (quay lại) cho mỗi workload quan trọng.
Bước 6 — Tối ưu sau migration (Optimize). Sau khi lên cloud, xem lại chi phí, hiệu năng, độ ổn định. Đây thường là lúc bạn nâng cấp từ Rehost lên Replatform như ví dụ BeautyMart ở trên.
Lỗi thường gặp & mẹo
Lỗi 1 — Rehost tất cả rồi dừng lại. Rất nhiều doanh nghiệp "lift & shift" toàn bộ vì nhanh, rồi không bao giờ quay lại tối ưu. Kết quả: hóa đơn cao, không hưởng được giá trị cloud. Mẹo: coi Rehost là bước một, luôn có roadmap giai đoạn hai.
Lỗi 2 — Bỏ qua bước kiểm kê phụ thuộc. Bạn migrate ứng dụng A lên cloud nhưng quên nó gọi API tới ứng dụng B vẫn nằm on-premise, gây độ trễ cao hoặc lỗi kết nối. Mẹo: vẽ sơ đồ phụ thuộc (dependency map) trước khi chia wave, di chuyển các ứng dụng liên quan chặt chẽ cùng một đợt.
Lỗi 3 — Quên tính chi phí truyền dữ liệu. Khi hệ thống nửa cloud nửa on-premise, dữ liệu chạy qua lại giữa hai môi trường có thể phát sinh phí egress (dữ liệu ra khỏi cloud) đáng kể. Mẹo: ước lượng lưu lượng dữ liệu giữa các thành phần từ đầu.
Lỗi 4 — Refactor quá sớm, quá nhiều. Đội kỹ thuật hào hứng muốn viết lại mọi thứ thành microservices ngay. Điều này kéo dài dự án và tăng rủi ro. Mẹo: chỉ Refactor những gì có lý do kinh doanh rõ ràng.
Lỗi 5 — Bỏ qua yếu tố con người. Migration không chỉ là kỹ thuật. Đội vận hành cần được đào tạo về công cụ cloud mới. Mẹo: dành ngân sách cho đào tạo và có ít nhất một người am hiểu cloud dẫn dắt mỗi wave.
Mẹo tổng quát: Đừng chọn "R" theo cảm tính. Hãy để dữ liệu (lượng truy cập, chi phí hiện tại, độ phức tạp) dẫn dắt quyết định. Và luôn nhớ: mục tiêu cuối cùng không phải "lên cloud" mà là "đạt được kết quả kinh doanh tốt hơn nhờ cloud".
Bài tập thực hành
Bài 1 — Phân loại nhanh. Với mỗi workload sau, hãy gán một chiến lược trong 6 Rs và giải thích lý do trong 1–2 câu:
- Một web server Apache chạy trang giới thiệu công ty, cần lên cloud gấp trong 2 tuần.
- Ứng dụng nội bộ tính hoa hồng chạy trên VM, dùng PostgreSQL tự cài, hay bị đầy ổ đĩa.
- Phần mềm quản lý văn bản tự viết từ 2016, đầy lỗi, có nhiều SaaS thay thế trên thị trường.
- Một server báo cáo cũ mà log cho thấy 8 tháng qua không ai truy cập.
- Hệ thống lưu trữ hồ sơ bệnh án của một bệnh viện, chịu ràng buộc pháp lý về nơi lưu dữ liệu.
Bài 3 — Suy nghĩ mở rộng. Trong ví dụ BeautyMart, nếu bạn là kỹ sư phụ trách, hãy đề xuất một roadmap 3 giai đoạn (mỗi giai đoạn 1–2 câu) để đưa họ từ Rehost ban đầu tới một kiến trúc tối ưu chi phí và ổn định.
Gợi ý đáp án bài 1: (1) Rehost — gấp, đơn giản; (2) Replatform — chuyển sang RDS để hết cảnh đầy ổ đĩa; (3) Repurchase — mua SaaS thay thế; (4) Retire — không ai dùng, tắt luôn; (5) Retain — ràng buộc pháp lý về data residency.
Tóm tắt
Framework 6 Rs là bộ công cụ ra quyết định cho mọi dự án cloud migration. Với mỗi workload, bạn có sáu lựa chọn: Rehost (bê nguyên lên, nhanh và ít rủi ro), Replatform (chỉnh nhẹ để hưởng managed service — thường là điểm ngọt), Repurchase (bỏ hệ thống cũ mua SaaS), Refactor (viết lại cloud-native, tốn công nhưng giá trị dài hạn), Retire (tắt cái không dùng), và Retain (giữ lại on-premise có chủ đích, thường vì tuân thủ).
Điều quan trọng nhất cần nhớ: không có "R" nào tốt nhất tuyệt đối — mỗi workload cần một quyết định riêng dựa trên giá trị kinh doanh, độ phức tạp kỹ thuật, chi phí và ràng buộc pháp lý. Quy trình đúng luôn bắt đầu bằng kiểm kê danh mục, đánh giá từng workload, gán chiến lược, chia wave, migrate, rồi tối ưu. Rehost nhanh nhưng đừng dừng ở đó; Refactor mạnh nhưng đừng lạm dụng; và Retain hay Retire là những quyết định trưởng thành chứ không phải thất bại. Nắm chắc 6 Rs, bạn đã có tấm bản đồ để dẫn dắt bất kỳ hành trình lên mây nào.