Thứ Ba, 04/06/2024, 17:00 (GMT+0)

Hiểu rõ chiến lược 6Rs để di chuyển lên Cloud hiệu quả

Quay lại Trang chủ Blog
Trên trang này

Mô hình 6Rs trong chiến lược di chuyển lên đám mây (Cloud migration) là khung phương pháp được Amazon Web Services (AWS) giới thiệu, giúp doanh nghiệp xác định hướng đi phù hợp khi chuyển đổi hạ tầng sang nền tảng điện toán đám mây.

Trên thị trường, có nhiều biến thể khác như mô hình 4Rs, 5Rs của Gartner hay các mô hình mở rộng tới 7Rs và 9Rs, nhưng 6Rs vẫn được xem là cách tiếp cận toàn diện và thực tiễn nhất. 

Bộ mô hình này bao gồm 06 chiến lược chính đại diện cho các lựa chọn khi di chuyển dữ liệu và ứng dụng lên đám mây: Rehost, Replatform, Rearchitect, Repurchase, Retire và Retain. Mỗi chiến lược có mức độ phức tạp, chi phí và lợi ích tối ưu hóa khác nhau, giúp doanh nghiệp linh hoạt tùy theo mục tiêu kinh doanh và mức độ sẵn sàng công nghệ.

Việc áp dụng mô hình 6Rs được xem là nền tảng trong các dự án chuyển đổi số, bởi tính linh hoạt và khả năng thích ứng với nhiều quy mô, từ doanh nghiệp vừa và nhỏ đến tập đoàn lớn.

Trong phần tiếp theo, từng “R” sẽ được VNPT Cloud phân tích chi tiết, nêu rõ trường hợp áp dụng, ưu nhược điểm và hướng dẫn từng bước triển khai. Sau khi nắm vững mô hình này, doanh nghiệp sẽ có cái nhìn rõ ràng để đánh giá, lập kế hoạch và thực hiện chiến lược di chuyển lên cloud hiệu quả, tối ưu chi phí và hiệu năng vận hành.

Rehost (Di chuyển nguyên trạng)

Rehost là chiến lược đơn giản nhất trong mô hình 6Rs, bao gồm việc di chuyển ứng dụng và dữ liệu lên đám mây mà không thay đổi kiến trúc hay mã nguồn. Vì vậy, Rehost còn được gọi là Lift and Shift (nâng và chuyển).

Chiến lược này thường là lựa chọn đầu tiên cho các doanh nghiệp muốn nhanh chóng tận dụng lợi ích của điện toán đám mây. Mục tiêu của Rehost là chuyển các ứng dụng tại chỗ (on-premises) sang cloud một cách nhanh chóng, giúp tiết kiệm thời gian và chi phí ban đầu mà không cần thiết kế lại ứng dụng.

Khi nào nên sử dụng Rehost 

  • Doanh nghiệp cần di chuyển nhanh do hạn chế về thời gian hoặc áp lực chi phí.
  • Công ty muốn mở rộng quy mô nhanh mà chưa quan tâm đến các tính năng của cloud-native.

Ưu điểm của Rehost

  • Nhanh chóng: Di chuyển ứng dụng và dữ liệu lên cloud trong thời gian ngắn. 
  • Tiết kiệm chi phí: Tiết kiệm chi phí khởi tạo nhờ giữ nguyên kiến trúc và mã nguồn hiện tại, không phải đầu tư thiết kế lại toàn bộ hệ thống.
  • Đơn giản và dễ thực hiện: Quá trình di chuyển ít phức tạp, giúp doanh nghiệp nhanh chóng tận dụng lợi ích của điện toán đám mây.

Hạn chế của Rehost

  • Tối ưu hạn chế: Không tận dụng được đầy đủ các tính năng của điện kiến trúc đám mây như khả năng mở rộng linh hoạt và dịch vụ quản lý, nên hiệu suất và chi phí chưa được cải thiện tối đa.
  • Kỹ thuật: Có thể duy trì các vấn đề và bất cập của hệ thống cũ lên môi trường cloud.
rehost.jpg

Replatform (Điều chỉnh nền tảng)

Replatform còn gọi là “Lift, Shift and Tweak”. Replatform là chiến lược di chuyển ứng dụng lên đám mây bằng cách tinh chỉnh một số thành phần để tận dụng các tính năng của cloud, mà không cần thiết kế lại toàn bộ hệ thống. Cách tiếp cận này nằm giữa sự đơn giản của Rehost (nâng & chuyển) và tối ưu của Rearchitect (tái cấu trúc). Chiến lược này vừa đảm bảo tốc độ triển khai, vừa mang lại hiệu quả về mặt hiệu suất. 

