Tác giả: Rolf Sabsch, Cheryl du Preez, Vinoth Kumar Natarajan, and Yann Kindelberger
Ngày phát hành: 10 APR 2026
Chuyên mục: AWS Transform, Generative AI, Mainframe & Legacy, Mainframe Migration

Giới thiệu

Nhiều doanh nghiệp trên toàn thế giới phụ thuộc vào các ứng dụng mainframe PL/I để vận hành các hoạt động quan trọng như ngân hàng, xử lý yêu cầu bảo hiểm và dịch vụ chính phủ. PL/I chiếm khoảng 5% tổng số ứng dụng (Tận dụng công nghệ biên dịch để tối ưu hóa đầu tư trên System z), chủ yếu trong lĩnh vực dịch vụ tài chính, bảo hiểm và khu vực công, chứng tỏ khả năng phục hồi đáng kể qua nhiều thập kỷ. Tuy nhiên, các tổ chức đang đối mặt với những thách thức ngày càng tăng bao gồm sự thu hẹp của nguồn nhân lực chuyên môn PL/I, chi phí vận hành tăng cao và nhu cầu về sự linh hoạt lớn hơn để phản ứng nhanh chóng với các điều kiện thị trường thay đổi.

Hỗ trợ ngôn ngữ PL/I trong AWS Transform for mainframe giúp khách hàng tăng tốc hành trình hiện đại hóa mainframe của họ. Khả năng mới này cung cấp chuyển đổi mã được hỗ trợ bởi AI, giúp giảm thiểu rủi ro vận hành, bảo toàn logic nghiệp vụ và cho phép kiến trúc cloud-native. Bài viết blog kỹ thuật này mô tả mô hình reimagine có thể áp dụng cho các ứng dụng PL/I.

Bối cảnh

Thách thức hiện đại hóa PL/I

Các tổ chức hiện đại hóa hệ thống mainframe dựa trên PL/I thường gặp phải những thách thức trong bốn lĩnh vực chính:

Thiếu hụt nhân tài: Bối cảnh nhân tài mainframe đặt ra một cân nhắc chiến lược quan trọng cho các tổ chức. Với các nhà phát triển PL/I giàu kinh nghiệm đang đến tuổi nghỉ hưu và rất ít sinh viên khoa học máy tính mới quen thuộc với các ngôn ngữ mainframe, khoảng cách kiến thức đe dọa tính liên tục của hoạt động.

Độ phức tạp của việc chuyển đổi thủ công: Các phương pháp viết lại truyền thống tốn thời gian, tốn kém và dễ mắc lỗi. Chuyển đổi thủ công sang Java thường mất 24–30 tháng đối với các ứng dụng lớn, với chi phí thường vượt quá 15 triệu đô la và rủi ro gián đoạn kinh doanh đáng kể. Logic nghiệp vụ phức tạp ẩn sâu trong mã PL/I, thường thiếu tài liệu rõ ràng, khiến quá trình hiện đại hóa vốn đã khó triển khai hiệu quả.

Quản lý rủi ro kinh doanh: Các ứng dụng quan trọng xử lý hàng triệu giao dịch mỗi ngày không thể chấp nhận thời gian ngừng hoạt động kéo dài hoặc các lỗi chức năng. Một ngày hệ thống không khả dụng có thể ảnh hưởng đến hàng chục nghìn người dùng, làm chậm quá trình xử lý quan trọng và khiến các tổ chức mất hàng triệu đô la doanh thu và các khoản phạt theo quy định.

Nợ kỹ thuật: Hàng thập kỷ tích lũy các thay đổi mã, bản vá và các quy tắc nghiệp vụ không được ghi lại khiến việc hiểu logic ứng dụng trước khi hiện đại hóa trở nên khó khăn. Trong nhiều trường hợp, hơn 40% quy tắc nghiệp vụ chỉ được nhúng trong mã mà không có tài liệu hỗ trợ, tạo ra những rào cản đáng kể cho việc chuyển đổi thành công.

Tổng quan về ngôn ngữ PL/I

