仮想化できないって言ったって！

ITの現場では、ベンダーからシステムを仮想化できないと言われることがよくあります。その理由はさまざまです。ITの立場からすると、そのような無茶な主張をするベンダーには毎回驚かされますが、顧客（または管理職）がそれを信じてしまうことにも同様に驚かされます。ベンダーは長年かけてこのセールストークを磨き上げており、それを分析することは重要だと思います。

問題の根本原因は、ベンダーがほぼ常に自社のコストを下げながら顧客からの利益を増やす方法を模索していることにあります。これが、一見奇妙に見える多くの行動を引き起こしています。

非常に多くのベンダーが試みることの一つは、自社製品がサポートされるシナリオを制限することです。こうすることで、費用がかかり信頼性の低いサポートを単純に提供しないで済む態勢を整えます。これは一般的な戦略です。場合によっては、これが非常に積極的に行われるため、許容できる本番環境のデプロイシナリオが存在しなくなることすらあります。

これを実現する非常に一般的な手段の一つは、サポートされているオペレーティングシステムをサポートしないことで、事実上ベンダー自身のソフトウェアを廃止扱いにすることです（例えば、今日であればWindows XP以前のみをサポートするといった形です）。別の例としては、ユースケースに対してライセンスされていない製品のみをサポートすること（Windows 10をサーバーとして使用することを要求するなど）があります。そして最も一般的なケースの一つが、仮想化の禁止です。

これらのシナリオは顧客を難しい立場に追い込みます。一方では業界のベストプラクティス、標準的なデプロイガイドライン、社内ツールやポリシーに従う必要があり、他方ではベンダーが適切なシステム設計、計画、管理を禁じていることがあるためです。これらのニーズは互いに相反しています。

もちろん、すべてのベンダーがあらゆる潜在的なシナリオをサポートすることを期待する人はいません。制限は必要です。しかし、合理的で適切にデプロイされたシステムをサポートすることと、許容できないほど劣悪なデプロイを積極的に要求することの間には大きな隔たりがあります。私たちはベンダーがビジネスパートナーとして振る舞い、私たちの成功、あるいは少なくとも自社製品の成功に共通の関心を持つことを望んでいます。最低限、合理的なデプロイシナリオに対してベストエフォートのサポートが提供され、適切に設計されたベストプラクティスのシナリオに対しては保証付きサポートが提供されることを期待します。

制限速度を守ってシートベルトを着用することが車の保証を無効にし、無謀な無防備な運転をした場合にのみサポートが受けられる世界を想像してみてください！

仮想化について理解しておくべき重要なことがあります。まず、仮想化は長年にわたる業界のベストプラクティスであり、サービスの本番環境デプロイシナリオにおいて使用されることが期待されています。仮想化は決して新しいものではなく、中小企業市場においてもベストプラクティスのカテゴリーに入ってから10年以上が経過しており、エンタープライズ分野では何十年もの歴史があります。システムを非仮想化で実行することが許容できると見なされる段階はとっくに過ぎており、それは長期間稼働してきたレガシーデプロイメントも含みます。

もちろん、ほぼすべてのルールには稀な例外が常に存在します。非常に特殊なハードウェアへのアクセスが必要なシステムでは仮想化が不可能な場合もありますが、現代のハードウェアパススルー技術により、今日ではほとんど聞かれません。また、超低レイテンシーシステムは仮想化できない場合もありますが、これは通常、最大規模の国際投資銀行や最も積極的なヘッジファンドに限られており、仮想化の改善によりそのような従来のユースケースの大半も排除されています。しかし結論として、仮想化できない場合はそれを残念に思うべきであり、なぜそれが不可能なのかを明確に理解しているはずです。それ以外の場合、サーバーは仮想化されている必要があります。

重要ではないのでしょうか？

ベンダーが健全なデプロイのための標準的なベストプラクティスに従うことを許可しない場合、それはベンダー自身の製品に対する見解について何を示しているのでしょうか？他のデプロイについて話しているなら、それに依存するつもりなのになぜそれほど劣悪なシステムをデプロイするのかを即座に問うはずです。ベンダーが私たちにこのように行動させるなら、同じように反応すべきです。ベンダーが自社製品を私たちの最も些細なITサービスと同程度にも扱わないなら、なぜ私たちがそうすべきなのでしょうか？

これは工学的な文脈で言う「インピーダンスミスマッチ」です。私たちのニーズ（本番システム）と、そのシステムを作るベンダーが製品をどのように扱っているように見えるか（趣味またはエンターテインメントシステム）の間のミスマッチです。ビジネスのためにこの製品に依存する必要がある場合、ビジネスニーズを理解しているベンダー、つまり本番対応の考え方を持つベンダーが必要です。製品がビジネス向けでないか、ビジネスに対応していない場合、そのことを認識する必要があります。そのような方法での使用が意図されていないサービスを本番環境で使用し、それに依存してサポートを必要とすることがなぜ適切なのかを問う必要があります。

サポートされているのか？テストされているのか？

顧客の視点からしばしば見落とされることは、製品に必要なサポートリソースが整っているかどうかです。製品をサポートするチームが縮小したり消滅したりすることは珍しくありませんが、会社は可能な限り利益を搾り取ることを期待して製品を販売し続け、問題をどうにかしのぐか、サポートが全くできない状況でベンダーが捕まった場合に顧客に返金することを頼りにしています。

ほとんどのソフトウェア契約では、ベンダーから取り出せる最大損害賠償は製品のコスト、つまり購入に費やした金額と定められています。このような状況では、ベンダーはサポートできない製品を提供することにリスクがありません。サポートのプレミアム料金を請求していても同様です。顧客が製品を使用できれば、ベンダーは報酬を得ます。顧客が使用できず、ベンダーもサポートできない場合、ベンダーは失うのは、そうでなければ得られなかったお金だけです。すべてのリスクを負うのはベンダーではなく顧客です。

これはもちろん、製品の継続的なテストもほとんどあるいはまったく行われていないことを示唆しており、これは追加的な懸念事項となるべきです。製品が動作するからといって、それが動作し続けるとは限りません。サポートされていない、あるいはさらに悪いことにサポート不可能な製品を起動して実行することは、時間の経過とともに潜在的なサポートレベルが低下する可能性が高い製品にますます依存することを意味し、ソフトウェアへの依存度とサポートの必要性が高まることが予想される一方で、状況は徐々に悪化していきます。

プロプライエタリな製品が本番環境にデプロイされ、サポート要件に対応するためにベストプラクティスのデプロイメントを諦めるという決定がなされた場合、これはどのように意思決定マトリックスに当てはまるのでしょうか？適切なサポートが存在しないことを意味するのでしょうか？前述の通り、これは私たちのニーズとのミスマッチを示唆しています。

 

まだ開発中なのか？

ソフトウェアのデプロイニーズが古い時代遅れの手法に従っているか、または時代遅れの（または合理的に最新でない）ソフトウェアや設計を要求する場合、製品が現在開発中である可能性を疑う必要があります。場合によっては、ソフトウェアのリリースサイクルをしばらく観察することでこれを判断できますが、すべての場合ではありません。製品は死んでおり、残っている開発チームがいないという合理的な懸念があります。コードは単に古く、廃止された古いコードベースから最後の数ドルを稼ごうとして売られている技術的負債かもしれません。このプロセスは、一般的に信じられているよりもはるかに一般的です。

小規模なソフトウェアショップは、多くの場合、初期ソフトウェアパッケージを開発し、市場に出して販売できるようにすることには成功しますが、初期リリース後に開発チームを維持または補充する余裕がないことがよくあります。これは実際には非常に一般的なシナリオです。これにより、顧客は時間の経過とともに実行可能性が低下し、デプロイシナリオがますますリスクを伴い、データの抽出がますます困難になることが予想される製品を抱えることになります。

 

プラットフォームがサポートされていない場合、どのようにサポートできるのか？

より極端な状況のよくあるパラドックスは、「サポート対象」と見なされるためには、サポートが終了しているか、または意図されたユースケースに対してサポートされたことがない他のソフトウェアを必要とするソフトウェアです。よくある例としては、サーバーシステムをデスクトップオペレーティングシステムの上で実行することを要求したり、まったくサポートされていないオペレーティングシステム、データベース、またはその他のコンポーネントのバージョンを要求したりすることがあります。この最後のシナリオは恐ろしいほど一般的です。このような状況では、ソフトウェアが「サポート対象」と見なされるデプロイが存在し得るのかを問う必要があります。スタックの一部が常にサポート外である場合、スタック全体がサポートされていないことになります。何がどうあっても、サポートを拒否される理由は常に存在することになります。したがって、ベストプラクティスを避けることを私たちに求める理由そのものが、最初からそのソフトウェア自体を選択しないことを等しく示唆しています。

業界のスキルと知識が不足しているのか？

このような性質のソフトウェアサポート問題で私たちが直面する問題は、ソフトウェアを作成するチームが単純に良いソフトウェアの作り方や良いシステムのデプロイ方法を知らないだけかもしれません。これは、このような状況に至る最も合理的で妥当な理由の一つです。しかし、他の仮説的な理由と同様に、ソフトウェアの品質とサポートが本当に利用可能かどうかについての懸念を残します。システムの最も目に見える部分を適切に処理することをベンダーに信頼できない場合、検証できない部分の専門家として彼らを頼ることができるでしょうか？

大きな問題

そうでなければ保留されていたサポートを解放するための交換条件として、疑わしいデプロイおよびメンテナンスの実践要求を持つソフトウェアの大きな包括的な問題は、私たちが通常想定するようなソフトウェア品質全体の問題ではなく、実行可能なサポートと開発実践の問題です。これらの問題が長期的なサポートに対する重大な懸念を示唆しているという事実は、最初から非常に目に見える深刻な懸念があるにもかかわらず、なぜ最初からこれらのパッケージを選択するのかを強く疑問視させます。

もちろん、ニーズを満たす他のソフトウェア製品が存在しない、あるいはより合理的な実行可能性のあるものが存在しない場合もあります。このような状況は極めて稀であるべきであり、そのような状況が存在する場合は、その特定の分野に参入しようとしているベンダーにとっての大きな市場機会と見なされるべきです。

ビジネスの観点からは、技術インフラのベストプラクティスを、他の状況では無謀または非専門的と見なされるようなベンダー要件を盲目的またはほぼ盲目的に従うことと引き換えに完全に無視することは絶対に許容できません。なぜ私たちはビジネスが依存するコア製品に対してこのように優秀さを要求することをしばしば怠るのでしょうか？それはビジネスをリスクにさらすものであり、単に行動そのものからだけでなく、そのような要件の存在によって示されるリスクによって、より大きなリスクをもたらします。