Ví dụ về Replatform:

  • Chuyển SQL Server tự quản lý sang Cloud Database để giảm công sức vận hành, backup, cập nhật.
  • Di chuyển ứng dụng web lên container và chạy trên Kubernetes thay vì chạy trên VM truyền thống để tận dụng khả năng auto-scaling.

Khi nào nên áp dụng Replatform

  • Phù hợp cho doanh nghiệp muốn tận dụng tối ưu đám mây nhưng tránh chi phí, rủi ro của tái kiến trúc hoàn toàn.
  • Thích hợp khi kiến trúc lõi của ứng dụng vẫn ổn, chỉ cần tinh chỉnh để đạt hiệu quả hơn trên môi trường cloud.

Ưu điểm của Replatform 

  • Tăng hiệu quả: Tối ưu ứng dụng để dùng các tính năng cloud-native như khả năng mở rộng và managed services.
  • Tiết kiệm chi phí: Vận hành hiệu quả hơn so với rehosting đơn thuần.
  • Giảm rủi ro: Ít rủi ro hơn so với việc tái kiến trúc toàn bộ vì cấu trúc lõi giữ nguyên.

Hạn chế của Replatform

  • Chuyển đổi hạn chế: Cải tiến có giới hạn, có thể chưa tận dụng được mọi tính năng cloud-native.
  • Cần chỉnh sửa: Một số thành phần ứng dụng có thể phải điều chỉnh hoặc viết lại để phù hợp với môi trường cloud.
replatform.jpg

Refactor (Tái kiến trúc)

Refactor hay còn gọi là Rearchitect, là việc viết lại các ứng dụng từ đầu để chúng trở nên tương thích với nền tảng đám mây. Refactor phức tạp hơn nhiều so với các phương pháp di chuyển lên đám mây khác vì đây không chỉ là việc “đưa ứng dụng lên cloud”, mà là xây lại nền móng để khai thác tối đa lợi ích của môi trường điện toán đám mây. 

Ví dụ thực tế về Refactor: Một nền tảng thương mại điện tử có lượng truy cập tăng mạnh vào mùa sale. Hệ thống monolithic cũ thường gặp lỗi quá tải. Khi chuyển sang kiến trúc microservices trên cloud, doanh nghiệp có thể tự động scale từng module, chẳng hạn như thanh toán hoặc giỏ hàng, giúp vận hành ổn định ngay cả khi lưu lượng tăng gấp 10 lần.

Khi nào nên dùng Refactor

  • Ứng dụng cần khả năng mở rộng, độ bền cao và muốn tận dụng công nghệ cloud-native như: microservices, serverless, kubernetes.
  • Doanh nghiệp đang vận hành hệ thống monolithic lớn, khó mở rộng, bảo trì nặng nề. 
  • Doanh nghiệp đang đặt mục tiêu tăng tốc đổi mới sản phẩm, rút ngắn vòng đời phát triển hoặc mở rộng quy mô người dùng nhanh.

Ưu điểm của Refactor

  • Độ tin cậy cao: Tách microservices giúp giảm rủi ro “gãy toàn hệ thống” khi một phần gặp sự cố.
  • Tối ưu chi phí: sử dụng cloud theo cơ chế linh hoạt giúp doanh nghiệp tránh lãng phí tài nguyên, đặc biệt với kiến trúc serverless hoặc autoscaling.
  • Tăng tốc đổi mới: Mỗi dịch vụ được tách nhỏ, phát triển độc lập rút ngắn thời gian triển khai tính năng mới.

Hạn chế của Refactor

  • Chi phí ban đầu cao: Yêu cầu đầu tư lớn về thời gian, nhân lực và năng lực chuyên môn.
  • Phức tạp: Chuyển từ monolithic sang microservices có thể khiến hệ thống khó quan sát hơn nếu không đầu tư vào monitoring, logging và DevOps.
re-architect.jpg

Repurchase (Chuyển sang sản phẩm mới)

Repurchase còn gọi là “drop and shop”, là việc bỏ ứng dụng cũ và chuyển sang một sản phẩm mới, thường là chuyển sang giải pháp cloud-native hoặc SaaS (Software as a Service). . Đây là con đường nhanh nhất để tiếp cận công nghệ hiện đại mà không cần tốn chi phí tái cấu trúc.

Hãy hình dung: Thay vì cố sửa một chiếc xe cũ liên tục hỏng vặt, doanh nghiệp đổi sang một chiếc xe mới có bảo hành đầy đủ, an toàn hơn, chạy mượt hơn và ít tốn công bảo dưỡng hơn. 

Trên thực tế, nhiều doanh nghiệp đang sử dụng Repurchase bằng cách chuyển CRM tự xây sang Salesforce hoặc hệ thống email nội bộ sang Microsoft 365 hay Google Workspace.

Khi nào nên chọn repurchase

  • Phần mềm hiện tại đã lỗi thời. 
  • Ứng dụng nội bộ tự phát triển nhưng khó mở rộng, khó bảo trì hoặc chi phí cao. 
  • Giải pháp SaaS ngoài thị trường tốt hơn, giá tốt hơn và cập nhật nhanh hơn.
  • Doanh nghiệp muốn giảm gánh nặng IT, chuyển trách nhiệm bảo trì cập nhật sang nhà cung cấp.

Ưu điểm của repurchase

  • Tinh gọn hệ thống IT: Giảm số lượng ứng dụng cần quản lý, phần lớn gánh nặng IT chuyển sang nhà cung cấp SaaS. 
  • Tiếp cận công nghệ mới: SaaS thường xuyên cập nhật tính năng mới, doanh nghiệp có thể sử dụng ngay công nghệ mới mà không cần tự phát triển.

Hạn chế của repurchase

  • Chi phí thuê bao: Có thể tăng chi phí OPEX do mô hình thanh toán theo gói hoặc theo tháng.
  • Vấn đề về tích hợp: Đòi hỏi tích hợp với hệ thống cũ, đôi khi cần viết lại API hoặc xây thêm middleware. 
re-purchase.jpg

Retire (Loại bỏ)

Retire là chiến lược mà doanh nghiệp xác định và loại bỏ các ứng dụng, hệ thống hoặc workload không còn mang lại giá trị kinh doanh. Đây là bước quan trọng để dọn dẹp môi trường CNTT, giúp doanh nghiệp tập trung nguồn lực vào các hệ thống thực sự cần thiết, đồng thời giảm gánh nặng vận hành và chi phí.

Trước khi Retire, doanh nghiệp nên thực hiện kiểm kê toàn bộ hệ thống, phân tích tần suất sử dụng và giá trị kinh doanh của từng ứng dụng. Việc này giúp đảm bảo rằng chỉ những ứng dụng không còn giá trị mới bị loại bỏ, tránh gây ảnh hưởng đến quy trình kinh doanh hiện tại và trong tương lai. 

Khi nào nên sử dụng retire

Chiến lược này phù hợp khi một số tài sản công nghệ thông tin đã lỗi thời, trùng lặp chức năng hoặc không còn phục vụ mục tiêu kinh doanh. Việc loại bỏ chúng giúp đơn giản hóa quá trình di chuyển lên cloud.

Ưu điểm của retire

  • Giảm chi phí: Loại bỏ chi phí bảo trì, vận hành và quản lý các hệ thống cũ.
  • Đơn giản hóa hệ thống: Giảm độ phức tạp của môi trường CNTT, thu gọn phạm vi migration.

Hạn chế của retire

  • Khó xác định: Việc quyết định ứng dụng nào bị loại bỏ là rất khó, đặc biệt khi thiếu dữ liệu sử dụng rõ ràng.
  • Cần sự đồng thuận: Cần làm việc chặt chẽ với các bộ phận nghiệp vụ để đảm bảo việc loại bỏ ứng dụng không làm gián đoạn quy trình quan trọng.
retire.jpg

Retain (Giữ lại)

Retain là chiến lược mà doanh nghiệp quyết định giữ lại một số ứng dụng hoặc workload lên cloud. Quyết định này thường dựa trên các yếu tố kinh doanh, kỹ thuật hoặc quy định đặc thù khiến một số hệ thống cần phải được duy trì bên ngoài môi trường đám mây. 

Khi nào nên sử dụng retain

Retain phù hợp khi các ứng dụng gắn chặt với hạ tầng legacy khó di chuyển, hoặc yêu cầu tuân thủ (compliance) nghiêm ngặt mà môi trường cloud hiện tại chưa thể đáp ứng.