PL/I là một ngôn ngữ thủ tục đa năng, mục đích chung, thường được sử dụng trong môi trường mainframe của IBM. Được thiết kế như một sự kết hợp giữa các tính năng của COBOL và FORTRAN, PL/I cung cấp các khả năng nâng cao bao gồm con trỏ, cấp phát bộ nhớ động và cấu trúc dữ liệu phức tạp. Tính linh hoạt này đã làm cho PL/I trở nên lý tưởng cho các ứng dụng nghiệp vụ phức tạp yêu cầu cả sức mạnh tính toán và xử lý dữ liệu, giải thích sự phổ biến liên tục của nó trong tài chính, bảo hiểm và chính phủ. Tuy nhiên, các khả năng số học con trỏ và cấp phát bộ nhớ động của nó làm cho việc dịch tự động phức tạp hơn so với COBOL.

Áp dụng mô hình Reimagine cho PL/I

Mô hình reimagine chuyển đổi các ứng dụng mainframe hiện có thành các microservice cloud-native thông qua phương pháp ba giai đoạn. Cách tiếp cận này được trình bày chi tiết trong bài viết đồng hành của chúng tôi, Reimagine các ứng dụng mainframe của bạn với Agentic AI và AWS Transform, với phần này tập trung vào việc triển khai cụ thể PL/I:

• Kỹ thuật đảo ngược để trích xuất logic nghiệp vụ và các quy tắc từ mã PL/I hiện có bằng cách sử dụng AWS Transform for mainframe.
• Kỹ thuật chuyển tiếp để tạo cả đặc tả dịch vụ và mã nguồn bằng cách sử dụng AI Agents / Kiro.
• Triển khai và kiểm thử để triển khai các artifact được tạo ra cho AWS bằng cách sử dụng Infrastructure as Code và để kiểm thử chức năng của ứng dụng đã hiện đại hóa.

Hình 1: Kỹ thuật đảo ngược với AWS Transform: Hiểu hệ thống hiện tại

Kỹ thuật đảo ngược với AWS Transform: Hiểu hệ thống hiện tại

Hỗ trợ PL/I của AWS Transform cho phép phân tích tự động các codebase mainframe ở quy mô lớn. Khi AWS Transform được áp dụng cho một ứng dụng, nó tạo ra:

• Trích xuất quy tắc nghiệp vụ — xác định logic xác thực, điều kiện xử lý và các quy tắc định tuyến dữ liệu được nhúng trong mã nguồn
• Ánh xạ phụ thuộc — theo dõi tất cả các chương trình, copybook và các phụ thuộc tệp trên toàn ứng dụng
• Tạo tài liệu — tạo ra các mô tả có cấu trúc, dễ đọc của đầu vào và đầu ra, bố cục bản ghi và luồng xử lý

Đầu ra là một artifact có cấu trúc mô tả những gì hệ thống thực hiện, độc lập với cú pháp PL/I, đóng vai trò là đầu vào chính cho giai đoạn triển khai.

Kỹ thuật chuyển tiếp với Kiro: Triển khai trong kiến trúc hiện đại

Đầu ra là một artifact có cấu trúc, độc lập với cú pháp, nắm bắt những gì hệ thống thực hiện, đóng vai trò là đầu vào chính cho giai đoạn triển khai. Bằng cách định nghĩa đặc tả ngôn ngữ tự nhiên mô tả hành vi mong muốn và kiến trúc mục tiêu, các nhóm tạo ra các giải pháp phù hợp với ngôn ngữ mới từ đầu. Kiro sau đó tự động tạo mã, các mẫu hạ tầng và các script triển khai phù hợp với các đặc tả đó.

Các nhóm phát triển tạo ra tài liệu hướng dẫn cụ thể cho dự án cung cấp cho Kiro sự hiểu biết liên tục về ngăn xếp công nghệ mục tiêu, các mô hình kiến trúc, quy ước đặt tên và triết lý di chuyển. Kiro áp dụng các quyết định kiến trúc nhất quán trên toàn bộ dự án, cho dù tạo một trình phân tích cú pháp Python, dịch vụ xác thực C#, mẫu AWS CloudFormation hay truy vấn Amazon Redshift SQL.

Kiro cấu trúc việc triển khai qua ba giai đoạn:

1. Định nghĩa yêu cầu — dịch đầu ra của AWS Transform thành các đặc tả chính thức, có thể theo dõi cho từng microservice hoặc thành phần mục tiêu
2. Thiết kế — tạo ra các bản thiết kế kiến trúc, mô hình dữ liệu và hợp đồng giao diện phù hợp với kiến trúc AWS mục tiêu
3. Triển khai — tự động tạo mã và hạ tầng, với các nhà phát triển xem xét đầu ra và xác thực chúng theo các đặc tả đã định nghĩa

