連携・統合によるクラウドマイグレーションガイド

まず、典型的なCEOの優先事項を見てみましょう。CEOはテクノロジーやコスト削減を注視していません。マッキンゼーによると、CEOの最優先事項は収益増加で、次に俊敏性の向上と市場投入までの時間短縮が僅差で続きます。多くの企業は、デジタルテクノロジーがこれら目標実現のための重要な達成手段であることを認識しており、その実現にCIO が貢献してくれることを期待しています。

しかし、多くの場合、CIOには最新の新しいアーキテクチャを定義できる余裕がありません。彼らは年間予算の最大80%をシステムの保守に費やしており、イノベーションに使える貴重なリソースはほとんどありません。当社が接しているCIOは、ITモダナイゼーションが必要不可欠であり、クラウドテクノロジーがそのモダナイゼーションの一部になることを認識しています。しかし、ほとんどの場合、どこから始めるかが難しい判断となります。どのような選択肢があるのでしょうか？また、どのタイプのアプリケーションとどのアプローチが最適なのでしょうか？

いくつかの単純なモデルで、クラウドへの道のりについて構造化された方法で考えることが可能なものを見てみましょう。クラウドへの機能移行は、基本的には３つの方法から選択することができます。

リフト&シフト方式

この方法では通常、既存のアプリケーションを選択して、そのままクラウド上のIaaS（infrastructure-as-a-service）に移行します。このアプローチには複数のメリットがあります。クラウドに迅速に移行でき、運用、保守、バックアップ、アップグレードが必要なデータセンター内のコンピュータでソフトウェアを実行する必要がなくなります。デメリットとしては、以前と変わらぬソフトウェアであるため、自分で操作、パッチ適用、デバッグを行わなければならないことです。この現状のままのオンプレミスアーキテクチャは、負荷時に柔軟性がなく、組込みの高可用性も備えていません。

SaaSの採用

２つ目の方法は、SaaS（software-as-a-service）アプリケーションで提供される機能を採用することです。良い例が、SalesforceやServiceNow、Marketoです。特定のビジネス機能をSaaSアプリケーションに移行すると、オンプレミスの古いアプリケーションをオフにしたり廃止したりできます。この方法のメリットは、アプリケーションがクラウドネイティブであり、料金が明確で、運用上の手間がかからないことです。デメリットとしては、これらのSaaSアプリは競合他社でも多く採用されているため、ビジネスを差別化できないことです。

クラウドネイティブ ソリューションの構築

３つ目の方法は、AWSスタックやAzureスタックなどのPaaS（platform-as-a-service）で提供されるすべての強力な機能を使用して、まったく新しいクラウドネイティブ アプリケーションを構築することです。これにより、古くなったオンプレミスのアプリケーションを縮小することもできます。主なメリットは、市場投入までの時間が短縮されることで、イノベーションのシステムに非常に適しています。また、アプリをゼロから構築することで、クラウドプロバイダーが提供する最高の機能、たとえばサービスとしてのデータベース、分析用のデータレイクとして使用できる巨大なストレージへの容易なアクセスなどを活用できます。デメリットとしては、ベンダーが特定のクラウドプロバイダーにロッキングされる危険性と、ソリューションが慎重に設計されていないと、頻繁に予測不可能なコストが簡単に激増してしまうことです。

既存環境の基部には、SoR（Systems of Record: 記録システム） と呼ばれるものがあります。財務元帳、人事システム、倉庫管理システムなど、企業の運営を維持するための基幹系システムで、あらゆるコアデータを記録し、高度に管理され、頻繁に変更されることはありません。これらのシステムでリスクを負う余裕はありませんが、競合優位性をもたらすこともありません。これらはどの企業も実行する標準的なアプリケーションですが、多くの場合、企業固有の要件に合わせて大幅にカスタマイズされています。

次に上の層を形成しているのは、SoD（Systems of differentiation:差別化システム）で、競合他社よりも優秀、迅速、安価にすることで差別化を実現するシステムです。これらは優位性をもたらすもので、通常、パッケージ化されたアプリケーションでは提供されません。その本質上、カスタムビルドされています。また、SoRよりも俊敏性と適応性が求められます。

最上層にあるのが、SoI（Systems of Innovation: イノベーションシステム）で、新しい市場、新しいチャネルへの移行をサポートし、競合他社が存在しない場所へ導きます。成功のために最大限のスピードと俊敏性を要します。

これら２つのモデルを組み合わせると、クラウド移行にどの方法をいつ使用すべきかが分かりやすくなります。

