現在保有しているシステムを全てOpenStackの上に載せたらどうなるか、という壮大な計画からはじまるパターンもよくある。これもうまくいかない。
なぜうまくいかないか、最も大きな原因は、ユーザーの信用を得られないことである。繰り返しになるが、OpenStackはクラウドのパラダイムシフトの中で生まれた。従来のやり方ではなく、その環境を利用するユーザーが手段を変えたり、リスクを取らなければいけない場合もある。
リスクをとるに当たり、必要なのは信用と得られる効果だ。たとえ小さくとも、身近で上手くいった実績があれば、チャレンジの後押しになる。よって、可能であれば、ユーザーであるアプリケーション開発者の課題を1つでも解決する機能を持ち、小さくても確実にこなせる規模から始めるべきだ。上手くいったらその実績をベースに広げていけばいい。
最後は、枝葉の技術ありきで設計を進めてしまうパターンだ。
クラウドと時を同じくして、“Software Defined”ブームが起こった。ネットワークやストレージといったハードウェアをソフトウェアで実装する、もしくはソフトウェア的に制御するという考え方だ。多くのベンダーが、その製品をOpenStackと組み合わせて動かすため、ドライバーやプラグインを提供している。
だが、これがバランスを崩す原因になることがある。
例えば、OpenStack以前になぜかSDN(Software-Defined Networking)製品の採用が決まっていた案件があった。理由は不明である。それによって組み合わせられる他技術の選択肢が狭まり、設計の大きな制約条件となっていた。また、OpenStackとの組み合わせでは使えない独自機能が前提となっており、話を戻すのに苦労した。そして、製品コストの内訳は、8割がネットワーク製品。これでは本末転倒である。
新しい技術を導入してビジネスに貢献したいという動機は否定できない。だが、それが本当に必要なものか、個別最適に陥っていないか、冷静に見極めるべきである。
第5回は、設計に入る「前夜」までに、アーキテクトに意識してほしいアンチパターンをまとめた。若干刺激の強い表現があったかもしれないが、ご容赦いただきたい。刺激が強かった文、これからOpenStackに取り組む読者の皆さまの記憶に残れば幸いである。
次回はいよいよ最終回、基本理念に続き、技術的なポイントを紹介する予定だ。ご期待いただきたい。
HPのクラウドの方向性、最先端の開発状況を日本のお客さまにお伝えし、かつ日本のお客さまの声を米国HP本社にフィードバックする役割を担う。アーキテクトとして設計支援も担当。
公共分野のソフトウェアエンジニア、通信業界担当のプリセールスエンジニアを経て現職。趣味はビール。
日系ベンダー、SIerを経て現職。アジアパシフィックリージョンの導入、構築案件などを担当。趣味は子育て。
Copyright © ITmedia, Inc. All Rights Reserved.
ハロウィーンの口コミ数はエイプリルフールやバレンタインを超える マーケ視点で押さえておくべきことは?
ホットリンクは、SNSの投稿データから、ハロウィーンに関する口コミを調査した。
なぜ料理の失敗写真がパッケージに? クノールが展開する「ジレニアル世代」向けキャンペーンの真意
調味料ブランドのKnorr(クノール)は季節限定のホリデーマーケティングキャンペーン「#E...
業界トップランナーが語る「イベントDX」 リアルもオンラインも、もっと変われる
コロナ禍を経て、イベントの在り方は大きく変わった。データを駆使してイベントの体験価...