Luồng công việc này được thiết kế để cung cấp khả năng truy xuất nguồn gốc đầy đủ của logic nghiệp vụ từ AWS Transform đến triển khai cuối cùng, điều này rất quan trọng đối với các khối lượng công việc quan trọng đòi hỏi tính đúng đắn chức năng đã được xác minh. Trong suốt cả ba giai đoạn, việc xác thực của con người vẫn là điều cần thiết.

Chuyển đổi vòng đời giao dịch thẻ tín dụng từ CardDemo

Bài viết blog này sử dụng AWS CardDemo, mô phỏng một hệ thống quản lý thẻ tín dụng bao gồm quản lý tài khoản, xử lý giao dịch và tạo sao kê, cho nỗ lực hiện đại hóa này. Để minh họa mô hình reimagine, chúng tôi đã chọn một luồng nghiệp vụ hoàn chỉnh bao gồm cả xử lý trực tuyến và xử lý hàng loạt: vòng đời giao dịch hàng ngày. Chi tiết về các thành phần mục tiêu được mô tả trong phần sau.

Trực tuyến: Khởi tạo giao dịch

Trong giờ làm việc, hai chương trình trực tuyến CICS cung cấp dữ liệu cho pipeline xử lý hàng loạt. COTRN02C cung cấp màn hình 3270 tương tác để nhập giao dịch thẻ tín dụng, xác thực từng giao dịch với các tệp tham chiếu chéo thẻ và tệp master tài khoản trước khi ghi vào tệp TRANSACT VSAM. COBIL00C cho phép thanh toán hóa đơn, tạo bản ghi giao dịch thanh toán và cập nhật số dư tài khoản. Cả hai chương trình đều ghi vào cùng một tệp TRANSACT VSAM, tích lũy khối lượng hàng ngày để xử lý qua đêm.

Xử lý hàng loạt: Cuối ngày

Hai công việc xử lý hàng loạt xử lý các giao dịch tích lũy:

POSTTRAN chạy hàng đêm và đọc tệp giao dịch hàng ngày. Nó xác thực từng bản ghi với dữ liệu tham chiếu chéo thẻ và tài khoản — kiểm tra tính hợp lệ của thẻ, giới hạn tín dụng và ngày hết hạn. Các giao dịch hợp lệ được đăng vào các tệp master với số dư danh mục được cập nhật, trong khi các giao dịch không hợp lệ được định tuyến đến một tệp từ chối. Điều này đại diện cho một mô hình mainframe cổ điển: xử lý tệp tuần tự với định tuyến có điều kiện.

CREASTMT chạy hàng đêm sau POSTTRAN và tuân theo bốn bước tuần tự. Nó khởi tạo một cluster VSAM tạm thời, sắp xếp các giao dịch theo số thẻ, tải dữ liệu đã sắp xếp và tạo sao kê tài khoản ở định dạng văn bản và HTML bằng cách kết hợp các giao dịch với dữ liệu bổ sung.
Điều này minh họa một pipeline xử lý hàng loạt nhiều bước với việc dàn dựng trung gian, một mô hình phổ biến trong các khối lượng công việc báo cáo mainframe.

Sơ đồ sau minh họa luồng trên các lớp trực tuyến, dữ liệu và xử lý hàng loạt:

Hình 2: CardDemo: Luồng giao dịch

Giai đoạn 1: Kỹ thuật đảo ngược — Trích xuất logic nghiệp vụ với AWS Transform

Trước khi bất kỳ mã hiện đại nào có thể được viết, codebase PL/I hiện có phải được hiểu đầy đủ. AWS Transform đã thực hiện phân tích sau trên chuỗi xử lý hàng loạt:

