の DevOps AWS Mainframe Modernization

メインフレームシステムには固有の課題がありますが、一般的な課題があります。DevOps フレームワークを拡張してこれらの一意の特性に対処する方法は次のとおりです。

• レガシーテクノロジースタック – メインフレームは通常、レガシーテクノロジースタックと独自のソフトウェアを使用します。これは、DevOps で使用される最新のクラウドネイティブテクノロジーとは大きく異なる場合があります。これらのレガシーシステムを DevOps パイプラインに統合するには、特殊なツールと専門知識が必要です。

• 複雑性が高い – メインフレームアプリケーションは複雑でモノリシックである傾向があり、広範な相互依存関係があります。これらのアプリケーションを分割してモダナイズすることは、モダナイズされたモジュール式のコードベースを使用するよりも難しい場合があります。たとえば、メインフレーム COBOL アプリケーションでは、プログラムに変更がない場合でも、毎回再コンパイルする必要があります。これは、コピーブックおよび関連するサブプログラムとの相互依存動作が原因です。

• レガシーツール – メインフレームは、最新の DevOps ツールとネイティブに互換性のない特殊なツールやプロセスに依存することがよくあります。統合と自動化はより複雑になり、カスタムスクリプトとコネクタが必要になる場合があります。

• 長いリリースサイクル – メインフレームは長いリリースサイクルで知られていますが、DevOps コンテキストではボトルネックになる可能性があります。メインフレームの DevOps は、安定性とコンプライアンスを維持しながら、これらのサイクルを短縮することを目指しています。メインフレームアプリケーションのリリースサイクルは 2～3 か月ですが、メインフレーム以外のモノリスアプリケーションは 3～4 週間で完了する可能性があります。この理由は、変更リクエストの変更されていない相互依存コンポーネントを評価するために必要なテスト作業の量が大きいためです。

• コンプライアンスとセキュリティの要件 – メインフレームは保険、金融、医療などの市場に共通しているため、アプリケーションは多くの場合、機密データを処理し、厳格なコンプライアンスとセキュリティ標準に従う必要があります。このガイドに記載されている DevOps フレームワークは、パイプラインのすべての段階でこれらの要件に対処します。

• スキルギャップ – メインフレーム中心の開発と運用から最新の DevOps プラクティスに移行する組織にはスキルギャップがあります。チームメンバーは、この新しい環境で効果的に作業するためにトレーニングが必要になる場合があります。

• テストの課題 – メインフレーム環境を正確にエミュレートする必要があるため、メインフレームの DevOps での自動化されたテストは複雑になる可能性があります。専用のテストツールとフレームワークが必要です。Z/OS プラットフォームで記述された COBOL プログラムが x86 プラットフォーム (Linux または Windows) で実行されると、互換性エラーが返されます。そのためには、Micro Focus Enterprise Server などの適切なツールセットを使用する必要があります。

• 文化的違い – 従来のメインフレーム文化から DevOps 文化への移行は、組織にとって大きな文化的変化になる可能性があります。DevOps は、メインフレームソフトウェア開発ライフサイクル (SDLC) の既存のプラクティスとは異なる可能性があるコラボレーション、自動化、継続的な改善を奨励します。

• ハイブリッド環境 – 多くの組織はメインフレームと最新のシステムを組み合わせて使用します。メインフレームの DevOps は、これらの多様な環境とシームレスに統合する必要があります。

の DevOps AWS Mainframe Modernization は、評価、構築、最適化の 3 つのフェーズに分類されます。次の表は、これらのフェーズが、メインフレームのモダナイゼーションジャーニー中に DevOps を効率的に有効にするための構造化されたアプローチをどのように表しているかを示しています AWS クラウド。

[Phase] (フェーズ)	コンポーネント
評価	現在の状態分析 ターゲット状態の定義
ビルド	ツールセットの設定 継続的な統合 継続的デリバリー パイプラインオーケストレーション
最適化	モニタリングとオブザーバビリティの強化 アラートと通知 自己修復システム