Giải thích chi tiết về 7R - Chiến lược dịch chuyển Cloud và bài toán tăng trưởng bền vững cho doanh nghiệp (High level)
Minh Huynh NhatCloud Migration không còn đơn thuần là một dự án chuyển đổi hạ tầng kỹ thuật. Đó là một quyết định chiến lược có thể định hình năng lực cạnh tranh của doanh nghiệp trong nhiều năm tới. (Ví dụ dự án mình đang làm Lead migartion cho O** Banking di chuyển 1800+ server lên AWS). Trong bối cảnh đó, mô hình 7Rs dần trở thành một “bản đồ kiến trúc” giúp các tổ chức đánh giá lại toàn bộ hệ thống công nghệ, tối ưu hóa tài nguyên CNTT và xây dựng nền tảng hạ tầng linh hoạt để sẵn sàng thích ứng với các kịch bản tăng trưởng dài hạn.
Mỗi chữ R đại diện cho một quyết định khác nhau trong việc xử lý hệ thống công nghệ hiện tại. Trong bài blog này, mình sẽ giúp bạn hiểu sâu về các kiến thức high-level này.
— High-level Workflow of Cloud Migration Strategy
1. Retire — Tắt bỏ hoàn toàn
Định nghĩa: Loại bỏ hoàn toàn workload, không migrate, không thay thế.
Trong hầu hết các dự án migration lớn, phân tích portfolio thường phát hiện 10–20% application thực tế không còn ai dùng — server vẫn chạy, chi phí vẫn trả, nhưng không có business value. Retire những app này là "quick win" lớn nhất: giảm ngay chi phí on-prem, giảm attack surface, và giảm số lượng workload cần migrate.
Dấu hiệu nên Retire: Không có traffic trong 90+ ngày (dữ liệu từ ADS/network monitoring), không có business owner rõ ràng, duplicate functionality với app khác, app từ dự án đã kết thúc nhưng chưa ai decommission.
Quy trình thực tế: Không bao giờ tắt server mà không confirm với business/app owner/Lead IT. Quy trình chuẩn: thông báo 30 ngày → tắt nhưng giữ snapshot 60–90 ngày → xóa hẳn. Có thể tiết kiệm 15–25% tổng chi phí migration effort chỉ bằng Retire.
2. Retain — Giữ lại on-prem
Định nghĩa: Không làm gì, giữ nguyên trên datacenter hiện tại, nhưng phải có lý do rõ ràng và được document.
"Retain" không phải để né tránh migration — nó là quyết định có chủ đích với review date cụ thể.
Lý do hợp lệ để Retain:
- Compliance/regulatory: Một số ngành (ngân hàng, y tế tại Việt Nam) yêu cầu data phải ở on-prem hoặc trong nước — chưa thể migrate cho đến khi có AWS region tại VN hoặc clarification từ cơ quan quản lý.
- Latency cực thấp: App cần sub-millisecond latency với thiết bị vật lý (industrial control system, trading system) — cloud không đáp ứng được về mặt vật lý.
- End-of-life gần: App sẽ bị thay thế hoàn toàn trong 6–12 tháng — không có ý nghĩa khi migrate.
- Dependency phức tạp chưa giải quyết được: App phụ thuộc vào mainframe hoặc legacy system chưa có giải pháp migrate.
Sai lầm phổ biến: Retain vô thời hạn không có review date. Mỗi workload Retain phải có ngày review (thường 6–12 tháng) để đánh giá lại liệu lý do Retain còn valid không.
3. Relocate — Di chuyển VMware sang VMware Cloud on AWS
Định nghĩa: Di chuyển toàn bộ VMware environment sang VMware Cloud on AWS (VMC on AWS) mà không thay đổi gì ở tầng OS, application, hoặc network policy.
Cơ chế hoạt động: VMC on AWS chạy VMware SDDC (vSphere + vSAN + NSX) trực tiếp trên bare-metal hardware của AWS, được quản lý bởi VMware. Admin vẫn dùng vCenter quen thuộc. Migration dùng VMware HCX — live migration (vMotion qua WAN) với downtime gần bằng 0. Bên AWS cung cấp dịch vụ Amazon Elastic VMware Service (Amazon EVS), giải quyết cho bài toán này.
https://docs.aws.amazon.com/evs/latest/userguide/what-is-evs.html
Khi nào chọn Relocate:
- Tổ chức đang chạy VMware nặng và muốn thoát khỏi datacenter contract sắp hết hạn.
- Team chưa sẵn sàng (về kỹ năng hoặc về thời gian) để chuyển sang EC2 native.
- Cần tốc độ — Relocate nhanh hơn Rehost nhiều vì không cần conversion.
- Muốn dùng Relocate như bước trung gian, sau đó từ từ refactor sang native AWS service.
Trade-off: Chi phí cao hơn EC2 native vì phải trả VMware license phí trên nền AWS. Không tận dụng được đầy đủ AWS managed services (RDS, Lambda, v.v.). Thường được dùng như stepping stone 2–3 năm trước khi modernize.
4. Rehost — Lift & Shift
Định nghĩa: Di chuyển application lên AWS EC2 mà không thay đổi gì về kiến trúc, OS, hoặc application code. "Nhấc lên và đặt xuống".
Công cụ chính: AWS Application Migration Service (MGN) — replication agent-based, liên tục sync block-level data, cutover window 15–30 phút, RPO gần bằng 0.
Khi nào chọn Rehost:
- Cần thoát khỏi datacenter nhanh (contract hết hạn, hardware EOL).
- App vẫn còn business value nhưng chưa có kế hoạch refactor rõ ràng.
- Muốn "get to cloud first, optimize later" — hoàn toàn hợp lý nếu có roadmap rõ ràng.
- App chạy trên OS/platform mà AWS hỗ trợ (Windows Server, RHEL, Ubuntu, v.v.).
Lợi ích: Nhanh, ít rủi ro, không cần kỹ năng cloud sâu. Ngay sau khi Rehost, vẫn có thể bắt đầu tiết kiệm chi phí nhờ right-sizing và không phải pay cho hardware maintenance.
Hạn chế: Không tận dụng được cloud-native features. App vẫn có kiến trúc monolith, không tự động scale. Coi đây là trạm dừng chân, không phải đích đến cuối cùng.
5. Replatform — Lift, Tinker & Shift
Định nghĩa: Di chuyển lên AWS với một số thay đổi nhỏ ở tầng platform — không thay đổi core architecture hay business logic, nhưng tận dụng một số managed service của AWS.
Ví dụ thực tế phổ biến:
| On-prem | Sau Replatform |
|---|---|
| MySQL trên EC2 tự quản lý | Amazon RDS MySQL (managed, tự backup, patching) |
| Tomcat trên EC2 | AWS Elastic Beanstalk (managed app server) |
| SQL Server Enterprise | RDS SQL Server (license included, giảm cost) |
| Self-managed Redis cluster | Amazon ElastiCache for Redis |
| Oracle RAW EC2 | RDS Oracle hoặc bắt đầu chuyển Aurora |
| Log aggregation tự làm | Amazon OpenSearch Service |
Khi nào chọn Replatform: Khi Rehost đơn thuần không đủ — app sẽ benefit rõ ràng từ managed service (giảm operational overhead, tăng reliability) nhưng chưa cần viết lại hoàn toàn. Đây là điểm sweet spot về effort/value cho rất nhiều workload.
Effort so với Rehost: Cần thêm testing và validation vì có thay đổi tầng platform, nhưng không cần refactor code. Thời gian migration có thể tăng 30–50% so với pure lift-and-shift.
6. Repurchase — Drop & Shop
Định nghĩa: Thay thế hoàn toàn application hiện tại bằng một sản phẩm SaaS thương mại trên cloud.
Ví dụ điển hình:
| App on-prem cũ | SaaS thay thế |
|---|---|
| CRM tự build hoặc Siebel | Salesforce |
| Exchange Server | Microsoft 365 / Google Workspace |
| SAP on-prem | SAP S/4HANA Cloud |
| HR system legacy | Workday / BambooHR |
| Helpdesk tự build | Zendesk / ServiceNow |
| Video conferencing on-prem | Zoom / Teams |
Khi nào chọn Repurchase: Khi SaaS alternative đã mature và cover đủ functionality, khi chi phí maintain app on-prem (license + infra + dev) cao hơn SaaS subscription, hoặc khi app hiện tại là commodity function (không phải core competitive advantage).
Challenge thực tế: Data migration từ app cũ sang SaaS thường phức tạp — cần cleansing, mapping, và validation. Change management với người dùng cuối cũng rất quan trọng khi UX thay đổi hoàn toàn. Licensing model mới (per-seat subscription) cần được tính toán kỹ về TCO dài hạn.
7. Refactor / Re-architect — Cloud-native
Định nghĩa: Viết lại hoặc tái kiến trúc đáng kể application để tận dụng cloud-native capabilities — containers, serverless, managed services, event-driven architecture.
Đây là chiến lược effort cao nhất nhưng long-term value lớn nhất.
Các hướng refactor phổ biến:
Containerization: Đóng gói application thành Docker container, deploy trên Amazon EKS (Kubernetes managed) hoặc ECS Fargate (serverless container). Dùng AWS App2Container để tự động phân tích Java/.NET app và generate container image + deployment artifacts. Benefit: portable, scale nhanh, deploy nhanh hơn nhiều, chi phí tối ưu hơn EC2 dedicated.
Serverless: Chuyển business logic sang AWS Lambda, API Gateway cho REST endpoints, DynamoDB hoặc Aurora Serverless cho database, EventBridge cho event routing, Step Functions cho workflow. Benefit: không phải quản lý server, auto-scale hoàn toàn, chỉ trả tiền khi có request. Phù hợp nhất cho event-driven workload, API backend, scheduled jobs.
Database modernization: Oracle/SQL Server → Aurora PostgreSQL hoặc Aurora MySQL (dùng AWS SCT + DMS). MongoDB → DynamoDB. Cassandra → Amazon Keyspaces. Benefit: giảm license cost dramatically, fully managed, built-in HA và Multi-AZ.
Microservices decomposition: Tách monolith thành independent service, mỗi service có database riêng, communicate qua SQS/SNS/EventBridge. Benefit: scale từng component độc lập, deploy independent, fault isolation.
Khi nào chọn Refactor:
- App cần scale elastically và kiến trúc hiện tại không cho phép.
- Chi phí vận hành quá cao do kiến trúc không hiệu quả.
- App là core business system cần tính sẵn sàng cao và tốc độ phát triển tính năng mới nhanh.
- Team đã đủ cloud-native skills sau Mobilize và Rehost giai đoạn đầu.
Thực tế dự án: Refactor thường được thực hiện sau khi đã Rehost — "get to cloud first, then modernize". Rất ít tổ chức Refactor trực tiếp từ on-prem mà không qua bước Rehost trước, vì rủi ro quá cao khi vừa migrate vừa viết lại.
Cách áp dụng 7Rs trong thực tế
Không có workload nào mặc định thuộc về một chiến lược cụ thể — quyết định phụ thuộc vào 4 yếu tố:
- Business value của app: app core hay peripheral? Có kế hoạch phát triển tiếp không?
- Technical complexity: app monolith hay đã modular? Có test coverage không? Dependency ra sao?
- Timeline và deadline: datacenter contract hết hạn khi nào? Budget cycle ra sao?
- Team capability: đội có đủ skill để Refactor không, hay cần Rehost trước để build confidence?
Trong một portfolio 500 app thực tế, phân bổ thường gặp: 10–20% Retire, 15–25% Retain, 35–45% Rehost, 10–20% Replatform, 5–10% Repurchase, 5–15% Refactor. Con số này thay đổi đáng kể tùy ngành và mức độ technical debt.