過去20年間で、Linuxは純粋なオープンソースのインスピレーションから、あらゆる業界の隅々で企業レベルのユーザーをサポートできる主流のオペレーティングシステムへと変貌を遂げました。
Linuxの進化は直線的なものではありませんでした。オープンソースは、このシステムを開発者にとって最も魅力的なものにしている主なセールスポイントであることは間違いありませんが、商業化のプロセスも同様に満足のいくものであり、急速にユーザーの信頼を獲得し、市場で支配的なソリューションのひとつとなりました。
技術的な観点から見ると、Linuxの軌跡を一般化することは不可能であり、さまざまなケースについて個別に分析する必要があります。仮想化を例にとると、仮想化環境におけるLinuxの歴史は誰の想像もはるかに超えていますが、企業向けに大きく前進したのはここ数年のことです。クラウド・コンピューティングは現在、新たなスプリントの出発点となっており、クラウドICTソリューションとサービスの利点は十分に立証されています。しかし、エンタープライズ・クラウド・サービスなどのソリューションの実装は、ストレージ、コンピュートなど、異なるブロックに厳格に分割されることがよくあります。さらに、異なるクラウド・サービス・プロバイダーが提供するプロプライエタリなサービスは、互いに「会話」することができず、オープンソース技術によって取り除かれるべき強固な障壁となっています。
OpenStack Foundationが主導するオープンソースのクラウド・コンピューティング・プロジェクトであるOpenStackは、インフラストラクチャー・アズ・ア・サービス・ソリューションをユーザーに提供することを目的としています。Linuxや仮想化など、企業におけるクラウドの実装が直面している重要な問題は、「もし」ではなく「いつ」かということです。150社のテクノロジー企業が前向きな回答をしており、誰もが安心してOpenStackに賭けることができるはずです。しかし、利害関係者の数が非常に多いということは、プロジェクトの実際の状況とその成功をしばらく正確に測定することができない可能性があるということです。
OpenStackは、よりコスト効率の高い方法でIaaSを導入する可能性をビジネスユーザーに提供します。コアとなる価値提案の1つは、コンピュート、ネットワーキング、ストレージなどのサービスを、ハードウェアではなく、完全にソフトウェアで実装できるようになったことです。しかし、OpenStackが急速に成熟するにつれて、従来のアプリケーションはこの未来のリソースシステムにまだ馴染んでいません。このような状況の中で、OpenStackを中核として生み出されたさまざまなビジネスモデルを軽く見て、これらのモデルが自社のブランドをオープンソースのクラウドプロジェクトとどのように整合させることができるかを体験するのは良いアイデアです。
企業ユーザーがOpenStackの導入を検討する際、管理者はITの観点からプロジェクト管理を計画すること、つまり、企業の重要なワークロードをすべて分類した詳細なソリューションモデルを開発することが重要です。このモデルでは、クラウドセキュリティ、ロケーションルール、相互接続性、さまざまなアプリケーションやアプリケーション機能の相関性などの基本的な事項を考慮する必要があります。
これらは、すべてのITプロジェクトマネージャがOpenStackの実装に移行する際に答えられなければならない重要な質問のほんの一部です。もちろん、それだけではありませんし、質問に対する正確な答えは、導入するビジネスの種類、ITインフラ、財務予算、企業のIT文化によって異なります。OpenStackへのやみくもな進軍は、誰もがしっかりとした計画を立てなければ、100パーセント失敗に終わるという諺がエンタープライズ・スペースにはあります。
多くの組織は、事前に優れたパイロットやテストを実施し、構造化された一貫性のある技術モデルを確立しています。しかし、準備が整っていなかったり、完全に的外れであったりする組織も多くあります。基本的なリファレンスや報告記録は、プロジェクトや一連のプロジェクトにおける作業の優先順位を決めるのに十分ではありません。全体像が確立されて初めて、移行できるもの、レガシーデータセンターに残すべきもの、そして最終的には、保持と移行の適切なバランスを取る方法について、組織が賢明な判断を下せるようになります。
マルチ仮想化/IaaSソリューションの管理をよりスムーズに行うためには、Red HatのClouDormsのような「管理者の管理者」ソフトウェアソリューションが非常に重要になります。-は非常に重要です。それは、ビジネスプロセスをシームレスにするためです。これを実現するためには、ビルディングブロックのための一連のアーキテクチャモデルが必要です。移行するアプリケーションの観点からは、関係するリソースをより正確に評価することができます。そして現実的な観点から、プロジェクトマネージャーはレガシーシステムに注意を払いながらOpenStackを採用しなければなりません。
どのオブジェクトを移行できて、どのオブジェクトを移行できないかが明確になったら、組織が次にすべきことはOpenStackに移行することであり、そのときにベンダーが推奨するビジネスモデルを見直す必要があります。意思決定者はベンダーのめまぐるしい選択肢に直面することになるでしょう。OpenStackのオープンソースの利点を増幅しようとするベンダーもいれば、「OpenStack」を大きく変え、プロプライエタリ・ベースのソリューションを開発しようとするベンダーもいます。OpenStackは現実よりも名前になり、ビジネス・プロセスは長い間、従来のソリューションに縛られることになるでしょう。
ビジネスモデルを選択する際に本当に必要なのは、ビジネスとテクノロジーの要件を理解しているパートナーです。プロジェクトによっては、特定のテクノロジーが注目され、何を、いつまでに、いくら欲しいのかという質問に対する答えを事前に確定しておく必要があります。その他のテクノロジー・ソリューションについては、過去にそのような分野についてほとんど知られていなかったため、将来が不透明な場合があります。つまり、信頼できるパートナーは、これらの目標を達成し、組織を健全な成長軌道に速やかに乗せることができるのです。
通常の状況では、ITランドスケープ全体をOpenStack環境に移行することは、一般的に望ましくありませんし、可能でもありません。その結果、レガシー管理への取り組みは継続的な課題として残ることになり、特にレガシーシステムは、時間の経過とともにますます多くの管理圧力をもたらすことになるでしょう。20年前、多くの人がメインフレームの終焉を予測しましたが、今日でもメインフレームを扱う必要があることはよくあります。同じ意味で、OpenStackクラウドは、どんなシステムにも適したビジネス環境では決してありません。
OpenStackはサポートされたサービスとして利用することができ、1回限りのインストールとして堅苦しく扱う必要はないことを覚えておくことが重要です。カスタムソリューションは莫大な投資とコストがかかるだけでなく、ビジネスユーザーはその後の管理やメンテナンスのオーバーヘッドに対処しなければならなくなります。完全にオープンなサブスクリプションモデルでOpenStackを使用することで、ビジネスプロセスを単一のベンダーに縛られることを避けることができます。つまり、十分にサポートされたパッケージを選択することで、パッチ、セキュリティアップデート、バージョンアップの修正にかかる労力を大幅に簡素化することができます。
ここまで根気よく読んでくださったということは、OpenStackに十分興味を持たれていることでしょうし、あなたのアジェンダに必ず入れておくことをお勧めします。また、オープンソース技術への深い関心から、企業環境にLinuxを導入していることも間違いないでしょう。何しろ、OpenStackのコンフィギュレーションとライフサイクル管理のメカニズムは、エンタープライズ環境でもLinuxディストリビューションと同じように機能するのですから。
