常に出口戦略を用意すべし
ほろ苦い経験から学ぶ、クラウド “ベンダーロックイン”回避策
OracleやIBMやMicrosoftには、ベンダーロックインへの懸念を生み出した歴史がある。現在同様の懸念はAWSにも存在する。ユーザー企業は苦い歴史を繰り返さないようにしなければならない。
企業のIT意思決定者の大半は、ベンダーロックインに陥るとパブリッククラウドのビジネス価値を最大限に引き出せないと考えている。アプリケーションをパブリッククラウドへ移行したがらないIT責任者が多いのは、1社のクラウドに依存すれば柔軟性が損なわれるとの懸念があるからだ。
実際、Amazon Web Services（Amazon）のようなパブリッククラウド事業者による圧倒的な市場占有は業界にとってマイナスだと指摘する研究結果も幾つかある。Amazonによるロックインを警戒するIT管理者は、「Amazon Web Services」（AWS）の「Amazon Elastic Compute Cloud」（Amazon EC2）や「Amazon Simple Storage Service」（Amazon S3）といった汎用サービスは利用しても、データベースやアプリケーション開発環境など特定用途のサービスを避ける傾向にある。先々、そうしたサービスのあらゆる側面をクラウドが支配し、柔軟性を制限することへの懸念からだ。
併せて読みたいお薦めの記事
クラウドベンダーによるロックインの懸念
ロックイン名人からの脱却
だがこの状況は私たちにとって初めてではない。何年も前、企業はOracleやIBM、Microsoft製品への移行をめぐり、同じような懸念を抱いていた。懸念の核となるのはいずれも、「プロプライエタリなデータベースやOSに移行すると、そのプラットフォームに長期的にロックインされることにならないだろうか」という不安だ。かつてベンダーはこうした懸念に対し、安心できる答えを提供しようとした。そして誰も、「1つの技術を選べば、ロックインされる」という本当の答えは聞きたがらなかった。
ベンダーロックインに陥ると、技術を移行するコストは法外になる。格好の一例がOracleだ。ただしIBMやMicrosoftなど他のベンダーにも、多かれ少なかれ同じ問題がある。データベースをOracleに移行したにせよ、新しいデータベースを構築したにせよ、新たに別のデータベースに移行するには相当の費用と労力が必要だ。
Oracleのネイティブ言語やネイティブAPIで記述したストアドプロシージャやトリガーなど、ネイティブでプロプライエタリな機能を使用した場合、問題はさらに悪化する。だが全ての機能をフルに活用し、最大限に価値を引き出せるのでなければ、なぜテクノロジーを購入するのか。残念ながら、こうしたネイティブな機能は短期的なメリットを提供できる一方で、ロックイン状態を強める可能性がある。
あれから数十年がたった今も、クラウドに関しては真にオープンな技術はない。例えばクラウドベンダーが提供するデータベースは、APIやモデルなど、プロプライエタリな技術を使用する傾向がある。そのためデータを他のクラウドに移行するとなると、高くつく可能性がある。それほどプロプライエタリではないオープンで安価な技術もあるが、費用やリスクを理由に移行に踏み切らずにいる企業が多い。
場合によっては、AWSでOracleを実行したりクラウドサービス「Oracle Cloud」を利用したりなどして、従来のデータベースやアプリケーション開発プラットフォームをクラウドで実行しなければならない。そうした企業は高いライセンス料金を払い続けることになる。
過去の教訓を生かす
かつて企業向けソフトウェアにロックインされていた時代から、IT管理者はどのような教訓を学べるのだろうか。その知識をどう生かせば、クラウドベンダーによるロックインを回避できるのだろうか。
まず、常に出口戦略を用意しておくことだ。パブリッククラウドのクラウドネイティブなデータベースに移行するなら、その技術からどう撤退するかを考えておく必要がある。オープンな技術とクローズドな技術のどちらに移行するかは関係ない。どちらにもロックインの問題はある。出口戦略は必ずしもAmazonによるロックインのリスクを軽減するものではない。だが特定のベンダーに対する財務的および組織的なコミットメントは軽減できる。
次に、いずれは撤退できるクラウドプラットフォームを選ぶことだ。例えば、一流のクラウドデータベースベンダーであれば、ごくわずかなコストとリスクで他のプラットフォームに移行できるプロセスやツールを用意しているはずだ。
最後に、プロプライエタリな機能はなるべく使わないこと。ネイティブAPIは魅力的だが、他のクラウドプラットフォームでは使えない。アプリケーションは常に、明日にでも移行するつもりで開発する必要がある。ことによると、本当にそうなるかもしれないのだから。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[LRM株式会社] 「標的型攻撃メール」事例・サンプル集 -
製品資料
[LRM株式会社] セキュリティ教育はなぜ「年間計画」を立てる必要があるのか？ -
製品資料
[LRM株式会社] セキュリティの重要性が伝わらない…… 効果がない社員教育から脱却する方法 -
製品資料
[LRM株式会社] 「標的型攻撃メール訓練」導入ガイド 社員の意識を確実に高める仕組みの作り方 -
事例
[株式会社マクニカ] アイカ工業に学ぶ脆弱性対策 情シスが把握できずにいたアセットも正確に把握
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
2
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
3
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
4
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
5
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
6
エンジニアが選考を辞退する本当の理由 7割が隠す“面接の違和感”とは
-
7
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
-
8
AI基盤は本当に「オンプレ回帰」する？ Broadcomの言い分と企業の本音
-
9
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
10
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
3
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
4
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
6
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
7
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
8
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
9
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
10
情報セキュリティ対策早分かりガイド：25の自社診断で弱点と解決策を理解
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー