コメント個々のデバイスを適切に管理することが重要ですか、それとも資産全体をより高いレベルで管理することが重要ですか?
現時点で利用可能な管理ツールの性質上、現状では選択を迫られています。ここではストレージ分野に焦点を当てますが、私の見てきた限りでは、この問題はITのほとんどの分野に影響を及ぼしています。
問題は、デバイスを開発するチームが、少なくとも当初は、管理ツールの大部分を開発しているという事実にあります。デバイスとツールは並行して成長し、テストチームとQAチームは、機能エンジニアリングチームが作成した機能をテストする方法を必要とし、顧客や初期投資家に機能をデモンストレーションするシンプルな方法も必要になります。
当初、これらのユーザーインターフェースは制限的な設計になっています。間違った操作があまりにも容易であれば、多くのユーザーがその道を選んでしまい、その結果、新しいデバイスはたちまち悪いレビューや劣悪なユーザー体験の犠牲になってしまいます。提供されるツールでできることを制限することで、列車は軌道から外れず、コードは十分にテストされた道筋に沿って進むことになります。その結果、起こり得る結果は、はるかに短時間で、ひいては低コストでテストできる範囲に限定されます。
ちょっと待ってください。誰がそれを入れたのですか?
問題は、製品が成長し、製品の管理が別のチームの責任となると、一部の制限の歴史的根拠が時の霧の中に忘れ去られてしまうことです。しかし、制限は依然として存在し、ユーザーはネイティブソフトウェアで本来であれば非常に有用なタスクを実行できないのです。こうした「制限」には別の副作用もあります。革新的で産業的なユーザーは、望む機能を実現するために別の手段を探す必要に迫られるのです。DevOpが人気と勢いを増している今、このことはかつてないほど深刻になっています。
このトレンドを的確に捉え、より人気のある開発コミュニティの先導に倣い、ユーザーがソフトウェアを創造的に活用できるよう支援することで、このトレンドを巧みに捉えるには、賢明な組織が必要です。ベンダーは、販売するキットやエンドユーザーが何を求めているかについて、あまりこだわりすぎないようにする必要があります。
この道を歩んできた企業の一つがNetAppです。私は長い間、Data Fabric Manager（DFM）、あるいは現在ではOnCommand Coreと呼ばれているものに苦労してきました。
ちょっとした余談ですが、マーケティングチームの皆さんへ… 全ての製品を似たような名前で呼ぶだけでは、統一されたアプローチとは言えません。製品がそれぞれ異なるタスクを実行し、外観や操作性も異なり、互いに完全に独立している場合、全てをUni-何とかやOnCommandなどと呼ばないでください。それぞれ異なる製品なので、異なる名前を付けてください。大人数のグループに製品について話している時、どの製品について話しているのかで参加者が50%に分かれる方が、混乱がはるかに少なくなります。愚痴はここまで。
では、OnCommand Coreとの葛藤に戻りましょう。これは悪い製品ではなく、むしろ優れた製品です。NetAppが目指していたものを達成できなかったわけではありません。かなり近いところまで到達していると確信しています。問題は、NetAppがOnCommandに込めた目標が、ほとんどのエンドユーザーがOnCommandで実現したいと願うものとはかけ離れていることです。
「WFA」とその他の解決策
しかし、以前も述べたように、NetAppは最近、Work Flow Automatorという形でより革新的な道を歩み始めました。その後、OnCommand Flowとか、マーケティングに優しい名称でブランド化されたことは間違いありませんが、この製品を中心に形成されたコミュニティ（私もメンバーの一人です）では、WFAと呼ばれています。これはNetAppのまさに天才的な動きだったと思います。
この製品は、かつて Onaro だったチームと SanScreen 製品 (現在は OnCommand Insight、Perform (もっと明確に言う必要がある場合) として知られています) の作成者が開発した製品です。この製品のインテリジェンスは、すぐに使える機能 (少し複雑ではありますが、すでに非常に優れています) から得られるのではなく、ユーザーが実行できる機能から得られます。
非常に優れたビルディングブロックのセットを提供していますが、さらに重要なのは、非常に強力なPowerShellツールキットを使用して、新しいブロックを作成したり、既存のブロックを拡張したりするためのシンプルな手段を提供していることです。NetAppは常にAPIアクセスの提供に優れており、全体的に非常に優れた安定性を備えています。これにより、NetApp自身はFASプラットフォームのハードウェアとコアソフトウェア機能に集中しながら、多くのパートナー企業がプラットフォームを基盤としたツールやアプリケーションを開発することが可能になりました。
これにより、BMC、VMware vSphere、Microsoft Hyper-V など、非常に高速で機能が豊富でサポートが充実した製品へのアプリケーション統合が実現しました。これらはすべて、エコシステムに対してよりクローズドなアプローチを取るベンダーがしばしば苦労する点です。
ベンダー:ユーザー プール内の人材を活用しましょう...
WFAはこのアプローチを採用し、ビルディングブロック方式を採用することで、よりシンプルな構成を実現しています。つまり、非常に強力で個々の要件にぴったりと合うオーケストレーションまたは管理プラットフォームを、わずかな時間で構築できるということです。昨今のほとんどのアプリケーションプラットフォームには、PowerShellインターフェース（その成功度は様々ですが）が搭載されているため、WFAはこれらの製品を同じワークフローに統合することを可能にします。
この製品を中心に成長しつつあるエコシステムは、クラウドと自動化インフラ分野への足掛かりを築く上で、NetAppにとって大きな推進力となる可能性を秘めています。管理と統合のシンプルさから、今私が真っ先に検討するプラットフォームの一つであることは間違いありません。
NetAppのAPIオープン化と、キットのパワーユーザーが自身の問題を解決するだけでなく、その成果を共有し、他のユーザーの同じ問題を解決するためのインセンティブと機会を提供するという点において、他のベンダーもNetAppに倣うことを期待しています。これこそが強力なコミュニティを築き、製品を強力にするのです。
DevOpsを活用し、ユーザープールの才能を最大限に活用してください。私たちを制限したり、おもちゃを壊す子供のように扱ったりするのはやめてください！私たちは、自ら招いたミスの責任を負うほどに大きく、そして醜い存在です。堅牢なガイドラインと徹底した理解によって、私たちをより良くし、製品を取り巻くイノベーションの壁を取り除いてください！
エンドユーザーに関しては、責任あるコミュニティメンバーとしてソリューションを共有し、そのコミュニティのオープン性をサポートし、ベンダーがオープン API を提供およびサポートする取り組みをすべての人にとって価値ある、やりがいのあるものにすることで、支援することができます。
オープンソースの LUCR データセンター管理プロジェクト（別名 LucrDCIM）のスクリーンショット（詳細についてはクリックしてください）
Lucr*は現在、こうした共有とコミュニティ精神を少しでも刺激できるようなプロジェクトに取り組んでいます。まずは、私たちが最もよく利用するテクノロジー（WFAとAPIアクセスを介したNetAppストレージ、そしてVMware仮想化）をベースに、SMI-SやCDMIといった業界標準と組み合わせ、ITサービスの物理的および論理的構築を管理するデータセンター管理製品を構築しています。
コミュニティの部分については、GitHubを通じて全体をオープンソースとして公開します。現在、このプロジェクトはLucrDCIMという愛称で呼ばれていますが、この名称についてはぜひ皆さんと共同で検討したいと考えています。現在、この移行をサポートするためのドキュメントや関連資料をまとめているほか、異なる、あるいは時には競合するライセンスモデルを持つ複数のオープンソースプロジェクトを統合するという法的な難題を解決すべく作業を進めています。これら全てが完了したら、詳細をお知らせいたします。
プロジェクトについてもっと詳しく知りたい方、あるいはより早い段階からプロジェクトに参加したい方は、[email protected] までお気軽にご連絡ください。皆様のご参加をお待ちしております。ベンダーの皆様、エンドユーザーの皆様にも、この非常にエキサイティングなプロジェクトの未来を形作るために、ぜひご協力をお願いいたします。®
* Glyn Bowden 氏は Lucr Ltd. の創設者兼 CEO です。
