Hiện Đại Hóa Mainframe: Rewrite, Refactor Hay Replatform

Hiện đại hóa mainframe hiếm khi là một quyết định đơn lẻ. Đó là lựa chọn giữa nhiều chiến lược khác biệt, mỗi chiến lược có một hồ sơ chi phí, thời gian và rủi ro rất khác nhau, và câu trả lời đúng phụ thuộc vào mục tiêu kinh doanh của bạn chứ không phải sở thích công nghệ. Chọn “viết lại tất cả” khi một replatform là đủ, hoặc “lift and shift” khi vấn đề thực sự là mã không thể bảo trì, chính là cách các chương trình hiện đại hóa lãng phí hàng triệu.

Hướng dẫn này so sánh các chiến lược hiện đại hóa chính, khi nào mỗi chiến lược hợp lý và cách lựa chọn.

TL;DR

• Các chiến lược chính là rehost, replatform, refactor, rearchitect/rewrite, replace và retire; hầu hết thường được gộp thành rehost, replatform và refactor/rewrite
• rehosting nhanh nhất và rẻ nhất nhưng thay đổi ít nhất; rewrite mang lại kết quả hiện đại nhất với chi phí và rủi ro cao nhất
• Lựa chọn đúng phụ thuộc vào các động lực kinh doanh: giảm chi phí, tính linh hoạt, rủi ro, khả năng có nhân lực và tình trạng của mã hiện có
• Hầu hết các chương trình lớn tại Anh kết hợp nhiều chiến lược trên toàn bộ hệ thống thay vì áp dụng một hướng tiếp cận cho tất cả

Vì sao phải hiện đại hóa mainframe

Các động lực nhất quán trên khắp các doanh nghiệp Anh: nguồn nhân lực COBOL và mainframe đang về hưu, chi phí vận hành mainframe cao, các hệ thống khó thay đổi nhanh, và việc tích hợp chúng với các nền tảng cloud, dữ liệu và AI hiện đại là khó khăn. Không làm gì mang theo rủi ro ngày càng tăng của riêng nó khi chuyên môn biến mất. Câu hỏi thường không phải là có nên hiện đại hóa hay không, mà là như thế nào.

Các chiến lược hiện đại hóa mainframe

Các khung của ngành liệt kê sáu hoặc bảy lựa chọn; trên thực tế chúng gom lại thành một vài lựa chọn có ý nghĩa.

Rehost (“Lift and Shift”)

Chuyển ứng dụng hiện có, gần như không đổi, sang hạ tầng mới, ví dụ mô phỏng môi trường mainframe trên cloud hoặc phần cứng phổ thông. Mã COBOL về cơ bản giữ nguyên.

• Ưu điểm: Lựa chọn nhanh nhất và chi phí thấp nhất; rủi ro triển khai thấp; thoát ngay khỏi chi phí phần cứng và bản quyền mainframe.
• Nhược điểm: Gần như không thay đổi gì về mã. Bạn vẫn có COBOL, vẫn có vấn đề nhân lực, và đạt được rất ít tính linh hoạt. Đó là một biện pháp chi phí, không phải hiện đại hóa bản thân phần mềm.
• Phù hợp nhất cho: Các tổ chức cần thoát khỏi phần cứng mainframe nhanh chóng và trì hoãn việc hiện đại hóa sâu hơn.

Replatform

Chuyển sang nền tảng mới với một số điều chỉnh, ví dụ biên dịch lại COBOL để chạy trên Linux hoặc trên cloud, hoặc chuyển cơ sở dữ liệu từ DB2 sang một tương đương hiện đại, mà không viết lại logic nghiệp vụ.

