ソフトウェア会社の成功するプロジェクトはそれぞれアイデアから始まりますが、それが実際の製品になる前に、試行錯誤の長い道のりを歩かなければなりません。 今日は、市場性のある製品になる可能性のある（またはできなかった）Virtuozzoプロジェクトについてお話します。
ソフトウェア会社は常に、開発の方向性について決定する必要があります。 Virtuozzoにはそのようなユニット、つまりプログラム管理部門があります。 既存の製品のロードマップ、リリースとアップデートのリリース、開発計画に責任を持つ人々を雇用しています。 したがって、プログラムマネージャーの活動は3つの大きなセクターに分けることができます。
- 市場の要件に応じた開発。 これは、既存のトレンドに対応した製品の作成、業界トレンドへのリリースの適応です。 たとえば、市場でDockerコンテナを使用する必要が生じた場合、ハイパーバイザーのレベルでそれらをサポートするメカニズムの開発に着手しました。
- 現在の顧客のニーズに合わせた開発は、ユーザーから受け取ったフィードバックによると、リリースの最終化です。 それは、明示的な「Guys、スタックに関する問題の解決に役立つ」か、改善の明らかな必要性の概要を説明する定期的な技術サポートリクエストの形で提供されます。
- そして最も曖昧なのは実験的な方向です。 多くの場合、特定の問題を解決できるかどうか、そしてこのソリューションがどれだけ需要があるかはわかりません。 時々、従業員がアイデアを持ち、チームがそれを良いアイデアと見なす場合、プロトタイプをリリースして、それから製品を作成しようとします。
実験と現実
会社の仕事にそのような方向性が存在することは、市場で成功するだけでなく、業界をある程度変える自然で成功することが多い製品やツールの出現の機会を作り出します。 ところで、これがVirtuozzo Storageプロジェクトの誕生方法であり、分散ストレージシステムとして開発することが決定されました。 2010年には、サーバーディスクを使用して仮想マシンを分散データストレージシステムに統合することが提案されました。現在、Virtozzo Storageはエコシステムの3つの基盤の1つです。
市場に出回っている製品がプロトタイプで始まったとき、さらにいくつかの例を挙げることができます。 3月にリリースしたPower Panel製品の完全に再設計されたアーキテクチャも、同様のプロジェクトから始まりました。 しかし、常に実験から製品の外観がもたらされるわけではありません。 ただし、否定的な結果は結果でもあります。 実際、それなしでは、より有望なプロジェクトを見つけることは不可能です。 この機会またはその機会をテストするために、1〜2人の開発者（この分野に関心のある人）を選択し、数週間または数か月間調査を実施します。 さらに、個別の製品の外観、または既存のソリューションの1つに「チップ」が含まれている、または方向性が見込みのないものとして閉じられている可能性があります。
失敗したテスト
2006〜2007年の変わり目に、当社の開発者は、製品PSBM（Parallels Server Bare Metal）と同様に、MACサーバー用の仮想化ソリューションを作成するというアイデアを持ちました。 興味深いことに、この製品は研究状態から抜け出し、開発段階を経て、テストに至りました。 しかし、それから2つの不快なニュアンスが判明しました。 第一に、AppleはBIOSなどの重要なシステム要素の閉じた部分で常に有名であり、特定のハードウェア構成で問題を引き起こしました。 これらの問題を完全に解決することはできませんでした。 さらに、最初は噂レベルで、Appleがサーバーラインを開発しないことがわかったため、プロジェクトを終了することにしました。 まあ、決定は正しかったことが判明しました-そして、2010年にAppleは本当にサーバーを放棄し、私たちが開発した製品は決して発表されませんでした。
悲しいかな、私が話したい2番目のプロジェクトは、研究段階から抜け出すことさえしませんでしたが、最初は非常に魅力的でした。 いわゆるMeta-PCのプロトタイプの作成に取り組みました。これは、1つのアプリケーションの共通の能力を使用して、複数のサーバーで同時に作業するためのランタイム環境を作成できるツールです。 実装が成功した場合、このような製品は、アプリケーションを垂直にスケーリングし、1つのコンピューターまたはサーバーが提供できるよりも多くのCPUとRAMを1つのプロセスに提供することを可能にします。
プロジェクトは終了しました。この場合の理由は市場の動向です。 状況を研究した結果、今日ではこのような問題はさまざまに解決されていることに気付きました。個々のマシンの能力がアプリケーションに対して十分でない場合、開発者はアプリケーション自体の設計へのアプローチを変更し始め、分散コンピューティングテクノロジーと水平スケーリング方法を使用します。 その結果、MapReduceやコンテナー管理環境などのテクノロジーが急速に発展し始めました。 数か月の研究の結果、垂直方向に拡張できるこのようなソリューションの市場は非常に小さくなり、そのためプロジェクトは単純に終了したことが明らかになりました。
市場で多くの成功を収めた後、プロジェクトが閉じられ、後の段階にある例がありますので、たとえば、Microsoft WindowsエコシステムでOSコンテナーを操作するソリューションは、約10年間製品ラインにあります。 システムは開発、テスト、起動され、独自のユーザーが存在し、プロジェクトは開発中でした。 しかし、さらに-クローズドWindowsカーネルでの作業はより困難になり、より複雑なクライアントリクエストを実装することは不可能になりました。 はい、Windowsには多くのAPIがありますが、それらはそのようなタスク向けではありません。 また、カーネル要素を使用してOSコンテナを起動しようとする試みは、ブラックボックスで何かを見つけようとする試みに似ています。 そのため、2015年にプロジェクトは終了し、カーネルソースコードが利用可能であり、オペレーティングシステムのコンテナーから簡単に使用できるLinuxのコンテナー化に焦点を当てることになりました。
おわりに
ただし、最後にもう1つの非常にわかりやすい例を示します。これは、アプリケーションのライブマイグレーションのシステムです。 2005年、デベロッパーは、一連のプロセスをフリーズし、ファイルに保存し、他の条件および異なるハードウェアで解凍するという興味深いことを試みることにしました。これは、仮想マシンのライブマイグレーションとほぼ同じですが、基本的にこれらを「カット」オペレーティングシステムのカーネルからのプロセス。
それでも、多くの人がそのようなスキームは実装できないと言っていましたが、我々はそれをしました！ うまくいったときに、Linuxカーネルに含めるライブマイグレーション用のツールを提案しようとしました。 しかし、実際には、コミュニティは提案されたすべてのイノベーションを常に受け入れるとは限らず、カーネルの各後続バージョンにそれらを導入するのは非常に高価です。 そして、ユーザー空間にバックアップシステムを開発することが決定されました。 これがCRIUプロジェクト（www.criu.org）の始まりであり、「ライブマイグレーション」の分野における主要なツールになっただけでなく、Linuxカーネルに貢献してツールキットがすべてのバージョンのLinuxで機能するようになりました。 そのため、プロジェクトに利益が出るかどうかわからない場合でも、実験することをお勧めします。