クラウドに向けた取り組みの紹介
アプリケーションの移行を含むクラウド移行プロセスは複雑になります。しかし、この複雑さの中には、クラウドへの過程で明確に定義された目標がいくつかあります。そのような目標の1つには、対象アプリケーションをどれほど"クラウド対応"にするか、ということがあります。希望する時間枠でクラウドに移行するために、アプリケーションをどの程度クラウド対応にする必要があるでしょうか？このホワイトペーパーでは、これらの目標のいくつかを概説し、当社の移行の過程に基づいて学んだベストプラクティスと教訓に焦点を当てます。成功の秘訣は、移行目標を事前に明確に定義して、目標を達成する方法について最適な決定を下せるようにすることです。可能性のある道筋はたくさんあることがわかるようになります。移行の過程で、開発者、配信チーム、および役員は、どのように進めるかについて評価し、多くの選択を行うことが必要になります。
ビジネス目標を達成するために必要な決定の枠組みを決めるために、次の技術的およびビジネス上の推進要因に焦点を当てることをお勧めします。
スケーラビリティ
クラウドサービスは、管理されたインフラストラクチャで可能な計算能力はるかに超える大規模な計算能力を提供し、ビジネスが市場オポチュニティを満たすために成長できるようにします。クラウドベースのサービスとしてのインフラストラクチャ（IaaS）とサービスとしてのプラットフォーム（PaaS）により、ISVは最新のコンポーネントを利用したスケーラブルなアーキテクチャの構築に集中できます。移行でさらに得られるメリットは、内部開発チームがIT運用の管理とスケーリングから解放され、パフォーマンスの調整と最適化に集中できるようになることです。
モダナイゼーション
ツールセット、サービス、およびアーキテクチャを最新化すると、コンポーネント間の統合が容易になり、アプリケーションがクラウドで利用可能なツールとテクノロジーの完全な価値を実現できるようになります。このようなツールは、インフラストラクチャのアップグレードから自動導入パイプライン、アプリケーションのパフォーマンスを向上させる統合された機械学習モデルまで多岐にわたります。市場で急速かつ一貫した変化が起きている場合、変化に付いて行くためにアプリケーションは動的でなければならないため、モダナイゼーションが最も重要です。場合によっては、最新のテクノロジースタックを活用して、サービスを完全に書き直し、ブランドを変更して、低コストまたはより合理化されたサービスオプションを提供できます。このような変化は、老朽化した製品を更新し、ライセンス製品が標準となっている、確立された市場を混乱させる可能性があります。また、新しいアプローチで製品をオーバーホールし、ブランド認知度と顧客のロイヤルティを維持しながらサービスを改善できる場合もあります。これは、必ずしも製品スイートを完全に変更する必要があるということではありません。
クラウドへの移行は、幅広いモダナイゼーション推進のきっかけになります。クラウドは、以前には組織で利用できなかったサービス、テクノロジー、専門知識へのアクセスをお客様とお客様のチームに提供するため、新しい目標を達成し、新しい機能を提供することが可能になります。チームは、個別の顧客との特定の導入にリンクされたカスタムコードではなく、一般的に適用可能な新しい製品機能に焦点を当てられるようになります。サービスのプロビジョニング、製品の更新、カスタマーサポートがすべてこれまでになく迅速に行われるため、新しい機能の開発にリソースを再集中させることができます。このように、クラウド移行は、製品のアップグレードの実行から顧客サービスの品質に至るまで、あらゆるものを変革する、幅広いモダナイゼーション活動の準備を整えます。
「Gen2クラウドへの移行により、Oracleは堅牢なDevSecOpsモデルを介してサービスを確実に提供できるようになり、お客様のビジネス変革をサポートできるようになりました。現在、ソフトウェアを毎日リリースしており、プロビジョニング時間を98%以上短縮しています」— Oracle Global Business Units、シニアプリンシパル製品戦略マネージャー、Karthic Murali
標準化
IaaSとPaaSでの標準化により、オーバーヘッドを削減し、チームをより柔軟で代替可能にすることができます。組織が成長するにつれて、チームはさまざまな成熟度レベルのツールを採用します。これらのツールセットをクラウドサービス内で統合すると、IT管理のこの層に関連する複雑さの多くが抽象化されます。これにより、ポートフォリオ全体でマッピングできるタスクの標準的な運用方法の開発と使用が可能になります。また、標準化により、日常業務がより簡単で予測可能になり、基本的なタスクの労働力の需要が減少します。以前は、アプリケーション間で、互換性がない場合もある、さまざまなプロセスをナビゲートすることに縛られていたリソースは、次世代製品や顧客向けのサービスの開発など、より重要な問題に集中するために解放されます。
特に、標準化により、セキュリティ、リスク、コンプライアンス、およびチームが既存および新製品に簡単に適用できるその他の運用アクティビティに関するグローバルポリシーとプラクティスを簡単に適用できるようになります。実際、資格を取得したコンプライアンス認定など、IaaSプラットフォームの固有の機能の多くは、アプリケーションに継承できます。
収益の最適化
収益の最適化は、主に2つの方法で実現できます。1つ目の、最も明白なものは、コスト削減です。IaaSを利用してデータセンターを排除すると、財務モデルがCapExからOpExに移行するだけでなく、通常、有意義なTCOの節約にもつながります。クラウドに移行されるアプリケーションのポートフォリオ全体で使用されるテクノロジースタックを合理化することによって達成されるコスト削減は、それほど明白ではないかもしれません。一般的なツールセットでは、制度的な知識が生まれ、標準化されていないツールのアドホック・トレーニングに関連する費用が排除されます。これらの方針に沿って、インフラストラクチャをコードとして扱う一般的なツールセットでは、最終的に時間と人件費を節約する自動化が実現できます。最後に、セキュリティなど、ポートフォリオ全体に適用される基本的な領域を専門とするチームにより、個々の製品チーム内に専門家を生み出す必要がなくなります。
第二に、アプリケーションがクラウド対応またはクラウドネイティブになると、通常、製品開発のタイムラインが短縮されるため、クラウドへの移行は、市場投入までの時間を短縮し、最終的に収益を最適化できます。より早く市場に参入することは、より迅速に収益を実現できることを意味します。アプリケーションがクラウド対応になると、世界中のどこにでも数分で導入できます。
上記の原則を組み合わせると、製品とサービスのアーキテクチャが標準化され、導入の速度と品質が向上するはずです。スケールは、繰り返されるパターンの設計の結果として生じ、収益の最適化、価値実現までの時間の短縮、および結果として得られる、顧客向けのサービスの品質と整合性の向上にリソースを再集中させる機能に貢献します。
"財務パフォーマンスにより、最初から設備投資を30〜35%節約できました。また、OCIから得られる優れたパフォーマンスにより、スイートで提供するROIはますます向上しています。"—WorkForce Software、最高経営責任者、Mike Morini氏
続きを読む
クラウドでの価値に通じる道
クラウド・コンピューティングには、ベア・メタル・インスタンスへのアクセスから統合されたコンテナ化された環境、完全に機能するサービススタックに至るまで、一連のIaaSおよびPaaSリソースと複数のソフトウェア導入モデルを含めることができます。最も基本的なレベルでは、クラウド・コンピューティングとは、物理インフラストラクチャ・コンポーネントをコアIaaSリソースに置き換えることを指します。
ほとんどのエンタープライズ・アプリケーションは、もともとクラウド用に構築されていません。多くのアプリケーションでは、クラウドパターンへの変換または準拠には時間がかかり、かつ困難です。プラットフォームの再構築は、時間と労力の両方の観点からコストがかかる可能性があるため、クラウドネイティブのプリンシパルを最初から設計する方が簡単な場合があるのは、驚くようなことではありません。この点を考慮に入れると、企業は通常、クラウドの移行を検討する際に3つの主要なシナリオのいずれかに直面します。
- レガシー・データセンターの終了：データセンターの運営には費用がかかります。建物、人、電力、冷却、メンテナンス、およびアップグレードは、日常の責務のごく一部です。多くの企業は、オフプレミスに移動するための候補となるアプリケーション・ポートフォリオを評価することにより、データセンターへの依存を軽減または排除するために積極的に取り組んでいます。優先事項は、資本支出を削減または排除するために、同じ場所に配置された、マネージド・ホスティングまたはオンプレミスのデータセンターからアプリケーションを移動することです。多くの場合、リフトアンドシフト戦略が利用され、アプリケーションはそのままベアメタルサーバーまたはクラウド内の仮想マシンに移行されます。
- テクノロジースタックの進化：この場合、企業は追加の投資を必要としても、時間とともにより多くの価値をもたらすことも期待されるアプリケーションに段階的な変更を加え始めます。この例としては、アプリケーション自体に大きな変更を加えることなく、オンプレミス・バージョンのOracle DatabaseをクラウドベースのOracle Autonomous Databaseに置き換えることが挙げられます。これは、移行と改善の戦略と呼ばれることもあります。
- クラウドネイティブでのオールイン：アプリケーションをボトムアップでクラウド対応に再構築する利点は、上記のシナリオの1つを実装しながら、成熟度の低いアプリケーションをそのまま維持するコストを上回る可能性があります。クラウドネイティブなアプリケーションは、本質的に高度に分散されており、多くの場合、12要素の原則を利用して構築されているため、基盤となるアーキテクチャから独立するように設計されています。つまり、アプリケーションは、その下にあるインフラストラクチャが壊れた場合でも継続して動作します。簡単に言えば、クラウドへの移行は、基盤となるインフラストラクチャと緊密に結合されたアプリケーションを移行するよりも確かに簡単であるため、このパスが対象アプリケーションにとって意味があるかどうかを評価する価値があります。
Oracleがクラウドネイティブをどのように定義しているか、クラウド・ネイティブ・アプリの起源、およびそれを構築する際に従うべきベストプラクティスについては、このeBookをお読みください。
これらのシナリオを想定するもう1つの方法は、エンタープライズ・アプリケーションをOracle Cloud Infrastructureに移行しながら、クラウド・ネイティブ・アーキテクチャに近づけるために実行できるさまざまなアクションを調べることです。下の図1を参照してください。
図1：クラウド移行の変化と投資レベル
図1の左側は、変化の量が最も少なく、価値を実現するまでの時間が最も短く、初期投資が最も少ないことを表しています。変化、投資、時間のレベルは、右に移動するにつれて全体的に増加しますが、実現される価値も大きくなります。このモデルは、移行フェーズで行うことを検討する投資の種類を予測する方法の枠組みを作るのに役立ちます。アプリケーションは無数の方法で構築されているため、シナリオは必ずしも個別のものとは限らず、多少重複ことに注意してください。
上記のシナリオは、既存の成熟度レベルとクラウド移行の目標を評価するための重要な参照ポイントになります。現在の状態と目標の状態の間のギャップから、クラウド移行に必要な技術的およびプロセスの変更の範囲の大まかな見積もりが得られます。完璧な世界では、クラウド移行により、すべてのアプリケーションがクラウドネイティブの提供モデルに移行するはずです。しかし、リソースと時間の制約があるため、1回のプロセスでポートフォリオ全体をクラウドネイティブ・モデルに移行できる組織はほとんどありません。単純なプラットフォームの再構築作業でさえ、リソースを大量に消費し、レガシー機能を複製するためだけに多額の投資が必要になる可能性があります。
したがって、クラウド移行は、最適なクラウド成熟度レベル（アプリケーションが上記のクラウドでホストされたクラウドネイティブの連続体にある場合）と、製品とそれに関連するビジネスプロセスを再構築するために必要なエンジニアリング投資との間のトレードオフを判断する問題です。この段階での重要なステップは、このギャップを埋めるために必要な開発投資の概算の見積もりを含め、各アプリケーションの現在および目標の成熟度レベルを特定することです。
移行中に成熟度レベルが変化するアプリケーションは、運用パターンと期待も変更する必要があります。成熟度レベルの変化は、サービスをサポートするチーム、プロセス、およびポリシーに影響します。