Electric Cloudがプラットフォームを拡張、メインフレームおよびマイクロサービス機能を追加

新しいElectricFlow DevOps Automationのメインフレームサポートには、デプロイ前後のネイティブなオートメーション機能とパイプラインのガバナンス、セキュリティが含まれている。新たなネイティブマイクロサービスモデルでは、マイクロサービスを第1級のオブジェクトとして扱うことにより、アプリケーションや環境から独立したモデル化が可能になると同時に、アプリケーション内部あるいはスタンドアロンでのコンテナデプロイメントの管理、コンテナランタイム環境との基盤コンポーネントの共用なども実現している。

新しいメインフレーム機能には次のようなものがある。

• JCLコードおよびREXXを含む、z /OS上でのシステムレベルのオートメーション
• メインフレームへのWebSphereおよびDB2のネイティブなデプロイメント
• Compuware ISPWとの統合による、DevOpsプラクティスのメインフレームライフサイクルへの拡張
• Compuware Topazスイートとの統合による、静的コード解析、ユニットテスト、機能テストのメインフレームパイプラインへの組込み
• APIおよびDSLを介して、上記のすべてを他のメインフレームSCCMツールに拡張する機能
• ElectricFlow用のメインフレームプラグインとして、CompuwareのISPWとTopaz、IBMのWebSphereとDB2、システム管理用のz/OSとCICS Configuration Managementを追加

Electric CloudのCTOであるAnders Wallgren氏に、メインフレームデプロイメントで実現されたパイプラインガバナンスとセキュリティ機能について詳しく聞いた。

ElectricFlowはACL(Access Control List)アーキテクチャを使用して、企業ディレクトリ(LDAP/AD)を経由した認証機能をサポートします。ACLアーキテクチャは継承とアクセス拒否をサポートします。これはRBACのスーパーセットであるため、RBACを簡単に実装することができます。プラットフォーム内のすべてのオブジェクト(アプリケーション、リリース、環境、ユーザ、グループなど)は、このようなACLによって管理されています。継承機構では、システム管理ユーザ権限を付与する必要なく、特定のオブジェクトへのアクセス権の委譲が可能になります。このような機能をメインフレームにまで拡張することにより、メインフレームはもはやオートメーションから孤立した砦ではなく、重要なコンポーネントのひとつになりました。ElectricFlowをポリシ施行エンジンとして使用することで、規則に従って承認されたアクティビティ/アクション/デプロイメントのみがメインフレームに移行可能であることを保証できます。誰かがメインフレームに直接Telnetして、パイプライン内のプロセスないしコンポーネントを変更しようとしても、ElectricFlowが次のステージでの実際の内容と意図したものとを比較することによって、そのような変更を検出(し、拒否あるいはプロセスを再実行)することが可能です。何らかの差異があれば、ElectricFlowがそれを可視化し、変更内容とパイプライン上のステージをログに記録することで、インシデント解析の最初の手掛かりを提供します。

Wallgren氏はさらに、パイプライン全体を通じて定義された入力と出力の基準(“ゲート”と呼ばれている)によって、パイプラインの各ステージでのソフトウェア開発の進行を管理していること、各ゲートは手動でも自動でも可能であること、などを説明してくれた。手動ゲートでは、ゲートを通過する進捗の承認ないし拒否する上で人手による介入を必要とするため、そのような判断を下すべきグループないし個人に対して通知が行われる。この場合、UIには、人の承認を待つためにパイプラインが“ストール”している様子が示されるが、可能であれば自動ゲートを用いることで、このプロセスを速くすることができる。例えば、ユニットテストステージのコードカバレッジ結果や、テストの成功率が所定のしきい値に達しているかどうかに基づいて、進行の承認ないし拒否を行うことが可能だ。Wallgren氏は続ける。

(静的あるいは動的な)セキュリティテストツールをパイプラインに組み込むことができます。例として、サードパーティ製ライブラリが承認済みのものであること、セキュリティ情報が期限切れでないことの確認が可能です。環境の停止や予約は、カレンダシステムを通じて管理されます。リリースの要件を満足することも必要です – アプリケーションAがサービスBの新バージョンに依存している場合、アプリケーションAのデプロイメントを、そのバージョンのサービスBが利用可能になるまで保留することができます。

メインフレームとマイクロサービスをなぜ同時に発表したのか、Wallgren氏に説明を求めた。

マイクロサービスは複雑で課題も多いので、ダッシュボードと管理機能は、それらの可視化と制御が可能なように設計されています。ディジタルトランスフォーメーションはあらゆる規模の企業に変化を促しますが、中でもメインフレーム上に重要なSoR(Systems of Record)を持つ大企業に対して、変革を強く求めます。一方で、このようなSoRを分散あるいはクラウドシステムに移行する作業は、困難な場合がしばしばあります。SoRを捨てることはできません – 戦略上の重要なコンポーネントとする方法を見出すか、もしくは安全に離脱する方法を見つけなくてはならないのです。ElectricCloudはメインフレームとディジタルトランスフォーメーションを、ひとつのエコシステムとして扱います。メインフレーム統合とマイクロサービス機能の組み合わせは、メインフレームをディジタル戦略の重要なコンポーネントにするだけでなく、マイクロサービスを介することでメインフレームを安全に、かつビジネスのスピードで移行する手段を企業に提供してくれます。(マイクロサービスの)デプロイメントパッケージはいくつかのアイテムで構成され、その中のひとつ、あるいはいくつかがz0Sに関連しています。

以前のElectricFlowは、特に大規模なコンテナインベントリを対象に、コンテナ特有のスクリプトや自動化、実行時のバージョン依存性といった課題に対処するためのものだった。新バージョンは、マイクロサービスをネイティブにサポートすると同時に、ネイティブなDocker環境やDocker Swarm、Dockerにデプロイするための一連のプラグインを新たに提供する。ElectricFlow DevOps Insightsには新たにダッシュボードが加わり、指定時間内にデプロイされたマイクロサービスに関する情報を、環境あるいはクラスタ毎に提供する。マイクロサービスダッシュボードでは、成功や失敗、最も多くデプロイされたマイクロサービス、最も多く利用されているクラスタなどに分類することができる。DevOps Insightsは、ElectircFlowによってデプロイされたマイクロサービスの数と、直接デプロイされた数に関する詳細を提供する。

Electric CloudのユーザであるSOMOSでは、米国およびカナダ内の4,100万のフリーダイヤル番号の管理に、30年以上にわたってメインフレームを使用していた。その同社が先頃、30年使用したこのメインフレームアプリケーションからの移行を決定した。同社のスクラムマスタであるGray McKay氏は次のように言う。

数多くあった課題のひとつが、マイクロサービスアーキテクチャへの移行と、現代的なDevOpsの文化とSOMOS環境の構築をいかに両立させるか、ということでした。当社がElectric CloudのElectricFlowを選んだのは、コンテナ化されたワークロードとメインフレームのワークロードの両方をサポートしていることに加えて、そのようなワークロードの開発環境と運用環境への展開をすべてコーディネート可能であるからです。