SoRはビジネスの中核であるため、非常に保守的な移行になります。これらのシステムは企業にとってビジネスクリティカルであるので、高い確率でオンプレミスに残ります。これは、非常に変更されたERPシステムを実行していたり、あるいは何年もメインフレームが変更されていないものの適切に機能し、基本機能を良い状態で維持していたりします。これらのシステムをリフト＆シフトしたり、1つずつSaaSソフトウェアに置き換えたりすることも可能ですが、ソフトウェアの重要性を考慮し、これらの移行は非常に慎重に行われ、通常は最後の段階で実施されます。

SoDとSoIもリフト＆シフトできますが、最も多くのメリットが得られるのは、最新のPaaSプラットフォームが提供する機能をフル活用することです。これらは、大規模なデータストレージ、分析、AI、UIフレームワークなどの構成要素を提供します。

現実世界では、アプリの移行はビッグバンのように発生するわけではなく、常に多種多様なアプリケーションとホスティングタイプが存在します。SoRの多くは長期間オンプレミスに残りますが、企業は新しいニーズに合わせて優れた新しいSaaSアプリを急速に採用します。そして最後に、新しいSoIが、クラウドプラットフォーム上で直接作成されます。したがって、一部はオンプレミス、一部はクラウド上のVM、一部はSaaSアプリケーション、一部は新しく構築されたクラウドアプリケーションという環境になるのです。

ホストされている環境に関係なく、エンタープライズ全体のシステムを連携するだけでなく統合することは、企業内を結び付ける中心的な役割を担います。メインフレーム、レガシー、カスタムなどの膨大な数の記録アプリケーションのほか、SaaSアプリケーション、IoTセンサーとデバイス、 モバイルアプリ開発 などの普及により、統合の必要性は高まるばかりです。

連携・統合を担うインテグレーション ソフトウェアは は、すべての環境にわたってデータを接続し、すべてのドメインを重ね合わせ、すべてのエンドポイントに到達します。ソフトウェアがデータセンターの外部でホストされるようになると、統合はオンプレミスのERM、CRM、メインフレーム、クラウドとSaaS環境、エッジデバイスとセンサー、さらに B2Bパートナーにわたって拡がり始めます。すぐに、他のソリューションを移行したときと同じ理由 ― 俊敏性、安定性、運用コストの削減の必要性により、統合ソフトウェアをモダナイズする必要性を感じるでしょう。統合はそれ自体では価値をもたらさず、アプリケーションを接続するため、組織は重要なデータがどこに存在するのか、つまりデータの重心がどこにあるのかを評価する必要があります。

新しい環境でのデータは、データセンター、任意のハイパースケーラー、またはSaaSなど、あらゆる場所に存在する可能性があるため、過去の「ワンサイズですべてに対応する」モノリス統合では、すべての統合ワークロードに適合しないことは明らかです。代わりに、接続するアプリケーションに応じて個別の統合フローでアーキテクチャの分散を開始します。この新しい現実で利用可能なオプションは次のとおりです。

オンプレミスに残す

多くの組織は当初、ESB（エンタープライズサービスバス) と連携プラットフォームを採用することで連携・統合の問題を解決していました。これらは今でも広く使用されており、多くの場合、組織のミッションクリティカルなアプリケーションを強化しています。接続されたアプリケーションがまだデータセンターにある場合、運用コストのメリットのためだけに統合ワークロードを別の場所に移行しても意味がありません。メッセージはクラウドを経由してデータセンターに戻ってくるからです。

リホスト

統合するシステムがすでにクラウドに移行されている場合、統合ワークフローも移行することは理にかなっています。これを実現する最も簡単な方法は、統合をそのままリホストすることです。これは、統合アーキテクチャを、データセンターの外部でホストされているVMにリフト＆シフトすることです。このアプローチでは運用上のメリットは得られますが、クラウドの拡張性と安定性は利用できず、まだソフトウェアを運用する必要があります。

再パッケージ化

クラウドをより活用できる別のタイプのリホストは、ソフトウェアをコンテナに再パッケージ化することです。コンテナは、必要なすべての依存関係を含み、VMよりもはるかに軽量で、標準化されパッケージ化されたディストリビューションとして使用されます。ソフトウェアをコンテナとして再パッケージ化するだけでは、拡張性と高可用性は得られませんが、コンテナのモビリティを活用して移行を容易にすることは可能です。コンテナがデータセンターで実行されている場合、クラウドでも同じように実行されます。

ソフトウェアの再パッケージ化は、インストールを包むような容易な作業ではありません。ソリューションの構築と運用の方法を完全に再形成する必要があります。これには、別のCI/CDフローから、新しい監視とトラブルシューティングの方法まで含まれます。

リファクタリング

コンテナに再パッケージ化すると、ソフトウェアのモビリティが得られ、すべての依存関係とツールが最新のコードで昇格されるため、昇格による信頼性が向上します。ただし、コンテナだけでは、ダウンタイムなしで部分的にアップグレードしたり、新しいアイデアを迅速に市場に投入したりできる柔軟なソリューションは提供されません。これらの目標を達成するには、ソフトウェアをパッケージ化する方法だけでなく、アーキテクチャも変更する必要があります。モノリシックソフトウェアでは新しい要件を満たすことができないため、 マイクロサービスとして独立して機能できる、より管理しやすい要素に変える必要があります。