• Ưu điểm: Lợi ích đáng kể về hạ tầng và chi phí với nỗ lực vừa phải; giữ nguyên logic nghiệp vụ đã được kiểm chứng; rủi ro thấp hơn rewrite.
• Nhược điểm: Ứng dụng về cơ bản vẫn là ứng dụng cũ; lợi ích về tính linh hoạt bị hạn chế và vấn đề nhân lực ở cấp độ mã vẫn tồn tại.
• Phù hợp nhất cho: Các tổ chức muốn lợi ích cloud và chi phí trong khi vẫn bảo toàn logic đang hoạt động và hạn chế rủi ro.

Refactor

Tái cấu trúc và cải thiện mã hiện có, và thường chuyển đổi nó sang một ngôn ngữ hiện đại, mà không thay đổi hành vi bên ngoài. Đây là nơi việc chuyển đổi tự động từ COBOL sang ngôn ngữ hiện đại phù hợp, tạo ra mã có thể bảo trì bằng một ngôn ngữ có nguồn lập trình viên dồi dào.

• Ưu điểm: Giải quyết vấn đề nhân lực bằng cách chuyển sang ngôn ngữ chủ đạo; cải thiện khả năng bảo trì; giữ nguyên hành vi; có thể thực hiện dần dần.
• Nhược điểm: Nỗ lực lớn hơn rehost hoặc replatform; đòi hỏi kiểm thử ngang bằng đầu ra nghiêm ngặt; chuyển đổi tự động vẫn cần con người xử lý việc truy cập dữ liệu và độ chính xác.
• Phù hợp nhất cho: Các hệ thống có logic vững chắc nhưng ngôn ngữ và cấu trúc là gánh nặng. Đây là lựa chọn tối ưu cho hầu hết các dự án hiện đại hóa COBOL.

Rearchitect / Rewrite

Xây dựng lại hệ thống, thiết kế lại kiến trúc của nó (ví dụ thành các dịch vụ hoặc thiết kế cloud-native) và triển khai lại logic nghiệp vụ trên một stack hiện đại.

• Ưu điểm: Mang lại kết quả hiện đại nhất, linh hoạt nhất và dễ bảo trì nhất; loại bỏ hoàn toàn nợ kỹ thuật tích lũy.
• Nhược điểm: Chi phí cao nhất, thời gian dài nhất và rủi ro lớn nhất; triển khai lại từ đầu hàng thập kỷ quy tắc nghiệp vụ không được ghi chép là nơi các chương trình lớn thất bại.
• Phù hợp nhất cho: Các hệ thống thực sự không còn phù hợp với mục đích, nơi doanh nghiệp cần những năng lực mà thiết kế hiện tại không thể hỗ trợ.

Replace và Retire

Thay thế hệ thống bằng một sản phẩm thương mại đóng gói sẵn (COTS) hoặc sản phẩm SaaS, hoặc loại bỏ hoàn toàn nếu không còn cần thiết.

• Ưu điểm: Có thể là kết quả tiết kiệm chi phí nhất khi có sản phẩm phù hợp hoặc chức năng đã lỗi thời.
• Nhược điểm: COTS hiếm khi khớp chính xác với logic tùy chỉnh; việc di trú và quản lý thay đổi là đáng kể; không khả thi cho các hệ thống thực sự khác biệt.
• Phù hợp nhất cho: Các chức năng phổ thông (ví dụ tính lương hoặc sổ cái tổng hợp) nơi đã có sản phẩm trưởng thành.

So sánh các chiến lược

Cách lựa chọn

Hãy để các động lực kinh doanh quyết định, không phải công nghệ:

• Động lực chính là chi phí và thoát khỏi phần cứng nhanh chóng: bắt đầu với rehost hoặc replatform.
• Động lực chính là thiếu hụt nhân lực và khả năng bảo trì: refactor, thường là chuyển đổi COBOL sang một ngôn ngữ chủ đạo.
• Động lực chính là một năng lực mới mà thiết kế cũ không thể hỗ trợ: rearchitect hoặc rewrite những phần cần thiết.
• Chức năng là loại phổ thông: cân nhắc replace.