Ưu điểm của retain

  • Tuân thủ quy định: Giữ nguyên hệ thống tại chỗ giúp đảm bảo tuân thủ chặt chẽ các tiêu chuẩn về quy định và bảo mật.
  • Ổn định: Duy trì sự ổn định cho các ứng dụng nhạy cảm, tránh rủi ro vận hành. 
  • Quản lý chi phí: Tránh được chi phí di chuyển cho các hệ thống chưa sẵn sàng hoặc không mang lại lợi ích khi đưa lên cloud.

Hạn chế của retain

  • Bỏ lỡ cơ hội: Các ứng dụng được giữ lại sẽ không tận dụng được lợi ích từ dịch vụ điện toán đám mây.
  • Tăng độ phức tạp: Phải vận hành song song cả hệ thống tại chỗ (on-premise) và hạ tầng cloud.
retain.jpg

Một số lưu ý khi chuyển lên Cloud với 6Rs

Di chuyển lên cloud theo 6Rs (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) là một quá trình cần lên kế hoạch và thực hiện có hệ thống. Một số lưu ý trước khi thực thi bao gồm:

  • Đánh giá và lập kế hoạch: Kiểm kê toàn bộ ứng dụng, dữ liệu và mối quan hệ phụ thuộc để xác định chiến lược 6Rs phù hợp cho từng workload. Dự toán chi phí, đánh giá rủi ro và lập kế hoạch dự phòng giúp giảm gián đoạn và tối ưu hóa nguồn lực.
  • Sao lưu và phục hồi dữ liệu: Đảm bảo dữ liệu được bảo vệ và sao lưu để tránh mất mát hoặc sự cố ngoài ý muốn.
  • Kiểm thử và giám sát: Thực hiện kiểm thử trước, trong và sau khi di chuyển; giám sát liên tục hiệu suất, mức sử dụng và bảo mật của các ứng dụng trên cloud.
  • Quản lý giấy phép phần mềm: Đảm bảo tuân thủ các hợp đồng, tránh chi phí dư thừa và tối ưu hóa việc sử dụng phần mềm trên cloud.
  • Lưu trữ tài liệu: Lưu lại kế hoạch, thiết kế, cấu hình và kết quả kiểm thử để phục vụ kiểm toán, khắc phục sự cố và lên kế hoạch cho các dự án cloud tiếp theo.

Khi thực hiện đồng bộ các bước trên, dữ liệu và ứng dụng không chỉ được di chuyển mà vận hành cũng được tối ưu, khai thác hiệu quả từng chiến lược trong 6Rs. Nhờ đó, tổ chức tăng tốc đổi mới và nâng cao hiệu quả kinh doanh.

Nhìn lại toàn bộ “6R of cloud migration”, hãy nhớ rằng mỗi chiến lược mở ra một lối đi riêng để tiếp cận môi trường đám mây. Việc lựa chọn phù hợp là sự cân bằng giữa nhu cầu hiện tại của doanh nghiệp và tiềm năng của công nghệ đám mây để giúp quá trình di chuyển trở thành bước tiến thực sự trong hành trình phát triển và đổi mới.

VNPT Cloud hiện đang cung cấp giải pháp Cloud Migration toàn diện, hỗ trợ doanh nghiệp từ bước đánh giá hệ thống (assessment), lập kế hoạch (planning), di chuyển (migration) đến tối ưu vận hành (optimization). Với đội ngũ chuyên gia giàu kinh nghiệm, nền tảng đạt chuẩn quốc tế và hệ sinh thái dịch vụ đa dạng, VNPT Cloud giúp doanh nghiệp rút ngắn thời gian triển khai, giảm rủi ro và tối ưu chi phí ngay từ ngày đầu tiên lên Cloud.

👉 Tổ chức cần tư vấn chiến lược Cloud migration phù hợp nhất?
👉 Tìm chuyên gia đồng hành trong quá trình di chuyển lên Cloud?

Đăng ký tư vấn và dùng thử miễn phí ngay tại đây:

Chúng tôi có 4 môi trường staging, 2 môi trường production, hàng chục microservice và rất nhiều phiên bản thử nghiệm. Lúc đầu dùng VPS tưởng là đủ, nhưng rồi mỗi lần cập nhật code là một lần lo… không biết lần này ‘tháo’ có làm hỏng cái gì không?
Tại sao doanh nghiệp hiện đại cần Kubernetes?