ESBはモノリスと見なされているため進化を続けており、組織はマイクロサービスとして軽量な統合を展開する必要性を感じています。これにより、ビジネスのニーズを満たすために非常に迅速にスケーリングできるマイクロサービス ランタイム（MSR）が登場しました。MSRは通常、コンテナを使用して展開され、KubernetesやOpenShiftなどのコンテナオーケストレーション環境を使用してスケーリングされ、その後、Prometheusなどのオープンソースツールを使用して監視されます。このアーキテクチャは、再パッケージ化の基礎を踏襲し、DevOpsプラクティスの大きな要件を伴います。つまり、昇格を完全に自動化し、開発・ビルド・テスト・展開する必要があります。このオプションの選択には、チームにおけるCI/CDプロセスの特別なノウハウと十分な成熟度も必要です。このアプローチは、組織がテクノロジーや運用上の課題に直面するため、すべてのオプションの中で最も難しいと考えられます。

再プラットフォーム化

再プラットフォーム化とは、ワークロードにiPaaS（integration Platform as a Service）を活用することです。これは純粋なクラウドサービスであり、クラウド間、またはSaaS間の統合を容易に実現します。統合をSaaSとして使用することで、このソフトウェアレイヤーの運用面を完全に忘れさせてくれます。ソフトウェアは自動的に更新され、必要に応じてスケーリングできます。他のクラウドネイティブシステムやSaaSアプリとの間で新しい統合を作成する場合に最適な選択で、そうしたアプリケーション用のコネクタとテンプレートが豊富に用意されています。アプリケーションをクラウドに移行する場合、iPaaSで新しい統合フローを作成して、オンプレミスのEBSを置き換えることは理にかなっています。

レガシー＆クラウド連携のハイブリッドアプローチ

当社はアプリケーションが単一のデータセンターでホストされることは二度となく、ソフトウェアの重要性やイノベーションのニーズに応じて常に ハイブリッドインテグレーション アプローチが採用されると確信しています。ハイブリッドでは、統合ワークロードはデータアーキテクチャに従い、さまざまなホスティングシナリオでアプリケーションをできるだけ近い脇に置いておきます。最終的には、前述のすべての統合オプションが全体的に連携して機能するようになります。

ビジョン – マイグレーションの推進理由が何であるかを知る必要があります。これは企業によって異なりますが、一般的な推進理由がいくつかあります。求めているのはコスト削減ですか？負荷時の俊敏性の向上ですか？メンテナンス時のビジネス継続性と安定性ですか？それぞれにおいて長期的なメリットを探し、それを貴社のビジネス目標に合わせるようにしてください。

評価 – 目標を達成するためにどのようなタイムラインを望んでいますか？アプリケーション環境の分析を行いましたか？どの環境に重心を置くかを把握していますか？

計画 – かなり多くのお客様が、最新のテクノロジートレンドを追いかけるだけで、この段階に直接ジャンプしています。ビジョンと評価の部分を達成すると、どのマイグレーションアプローチが特定の連携フローに最も適しているかが明確になります。

実行 – ビジョンとその達成計画を立てたら、変革を前進させるために必要なスキルと時間を確保する必要があります。完璧なマイグレーション方法は存在しませんし、最新のアーキテクチャを備えたクラウドからソフトウェアを実行するだけの魔法のようなスイッチもありません。 ビジネス目標を達成するための最善方法を見つけ出し、成功のための測定可能な基準を定義してください。

連携作業の最初のステップとしては、どこに移行するかに関係なく、環境を容易にモダナイズするためのAPI戦略を慎重に選択することが重要です。次に、各連携作業の「重心」を理解することで、どの連携オプションが最適かを判断できます。まずは素早く成功させる方法から始めることをお勧めします。迅速な成功のためのお薦めのオプションとしては、そのままリホストすることです。クラウドで実行することの意味を理解することができます。ランニングコストと運用コストを追跡できるだけでなく、ネットワーク トポロジ、データに関する法的側面、組織内の知識のギャップなど、潜在的な隠れた問題を監視することもできます。

次の簡単なステップは、再プラットフォーム化です。特に、まったく新しいSaaSアプリケーション間の連携の構築を開始する場合です。webMethods.io は、優れたUXと多くの最新システム用の豊富なレシピで、これらのワークフローを容易に構築できます。

その一方で、組織はコンテナオーケストレーション環境で連携のマイクロサービスを実装して展開するスキルを徐々に習得できます。
多くの異なる連携が必要になるため、それらすべてをスケーラブルな方法で管理できるように準備する必要があります。