Trên thực tế, các hệ thống lớn tại Anh kết hợp các hướng tiếp cận: replatform những phần ổn định, refactor mã khó bảo trì, rewrite số ít hệ thống cần năng lực mới, và retire những gì không còn được sử dụng. Nếu con đường được chọn liên quan đến việc chuyển đổi COBOL sang một ngôn ngữ hiện đại, tổng quan về di trú COBOL so sánh các ngôn ngữ đích như C#, Java, Python, Go, C++ và Rust, còn hướng dẫn chi phí di trú COBOL trình bày các ngân sách thực tế.

Dịch vụ di trú mainframe legacy của Mecanik bao gồm việc ngừng vận hành hạ tầng cùng với việc di trú mã, và dịch vụ hiện đại hóa COBOL bao gồm công việc refactor và chuyển đổi ở cấp độ mã.

Những điểm chính

• Hiện đại hóa mainframe là lựa chọn giữa rehost, replatform, refactor, rewrite và replace/retire, mỗi loại có một hồ sơ chi phí-rủi ro riêng biệt.
• rehost nhanh nhất và rẻ nhất nhưng hiện đại hóa ít nhất; rewrite biến đổi nhiều nhất nhưng tốn kém nhất và rủi ro nhất.
• refactoring (thường là chuyển đổi COBOL sang một ngôn ngữ hiện đại) là lựa chọn tối ưu khi logic vững chắc nhưng ngôn ngữ và nhân lực là vấn đề.
• Hầu hết các chương trình lớn kết hợp các chiến lược trên toàn hệ thống; hãy để các động lực kinh doanh, không phải sở thích công nghệ, quyết định.

Câu hỏi thường gặp (FAQ)

Sự khác biệt giữa rehosting và refactoring một ứng dụng mainframe là gì? rehosting (“lift and shift”) chuyển ứng dụng hiện có sang hạ tầng mới với mã gần như không đổi, nên nó giải quyết chi phí phần cứng nhưng không giải quyết vấn đề mã hay nhân lực. refactoring tái cấu trúc và thường chuyển đổi mã sang một ngôn ngữ hiện đại trong khi giữ nguyên hành vi, điều này giải quyết vấn đề khả năng bảo trì và nhân lực.

Nên viết lại hay di trú COBOL? Điều đó tùy thuộc vào hệ thống. Nếu logic nghiệp vụ vững chắc nhưng ngôn ngữ là gánh nặng, việc chuyển đổi (refactoring) COBOL sang một ngôn ngữ hiện đại thường có rủi ro và chi phí thấp hơn rewrite. Một rewrite toàn phần chỉ hợp lý khi thiết kế hiện tại không thể hỗ trợ các năng lực mà doanh nghiệp cần.

Chiến lược hiện đại hóa mainframe nào rẻ nhất? rehosting thường rẻ nhất và nhanh nhất, nhưng nó mang lại mức hiện đại hóa thấp nhất vì ứng dụng về cơ bản vẫn như cũ. replatforming bổ sung lợi ích vừa phải với chi phí vừa phải. rewriting là tốn kém nhất.

Chúng ta có thể hiện đại hóa mainframe theo từng bước không? Có. Hiện đại hóa từng bước (strangler fig ) thay thế hoặc chuyển đổi từng phần của hệ thống một cách lần lượt, giảm rủi ro chuyển đổi ồ ạt. Hầu hết các chương trình lớn tại Anh kết hợp các chiến lược và triển khai từng bước trên toàn hệ thống.

Rủi ro lớn nhất trong hiện đại hóa mainframe là gì? Triển khai lại hàng thập kỷ logic nghiệp vụ không được ghi chép, đặc biệt trong một rewrite toàn phần, và kiểm thử ngang bằng đầu ra không đầy đủ. Các chiến lược bảo toàn logic đã được kiểm chứng (replatform, refactor) mang ít rủi ro này hơn so với một rewrite làm lại từ đầu.