クラウド移行の8つの課題

クラウドコンピューティングは成熟度が高まっていますが、それをより困難にしたり、コストを増大させたりする可能性のある課題がいくつかあります。パンデミックの影響もあり、養子縁組のパターンも変化した。

当初、クラウド移行にはストレージが含まれ、その後にアプリケーションとコンピューティングが続きました。現在利用可能なすべてのクラウドサービスにより、コストが依然として最大の懸念事項ではあるものの、企業は新たなレベルの効率性を達成し、成長する機能を活用できます。

パンデミック以前は、クラウドコンピューティングの方が安価であることを証明するために、さまざまな価格分析を行う必要があり、総所有コストについても話し合いました。今重要なのはコストの最適化です。当社の多くの顧客にとって、最も簡単な解決策はクラウドに移行しており、現在最大の問題はコストです。

コストを節約するために、多くの企業は独自に移行を好みますが、これは非効率性を生み出し、最終的には長期的にはコストの増加につながる可能性があります。たとえば、組織がワークロードを間違った環境に移動したり、急騰する消費コストの修正に貴重な時間を費やしたりする可能性があります。

毎年、クラウド移行プロセスの非効率性により組織はより多くの費用を費やしており、かなりの数の企業が移行の遅れに気づいています。これらの予期しないクラウド費用は世界的に増加し、無駄な支出を生み出します。このような無駄を避けるために、組織は明確な KPI を定義して、クラウドへの移行によってどれだけの節約や支出が見込まれるかを判断する必要があります。これは、移行が経済的に効率的か困難かを判断するのに役立ちます。

組織が直面するその他のクラウド移行の課題を以下に示します。

1. アプリケーションの依存関係

データセンターをクラウドに移行するには、多くの課題があります。最も一般的な課題は、組織がアプリケーション間、さらには個々のアプリケーションコンポーネント間の重要な依存関係を理解していないことです。

アプリケーションが相互に通信する方法と、アプリケーションの操作に重要なコアサービスがどれであるかを理解することは、移行計画を策定する上で重要な要素です。これを怠ると、コストのかかるダウンタイム、パフォーマンスとユーザーエクスペリエンスの低下、セキュリティリスクが発生する可能性があります。時間をかけて徹底的なアプリケーション依存関係マッピングを実施し、その結果を移行計画に組み込む企業は、クラウド変革が成功する可能性が高まります。

2. データセキュリティと規制遵守

クラウドへの移行により、新たな脆弱性とリスクが露呈します。チームは、インフラストラクチャ・アズ・コード (IaC) テクノロジーを使用してクラウドを活用し、クラウド開発パイプラインを保護できます。

IaC を使用すると、開発プロセスに統合されたツールを使用して、コードレベルでセキュリティ制御を組み込み、新しいインフラストラクチャの問題を評価することが容易になります。ほとんどのパブリッククラウドプラットフォームでは、開発プロセス内でセキュリティの問題を評価および監視するためのツールも提供されており、セキュリティチームは、クラウドセキュリティポスチャ管理 (CSPM) やクラウドネイティブアプリケーション保護プラットフォーム (CNAPP) などの新しい機能を使用して、セキュリティの誤った構成や調査が必要なその他の疑わしいアクティビティをリアルタイムで可視化しています。これらのツールをクラウド管理コントロールプレーンとビルドパイプラインに統合すると、オンプレミス環境では決して実現できないレベルの可視性と制御をセキュリティチームに提供できます。

3. 古い思考パターン

コードとしてのインフラストラクチャ、サーバーレス、エッジコンピューティングなどの最新のアプローチを使用すると、テスト、1 日に複数回のデプロイ、または安心して運用環境にデプロイするために、レプリカ環境を数分でプロビジョニングおよび廃止することは難しくありません。最終的な解決策は、矛盾しているように思えても、通常はより複雑ではなく、より単純です。サービスごとに移行でき、サーバーレス、Docker、CDN に完全に切り替えた後は、主に CI/CD のおかげで配信を大幅に高速化でき、リリース管理のオーバーヘッド全体が排除されます。

4. 誤った仮定

これまでオンプレミスのデータセンター、メインフレームコンピューティング、従来のリリースサイクルに依存してきた組織にとって、クラウドへの移行は困難な場合があります。効果的なクラウド移行は、次の主要領域における中核的な前提に挑戦する可能性があります。

● インフラストラクチャはコードとしてのインフラストラクチャ (IaC) ではなく、資本支出である

● 資産所有コストの会計と柔軟性の計算

● インフラストラクチャとアプリケーションのエンドツーエンドの管理から、構成可能なクラウドベースのプラットフォームとサービスの構成要素への新たな重点への変革

● 境界ベースのオンプレミスセキュリティモデルからクラウドベースまたはハイブリッド脅威モデルへの移行

● クラウドの共有責任モデルにおける完全なハードウェアとネットワーク制御のトレードオフを評価する

● クラウドベースではなく物理的な場所に基づいた冗長かつ階層化されたデータストレージオプションによる災害復旧および事業継続計画

クラウドでは、物理的なデータセンターよりも、垂直方向、水平方向、さらには地域的に拡張することが容易です。ただし、必ずしも安価で労働集約的ではないため、クラウド移行を戦略の中核にすることを完全に決定する前に、すべての潜在的なトレードオフを考慮することが重要です。

5. 批判的思考力の欠如

水平方向の移行と垂直方向の移行の両方に課題があります。水平移行はワークロードアーキテクチャにほとんど影響を与えず、同じパブリッククラウドまたはプライベートクラウド環境内でより効率的なクラウドプロバイダーを見つけることができます。プライベートクラウド分野での M&A 活動により、チームがプライベートクラウドのコストモデルと潜在的なハイパーバイザーの変更を再評価していることを考えると、これは突然、はるかに興味深いものになっています。

これは、まったく新しい経済モデルの採用と、移行自体だけでなく翌日の作業負荷も管理するためのチームのスキルと能力の冷静な評価を必要とする複雑な取り組みでした。

垂直移行は、通常、プライベートクラウドからパブリッククラウドへの「リフトアンドシフト」移行ですが、あまり一般的ではありませんが、パブリッククラウドからプライベートクラウドへの移行もあります。これは多くの場合、プライベートクラウドのフットプリントを削減し、プライベートクラウドへの水平移行で必要になる可能性のあるリスクや労力を軽減するための最初のステップとなります。この目的で活用されるパブリッククラウドサービスは、移行プロセスを簡素化する、非常に安定しており、十分に説明された商品です。最後に、モダナイゼーションがあります。これには、ワークロードの移動自体だけでなく、ワークロードのアーキテクチャパターンをクラウドネイティブパターンとより適合するように変更することも含まれます。

企業としては、複数の入力を継続的に評価し、特定の時点でどのテクノロジーの組み合わせがビジネスに適しているかを判断する必要があります。これらの側面には、どのワークロードがビジネスの差別化機能に最も貢献しているか、使用状況とスケーリングパターンに応じて再展開/変更がどのくらいの頻度で必要か、コンプライアンスのニーズ、規模の経済性などが含まれます。これらの要素のバランスをとるための共通の管理場所を確保し、適切な規模の経済性で適切なワークロードを適切なクラウドに配置することにチームが集中できるようにして、最高のクラウド ROI を確保します。

6. 運用技術をクラウドに移行する

クラウドコンピューティングの当初の焦点は、ストレージやバックアップなどの IT ワークロードをクラウドに移行することにありましたが、現在の課題は、製造プロセスに不可欠な複雑で重要な運用技術 (OT) システムをクラウドに移行することです。

これらのシステムは複雑で運用に深く組み込まれているだけでなく、クラウドサービスに関するトレーニングを受けていない可能性のある OT 管理者の専門知識も必要になります。さらに、OT データを安全に保ち、さまざまな標準に準拠させることは大きなハードルであり、クラウド IT ワークロードと製造業務の間のギャップを悪化させます。

IT と OT のギャップを埋め、クラウド導入から価値を引き出すには、製造業者はクラウドのスケーラビリティと高度な分析機能を活用する必要があります。たとえば、定期的に SOC2 評価を受ける SaaS プラットフォームを活用すると、機密性の高い OT データに対して安全で準拠した環境が提供され、企業は変化するニーズに適応し、大量のデータを分析してより適切な意思決定を行い、従業員に実用的な洞察を提供できるようになります。

7. レガシーシステムの知識と技術的負債

近代化が進むアプリケーションのほとんどには、長年にわたるビジネスおよびプロセスの知識が含まれていますが、ドキュメントがほとんどまたはまったくないため、リバースエンジニアリングが困難になっています。

複雑さに加えて、レガシーシステムや技術的負債に関連する機能やビジネスロジックの多くは、減価償却または廃止する必要がある可能性があり、これはビジネス上の決定と承認にとって大きな課題となります。この問題を克服するには、チームには、この固有のシステム知識を効率的に習得するのに役立つ従来のシステムの専門家が必要です。