エンタープライズのためのOpenStack検討ガイド【第5回】

OpenStack導入で先が思いやられる「アンチパターン」ベスト5（2/2 ページ）

アンチパターン4：いきなり壮大な計画を立てる

　現在保有しているシステムを全てOpenStackの上に載せたらどうなるか、という壮大な計画からはじまるパターンもよくある。これもうまくいかない。

　なぜうまくいかないか、最も大きな原因は、ユーザーの信用を得られないことである。繰り返しになるが、OpenStackはクラウドのパラダイムシフトの中で生まれた。従来のやり方ではなく、その環境を利用するユーザーが手段を変えたり、リスクを取らなければいけない場合もある。

　リスクをとるに当たり、必要なのは信用と得られる効果だ。たとえ小さくとも、身近で上手くいった実績があれば、チャレンジの後押しになる。よって、可能であれば、ユーザーであるアプリケーション開発者の課題を1つでも解決する機能を持ち、小さくても確実にこなせる規模から始めるべきだ。上手くいったらその実績をベースに広げていけばいい。

アンチパターン5：枝葉の技術にこだわる

　最後は、枝葉の技術ありきで設計を進めてしまうパターンだ。

　クラウドと時を同じくして、“Software Defined”ブームが起こった。ネットワークやストレージといったハードウェアをソフトウェアで実装する、もしくはソフトウェア的に制御するという考え方だ。多くのベンダーが、その製品をOpenStackと組み合わせて動かすため、ドライバーやプラグインを提供している。

　だが、これがバランスを崩す原因になることがある。

　例えば、OpenStack以前になぜかSDN（Software-Defined Networking）製品の採用が決まっていた案件があった。理由は不明である。それによって組み合わせられる他技術の選択肢が狭まり、設計の大きな制約条件となっていた。また、OpenStackとの組み合わせでは使えない独自機能が前提となっており、話を戻すのに苦労した。そして、製品コストの内訳は、8割がネットワーク製品。これでは本末転倒である。

　新しい技術を導入してビジネスに貢献したいという動機は否定できない。だが、それが本当に必要なものか、個別最適に陥っていないか、冷静に見極めるべきである。

---

　第5回は、設計に入る「前夜」までに、アーキテクトに意識してほしいアンチパターンをまとめた。若干刺激の強い表現があったかもしれないが、ご容赦いただきたい。刺激が強かった文、これからOpenStackに取り組む読者の皆さまの記憶に残れば幸いである。

　次回はいよいよ最終回、基本理念に続き、技術的なポイントを紹介する予定だ。ご期待いただきたい。

エンタープライズのためのOpenStack検討ガイド

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  サイバーエージェント、ヤフー、楽天が語るOpenStackとの理想的な関係

• 

  PayPalが語るOpenStack新版「Havana」の導入効果

• 

  機能を徹底比較！　～Eucalyptus、CloudStack、OpenStack

• 

  クラウドに興味を持つ者全てが望む「オープンソース連係」

新着ホワイトペーパー PR

• 製品資料
  [株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる
• 製品資料
  [株式会社キーエンス] なぜRPA導入は頓挫する？　シナリオ作成の壁を乗り越える解決策とは
• 製品資料
  [株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？　PLMとの融合で実現する高速開発
• 事例
  [日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？　「新たな働き手」を支える3要素とは
• 製品資料
  [日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