• Trích xuất quy tắc nghiệp vụ — Xác định logic xác thực được nhúng trong mã nguồn PL/I: kiểm tra giới hạn tín dụng, xác thực hết hạn tài khoản, tra cứu tham chiếu chéo thẻ và định tuyến có điều kiện xác định xem giao dịch có được đăng hay bị từ chối.
• Ánh xạ phụ thuộc — theo dõi tất cả các tệp, copybook và các phụ thuộc chương trình. Đối với POSTTRAN, điều này cho thấy các phụ thuộc vào năm tệp VSAM và đầu ra từ chối. Đối với CREASTMT, nó ánh xạ pipeline bốn bước và các phụ thuộc chéo tệp trên dữ liệu giao dịch, tham chiếu chéo, tài khoản và khách hàng.
• Tài liệu bố cục bản ghi — nắm bắt các định dạng bản ghi có độ dài cố định (giao dịch 350 byte, tài khoản 300 byte, từ chối 430 byte với mã lỗi nhúng) là rất quan trọng để di chuyển dữ liệu chính xác sang bộ nhớ cloud-native.

Đầu ra nắm bắt “cái gì” của hệ thống — các mô tả có cấu trúc về hành vi nghiệp vụ, cấu trúc dữ liệu và logic xử lý, độc lập với cú pháp PL/I, đóng vai trò là đầu vào chính cho giai đoạn kỹ thuật chuyển tiếp.

Hình 3: AWS Transform: Logic nghiệp vụ PL/I được trích xuất

Giai đoạn 2: Kỹ thuật chuyển tiếp — Từ quy tắc nghiệp vụ đến đặc tả dịch vụ

Trong khi AWS Transform trích xuất các quy tắc nghiệp vụ chi tiết trên codebase PL/I, có khả năng trải rộng hàng trăm chương trình, định nghĩa copybook và tệp, Kiro tổng hợp chúng thành các mô hình miền gắn kết. Bước kỹ thuật chuyển tiếp này hợp nhất logic phân tán thành các đặc tả dịch vụ thống nhất nắm bắt các khả năng nghiệp vụ thiết yếu, độc lập với cả triển khai PL/I và bất kỳ kiến trúc mục tiêu nào.

Yêu cầu — Mỗi quy tắc nghiệp vụ được trích xuất trở thành một yêu cầu có thể theo dõi. Chuỗi xác thực của COTRN02C (tra cứu thẻ → xác minh tài khoản → kiểm tra giới hạn tín dụng → kiểm tra hết hạn) được ánh xạ tới các yêu cầu rõ ràng cho Dịch vụ xác thực giao dịch, mỗi yêu cầu có thể truy xuất nguồn gốc từ tài liệu PL/I gốc.

Thiết kế — Kiro đã tạo ra các ranh giới dịch vụ, hợp đồng API và mô hình dữ liệu tái hình dung các mô hình xử lý hiện có:

• Xử lý hàng loạt POSTTRAN → xử lý theo sự kiện: Xác thực dựa trên tệp tuần tự được phân tách thành một trình tiêu thụ sự kiện xác thực các giao dịch riêng lẻ khi chúng đến qua streaming, thay thế mô hình xử lý hàng loạt qua đêm.
• Xử lý hàng loạt CREASTMT → báo cáo theo yêu cầu: Pipeline sắp xếp và tạo bốn bước được chuyển đổi thành một luồng đồng bộ hóa dữ liệu gần thời gian thực. Các giao dịch đã xử lý hiện cung cấp dữ liệu cho một kho phân tích để báo cáo dựa trên bảng điều khiển, thay thế đầu ra tệp tĩnh.
• Thiết bị đầu cuối COTRN02C → API được container hóa: Nhập giao dịch dựa trên màn hình 3270 được thiết kế lại thành một REST API được hỗ trợ bởi giao diện web hiện đại, cho phép truy cập 24/7 ngoài giờ làm việc của mainframe.

Phân tích nhiệm vụ — Mỗi dịch vụ được phân tách thành các nhiệm vụ triển khai, tạo ra một backlog có cấu trúc để nhà phát triển xem xét và hoàn thành.

Giai đoạn 3: Kỹ thuật chuyển tiếp — Áp dụng các mô hình kiến trúc Cloud-Native

Với các đặc tả dịch vụ hợp nhất từ Giai đoạn 2 làm nền tảng, Kiro hiện định nghĩa cách hệ thống hiện đại hóa sẽ hoạt động trong kiến trúc cloud-native.

Sử dụng Chế độ Vibe của Kiro trong cách tiếp cận dựa trên đặc tả, các đặc tả dịch vụ được mở rộng và tinh chỉnh để kết hợp các nguyên tắc kiến trúc chính sau. Chuyển đổi này chuyển từ xử lý hàng loạt mainframe sang kiến trúc dựa trên sự kiện, dựa trên dịch vụ được xây dựng trên các dịch vụ AWS.

Các chuyển đổi kiến trúc chính:

• Lưu trữ dữ liệu Cloud-Native: Amazon RDS for PostgreSQL thay thế cấu trúc tệp VSAM gốc
• Nhập dữ liệu theo sự kiện: xử lý tệp được chuyển đổi thành DMS change data capture
• Bảng điều khiển thời gian thực thông qua Amazon Quick Suite
• Kiến trúc dịch vụ được container hóa: Xử lý giao dịch PL/I được chuyển đổi thành microservice .Net được container hóa trên Amazon Elastic Container Service Fargate

Ngoài tệp hướng dẫn, định nghĩa kiến trúc cơ bản sẽ được sử dụng, các lời nhắc mục tiêu hướng dẫn Kiro áp dụng các mô hình cụ thể cho từng thành phần. Ví dụ, khi chuyển đổi hệ thống con báo cáo, lời nhắc được sử dụng nhấn mạnh sự thay đổi từ tạo tệp hàng loạt sang phân tích thời gian thực.

Sau khi áp dụng các mô hình kiến trúc này thông qua tinh chỉnh, Kiro tạo ra các đặc tả được cập nhật sẵn sàng cho việc tạo mã trong Giai đoạn 4.

Giai đoạn 4: Kỹ thuật chuyển tiếp – Tạo mã và triển khai hạ tầng

Sau khi xác thực đặc tả, Kiro chuyển sang giai đoạn triển khai, nơi nó tạo mã và hạ tầng dưới dạng mã ở chế độ hướng dự án. Kiro có thể tự động hoàn thành các nhiệm vụ triển khai trong khi các nhà phát triển tập trung vào việc xem xét mã được tạo, cung cấp phản hồi và xác thực việc triển khai theo các yêu cầu. Quan trọng đối với quá trình này là các tệp hướng dẫn, cung cấp cho Kiro kiến thức dự án liên tục bao gồm các quy ước, thư viện, tiêu chuẩn và lựa chọn hạ tầng, duy trì sự tuân thủ kiến trúc nhất quán.

Kết quả của quá trình này được hình dung trong sơ đồ kiến trúc này, và các thành phần chính được làm nổi bật.

Hình 4: Sơ đồ kiến trúc: Xử lý giao dịch hàng loạt PL/I

Kích hoạt giao dịch:

• Dựa trên tệp/Liên quan đến di chuyển: VSAM sang Lưu trữ Cloud-Native: Các tệp VSAM được sử dụng bởi POSTTRAN và CREASTMT được di chuyển sang lưu trữ cloud-native.
• Dựa trên sự kiện: Giao diện người dùng giao dịch (Nhập dữ liệu tương tác): Kênh này cho phép nhập giao dịch và quản lý tài khoản theo thời gian thực, do người vận hành điều khiển.

Xử lý hạ nguồn và theo sự kiện:

• Từ Aurora, dữ liệu đi vào cùng một pipeline hạ nguồn như dữ liệu được nhập từ tệp: DMS nắm bắt các sự kiện thay đổi, xuất bản chúng lên Amazon Kinesis Data Streams, các hàm AWS Lambda xử lý các sự kiện và kết quả được ghi vào Amazon Redshift để báo cáo và phân tích.
• Các sự kiện thay đổi được xuất bản lên Amazon Kinesis Data Streams, cung cấp một kênh sự kiện bền vững, thông lượng cao.
• Các hàm AWS Lambda tiêu thụ các sự kiện từ Kinesis và thực hiện các hoạt động dữ liệu tương ứng, bao gồm Load, Insert, Update và Delete, đối với Amazon Redshift gần thời gian thực.
• Hàm Fact Lambda bổ sung quản lý các bản cập nhật sao kê trong bảng Tài khoản PostgreSQL, phản ánh logic xử lý sau giao dịch từ công việc POSTTRAN gốc.

Báo cáo thời gian thực:

• Đầu ra tạo sao kê của CREASTMT, trước đây được tạo dưới dạng tệp văn bản và HTML tĩnh, hiện được phục vụ thông qua Amazon Quick Suite được kết nối với kho dữ liệu Amazon Redshift.

