TechTargetジャパン
クラウド
AWS
比較
ほろ苦い経験から学ぶ、クラウド “ベンダーロックイン”回避策

常に出口戦略を用意すべし

ほろ苦い経験から学ぶ、クラウド “ベンダーロックイン”回避策

OracleやIBMやMicrosoftには、ベンダーロックインへの懸念を生み出した歴史がある。現在同様の懸念はAWSにも存在する。ユーザー企業は苦い歴史を繰り返さないようにしなければならない。

公開 2016年12月22日 12時00分

著者

David Linthicum

[TechTarget]

印刷する Googleで優先するソースとして追加

　企業の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は魅力的だが、他のクラウドプラットフォームでは使えない。アプリケーションは常に、明日にでも移行するつもりで開発する必要がある。ことによると、本当にそうなるかもしれないのだから。

印刷する

この記事の著者

David Linthicum

ほろ苦い経験から学ぶ、クラウド “ベンダーロックイン”回避策

併せて読みたいお薦めの記事

クラウドベンダーによるロックインの懸念

ロックイン名人からの脱却

過去の教訓を生かす

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

ほろ苦い経験から学ぶ、クラウド “ベンダーロックイン”回避策

併せて読みたいお薦めの記事

クラウドベンダーによるロックインの懸念

ロックイン名人からの脱却

過去の教訓を生かす

この記事の著者

関連記事

クラウドの“勝ち組”Amazonに浮上するベンダーロックインの懸念

「Evernote」がGoogleクラウドへ移行、“ロックイン”は怖くない？

クラウドユーザーはベンダーロックインの悪夢をまた見るのか

「ベンダーロックインの名人Oracle」からの脱却

ユーザーの製品選択を脅かす“ベンダーロックイン”、唯一の解決策とは？

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