ポイント: ベンダーロックインはクラウドコンピューティングを複雑にし、ユーザーがプロバイダーを切り替える能力を制限します。このリスクを軽減するためのベストプラクティスには、技術依存関係の評価、アプリケーションの移植性の確保、関係者の関与、マルチクラウド戦略の採用が含まれます。
- 技術スタック依存関係を特定し、評価する。
- アプリケーションを移植可能にし、オープンスタンダードに合わせる。
- ベンダーロックインを避けるための明確な出口戦略を策定する。
クラウドの世界では、私たちのワークロードは、ハイブリッドクラウドやさまざまなマネージドサービスの中に存在します。しかし、ワークロードやデータセットをあるクラウドから別のクラウドに移動しようとしたことがあるなら、厄介な状況に直面することがあるかもしれません。この課題―ワークロードを一つのクラウドベンダーから別のクラウドベンダーに移すこと―はベンダーロックインとして知られています。ベンダーロックインは特にクラウドコンピューティングにおいて発生し、ユーザーは簡単にサインアップすることが奨励されますが、さまざまな慣行がユーザーが「離れる」こと、データを移動させることを難しくします。幸いなことに、クラウドベンダーロックインを避けるために取れるステップがあります。見てみましょう。
ベンダーロックインとは何か？
ベンダーロックインは、ユーザーがサービスを切り替えることを妨げる制限を指します。理想的なオープンIT環境では、ユーザーは自由に「リフト・アンド・シフト」でき、データやITワークロードを一つの技術スタックから別の技術スタック、競合するベンダーや地理的な場所に移行することができます。しかし、エンタープライズITの世界は必ずしもオープンではありません。これは特に、プロプライエタリ技術、激しい市場競争、規制の制約が関与する場合に当てはまります。一部のベンダーは、ユーザーがITワークロードを競合他社のサービススタックに移行することを特に困難にします。ユーザーが長期的なビジネスパートナーシップにコミットしない場合、自由に行動する権利を受け入れることは収益の流失を意味します。しかし、ベンダーはユーザーがこの自由を行使することを明示的に妨げることはありません。彼らは単に、ユーザーがそうすることを思いとどまらせる技術的、財政的、法的制約を課します。逆に、ベンダーはユーザーが自社のサービスに参加することを容易にします：
- コンピューティングを開始するための初期コストは低く抑えられています。しかし、サービスをスケールする必要がある場合、コストは指数関数的に増加します。
- パフォーマンス、セキュリティ、統合、競合するベンダーの技術との互換性などの技術的制限は、後の段階でのみ経験されます。
多くの点で、これらの制限はサービス利用規約（ToS）の細かい印刷として指定されているか、ユーザーの技術要件が予測不可能に進化する中で予見できないものです。
ベンダーロックインを避けるためのヒント
ベンダーロックインは、クラウド移行に反対する理由としてしばしば引用されます。実際、ロックインの概念は、クラウドの主な価値提案の一つである柔軟性を否定します。しかし、以下のベストプラクティスを採用することで、ベンダーロックインのリスクを減らす方法があります。
1. 複雑な依存関係を特定する
既存の技術スタックを見直してください。ITワークロードがレガシー技術で動作するように設計されている場合、クラウドプラットフォームとインフラストラクチャの選択が制限される可能性があります。
2. 共通点を理解する
クラウドベンダー間で互換性があるもの、既存の技術スタック、および技術要件を比較してください。これらの共通点は、ビジネスニーズに最適なクラウドソリューションを決定するための重要な要素です。代替サービスが利用できない場合は、IT戦略、移行の決定、およびITワークロードの技術要件を再考する必要があります。
3. 移行前にアップグレードを検討する
アプリが限られた技術セットでのみ互換性がある場合、クラウド移行の前にアプリの重要な部分をアップグレードまたは再構築することを検討することが望ましいです。アプリとITワークロードが、特定のクラウドベンダーによってサポートされているレガシー技術でのみ動作する場合、サービスを拡大するための将来の要件は、高額な財政コストや技術的課題を引き起こす可能性があります。
4. 関係者を教育する
トレーニングと関係者の関与は、あなたのユースケースにおけるベンダーロックインの独自のリスクを理解するために重要です。技術チームは、技術的な決定選択のビジネスへの影響を把握しておく必要があります。アプリ、ITワークロード、またはコンピューティングアーキテクチャの形での作業ソリューションは、ビジネス要件とリスクに合致する必要があります。ITワークロードをクラウドサービスに移行する前に、特定のベンダーおよび契約の義務に関連するベンダーロックインの懸念を慎重に評価してください。
5. アプリを移植可能にし、オープンスタンダードに合わせる
この慣行は、さまざまなクラウドの選択肢を確保します。多くのクラウドベンダーは、さまざまな業界の垂直にわたるほとんどのオープンスタンダードをサポートしています。十分な代替手段がある場合、ベンダーを簡単かつ効果的に切り替えることが容易になります。これを実現するためには、ITワークロードが非プロプライエタリの代替手段をサポートする必要があります。ワークロードがオープンスタンダードをサポートしないプロプライエタリ技術のAPI、構成、および機能にロックインされている場合、ベンダーロックインの可能性があります。オープンスタンダードをサポートしないことは、将来的にベンダーロックインの状況から脱出するために多くのカスタマイズが必要になる可能性があります。
6. 現代のSDLC手法を採用する
現代のSDLC手法に基づいて設計することで柔軟性が得られます。例えば、DevOpsはオープンソース技術の使用を奨励するだけでなく、クラウドサービスの管理と運営の技術的独立性に特に焦点を当てています。インフラストラクチャ・アズ・コード (IaC)は、インフラストラクチャをプロビジョニング、管理、運営するための一般的なDevOpsプラクティスです。IaCは、インフラストラクチャの構成と依存関係を記述するプロセスを自動化し、任意の選択肢から繰り返し可能な望ましい技術的状態に収束させます。
7. 移行後の移植性を確保する
データを一つのサービスから別のサービスに移すことは、同じベンダー内であればしばしば無料です。しかし、競合するサービスに移行する場合、この転送は高額になります。クラウドに移行する前に、クラウドベースのデータストレージや関連サービスの将来のスケール要件に基づいてこれらのコストを評価し、考慮してください。
8. 明確な出口戦略を策定する
クラウドベンダーはビジネスを終了したり、利用規約を大幅に変更したりすることが法的権利の範囲内で可能です―ユーザーの利益を犠牲にしてでも。可能な出口戦略を設定することで、このリスクを減らすことができます。契約の出口条件は両者で合意されるべきであり、顧客がベンダーロックインの状況を回避しやすくなります。
9. マルチクラウド戦略を検討する
複数のクラウドサービスを活用し、基盤となるベンダーのインフラストラクチャに依存せずにワークロードを分散させます。マルチクラウド戦略には、コスト、パフォーマンス、リスク（ベンダーロックインなど）を最適化するために追加のステップを踏む必要があります。うまく行うことで、アプリやデータが意図的に複数のクラウドプラットフォームのハイブリッドミックスで機能できるため、前述のリスクが自然に対処されます。
10. デューデリジェンスを行う
以下の項目は、あなたのデューデリジェンス戦略の一部であるべきです：
- 自分の技術的およびビジネス要件を徹底的かつ正確に理解する。何が変わると予想され、どのように変わるのか？
- クラウドベンダー市場を評価する。サービス履歴、市場の評判、およびビジネス顧客の経験を監査する。
- クラウド市場のトレンド、ビジネスモデル、クラウドサービスの未来を理解する。
- クラウドのユースケースに適用される法的制限を理解する。あなたのビジネスドメインとITワークロードの垂直に適用される特有の規制はありますか？
- 細かい印刷を読む。ベンダーロックインの可能性を制限するサービスレベル契約（SLA）の条件や契約義務に同意する。
ロックインを避けるための魔法の弾はない
最後に、ベンダーロックインを避けるために極端な手段を講じることが予期しない結果をもたらす可能性があることを理解することが重要です。オープンソースを使用することでベンダーロックインが魔法のように排除されるわけではありません。場合によっては、プロプライエタリ技術が特定のオープンソース技術に対するパフォーマンス、コスト、またはセキュリティリスクを相殺することがあります。または、あるいは、プロプライエタリベンダーとは異なるロックイン状況を提示することがあります。例えば、プロプライエタリなAWS技術からKubernetesのようなオープンソースソリューションに切り替えることができます。アプリケーションがスケールし、複雑さが増すにつれて、Kubernetesから別のオープンソースまたはプロプライエタリな代替手段に切り替えるためのすべての設定依存関係やYAMLファイルを管理することは、ITチームにとって大きな課題となるかもしれません。この場合、1つのロックインを別のもので置き換えるだけの問題かもしれません。
追加リソース
クラウドがあなたの会社に機能するようにするための詳細については、BMC Cloud Blogを閲覧するか、次の記事をチェックしてください：
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。