Kiến trúc này giảm độ trễ truyền thống qua đêm giữa xử lý giao dịch và báo cáo, cho phép phân tích kịp thời và các quyết định kinh doanh nhanh hơn.

Giai đoạn 5: Triển khai và kiểm thử giải pháp cuối cùng — Truy cập trực tiếp AWS và Chế độ Vibe

Tạo một phiên bản ban đầu của mã thông qua phát triển dựa trên đặc tả chỉ là khởi đầu. Hai khả năng bổ sung trong Kiro là cần thiết để đạt được một ứng dụng được triển khai và chạy hoàn chỉnh.

Truy cập trực tiếp dịch vụ AWS
Kiro có thể chạy các lệnh shell và tương tác trực tiếp với các dịch vụ AWS thông qua AWS CLI, loại bỏ chu trình sao chép-dán thủ công giữa một thiết bị đầu cuối và AI. Trong dự án này, Kiro đã tự động:

• Truy vấn Amazon Redshift qua aws redshift-data execute-statement để kiểm tra lược đồ bảng, số hàng và giá trị dữ liệu.
• Sử dụng Amazon CloudWatch để giám sát, Kiro đã theo dõi CloudWatch Logs để chẩn đoán lỗi tác vụ Lambda và Amazon ECS.
• Mô tả định nghĩa tác vụ ECS để xác minh cấu hình biến môi trường.
• Liệt kê các kết nối VPC và tác vụ DMS để xác nhận trạng thái hạ tầng.
• Kiểm tra các chính sách vai trò AWS IAM để xác định các quyền bị thiếu.

Truy cập trực tiếp này cho phép chẩn đoán từ đầu đến cuối trong một lượt hội thoại duy nhất — đọc nhật ký lỗi, truy vấn cơ sở dữ liệu, kiểm tra chính sách IAM, sửa mã.

Chế độ Vibe (Tự động)
Chế độ vibe của Kiro cho phép một quy trình làm việc phát triển hoàn toàn theo hội thoại, nơi nhóm mô tả các vấn đề bằng ngôn ngữ tự nhiên và Kiro tự động giải quyết chúng trên nhiều tệp và dịch vụ. Hai ví dụ đại diện minh họa chiều sâu của khả năng này:

Lỗi mô hình dữ liệu:

“Bạn có thể kiểm tra tại sao truy vấn Amazon Redshift không trả về kết quả nào cho Giao dịch được chèn từ Lambda sau khi xử lý Tác vụ DMS không?”
Kiro đã chạy SQL đối với Amazon Redshift thông qua Data API, phát hiện ra rằng fact_transaction.account_key chứa các khóa tự nhiên trong khi dim_account.account_key chứa các khóa thay thế, xác định lỗi trong Fact Lambda và sửa logic tra cứu khóa.

Sự cố quyền IAM:

“Dịch vụ ECS trả về 500 trên POST /api/v1/transactions”
Kiro đã theo dõi Amazon CloudWatch Logs, xác định KMSAccessDeniedException khi xuất bản lên Kinesis, truy tìm nó đến một quyền IAM bị thiếu trong mẫu CloudFormation, thêm kms:GenerateDataKey và kms:Decrypt vào vai trò tác vụ ECS, và xác định rằng bản sửa lỗi kiến trúc chính xác là ngăn dịch vụ ECS xuất bản trực tiếp lên Kinesis — vì DMS xử lý trách nhiệm đó.

Mỗi tương tác bao gồm Kiro đọc tệp, chạy lệnh AWS CLI, phân tích đầu ra lỗi, sửa đổi mã trên nhiều tệp và giải thích nguyên nhân gốc rễ, tất cả trong một lượt hội thoại duy nhất.

Các ảnh chụp màn hình ghi lại hệ thống hiện đại hóa hoàn chỉnh. Giao diện người dùng giao dịch được container hóa ở bên trái cho phép nhập giao dịch theo thời gian thực thông qua giao diện web hiện đại, trong khi bảng điều khiển Amazon Quick Suite ở bên phải hiển thị phân tích và báo cáo gần thời gian thực.

Bản chất gần thời gian thực của pipeline được minh họa trong bảng điều khiển. Một giao dịch được nhập qua UI được phản ánh trong số dư tài khoản trong vòng vài giây, như được hiển thị bằng việc cập nhật số dư từ 2.234,76 đô la lên 2.534,76 đô la.

Kết luận

Sự kết hợp giữa AWS Transform và Kiro cung cấp một cách tiếp cận có cấu trúc để hiện đại hóa PL/I. AWS Transform trích xuất các quy tắc nghiệp vụ, bố cục bản ghi và logic xử lý từ mã nguồn PL/I, tạo ra tài liệu có cấu trúc về hành vi hệ thống. Kiro sử dụng tài liệu này để tạo các đặc tả ứng dụng, mã ứng dụng và cấu hình hạ tầng trên nhiều dịch vụ AWS trong khi duy trì tính nhất quán thông qua tinh chỉnh lặp đi lặp lại.

Luồng công việc này giúp giảm thời gian và nỗ lực thủ công theo truyền thống cần thiết cho các dự án hiện đại hóa mainframe. Phần di chuyển ứng dụng CardDemo liên quan đến giao dịch, được hoàn thành trong khoảng 12 giờ, minh họa tính khả thi của cách tiếp cận để chuyển đổi các ứng dụng PL/I hướng xử lý hàng loạt thành kiến trúc đám mây hướng sự kiện. Các tổ chức có codebase PL/I đáng kể có thể sử dụng các công cụ này để di chuyển các ứng dụng quan trọng sang AWS trong khi bảo toàn logic nghiệp vụ hiện có và giảm rủi ro dự án.

Các tài nguyên bổ sung về AWS Transform for mainframe và Kiro:

1. Tìm hiểu thêm về AWS Transform for mainframe
2. Dịch vụ AWS DMS
3. Làm cách nào để tự động hóa các tác vụ AWS DMS trong các khoảng thời gian cụ thể

Về tác giả

Rolf Sabsch

Rolf Sabsch là Quản lý tài khoản kỹ thuật tại Amazon Web Services có trụ sở tại Munich, Đức. Rolf đã làm việc trong lĩnh vực công nghệ hơn 17 năm, bao gồm gần 10 năm tại Allianz với vai trò Product Owner và gần 7 năm tại Accenture với vai trò IT Consultant cũng như Senior Manager. Trong vai trò hiện tại, ông giúp đỡ, tư vấn và hỗ trợ khách hàng tối ưu hóa môi trường AWS của họ.

Cheryl du Preez

Cheryl du Preez là Kiến trúc sư giải pháp chuyên gia cấp cao WW của AWS về hiện đại hóa mainframe và hệ thống cũ. Cheryl có hơn 20 năm kinh nghiệm lãnh đạo kỹ thuật trong các sáng kiến hiện đại hóa và chuyển đổi mainframe cho khách hàng trên toàn thế giới. Trong vai trò hiện tại, cô là một cố vấn đáng tin cậy, tư vấn cho khách hàng và đối tác về việc tận dụng các khả năng của AWS để hiện đại hóa mainframe bằng cách sử dụng Generative AI.

Vinoth Kumar Natarajan

Vinoth Kumar Natarajan là Kiến trúc sư giải pháp chuyên gia cấp cao về hiện đại hóa mainframe tại Amazon Web Services. Vinoth có hơn 18 năm kinh nghiệm trong phát triển ứng dụng mainframe, chuyển đổi dữ liệu và hiện đại hóa khối lượng công việc mainframe sang kiến trúc cloud-native. Trong vai trò hiện tại, ông giúp đỡ, tư vấn và hỗ trợ khách hàng trên khắp EMEA về hiện đại hóa khối lượng công việc mainframe bằng cách sử dụng các công cụ/Agentic AI.

Yann Kindelberger

Yann Kindelberger là Kiến trúc sư giải pháp chính tại Amazon Web Services. Yann đã làm việc với Mainframe hơn 23 năm, từng là Kiến trúc sư Mainframe tại IBM trong hơn 20 năm. Ông là một phần của nhóm WW làm việc về di chuyển và hiện đại hóa Mainframe lên AWS Cloud. Ông gia nhập AWS vào năm 2021 và vai trò của ông với tư cách là Kiến trúc sư giải pháp là giúp đỡ, tư vấn và hỗ trợ khách hàng di chuyển và hiện đại hóa Mainframe của họ.