VMWare と Broadcom 後のインフラソフトウェア依存の運用コスト

概況

VMWare は、公開製品、ドキュメント、サポート、セキュリティ、ステータス面から、仮想化プラットフォームが長期的な運用義務を生み出す理由を示すインフラソフトウェア依存として読むべきです。
主なコストは単にサブスクリプションや移行の価格ではなく、バージョン管理、サポートチャネル、セキュリティアドバイザリ、統合、ロールバック計画、そして多くの他のシステムの下にあるプラットフォームを変更するリスクに関する監視作業です。

ディレクトリリンク:VMWare

VMWare が運用依存であり続ける理由

仮想化インフラは、ほとんど分離されていないため変更が困難です。アプリケーションサーバー、ID サービス、ストレージの前提、バックアップルーチン、監視エージェント、ディザスタリカバリ計画、管理上の習慣を伴います。VMWare の公開製品ページや vSphere の資料は、同社がこのインフラ層に位置するという基本的な主張を裏付けています。ドキュメント、サポート、知識ベース、セキュリティアドバイザリ、ステータスページは、依存関係のもう一方の側面を示しています。顧客はソフトウェアを購入するだけでなく、長期的なメンテナンス関係に参加するのです。

この関係が記事の主題です。VMWare の報道は、プラットフォームが重要であるという曖昧な記述に依存すべきではありません。公開記録により、より正確に述べることができます。顧客は製品を追跡し、ドキュメントを読み、サポート経路を利用し、アドバイザリを監視し、サービスのステータスを確認する必要があります。デスクトップハイパーバイザーページは別の面を追加します。開発者やローカルテスト環境は、戦略的なインフラ選択が変わった後も長く組織内に残ることがあるからです。プラットフォームは十分に安定して見えなくなることがありますが、バージョン、アドバイザリ、サポートチャネルの変更によって運用の視野に戻ってきます。

VMWare が削減する作業と生み出す作業

仮想化は一連の物理インフラの負担を軽減します。チームは共有ハードウェアで複数のワークロードを実行し、デプロイメントパターンを標準化し、環境を分離し、一度に1台のマシンではなく管理層を通じて運用できるようになります。この削減は現実的です。公開されている vSphere および製品資料はこのサービスカテゴリを裏付け、より広範な VMWare のドキュメント面は、顧客が単純なユーティリティではなく複雑な運用モデルを受け取ることを示しています。

生み出される作業も同様に現実的です。管理者はバージョン規律を必要とします。セキュリティチームはアドバイザリの取り込みとパッチの優先順位付けを必要とします。アプリケーションチームは、インフラ変更がパフォーマンスや可用性に影響を与える可能性がある時期を知る必要があります。財務および調達チームはサポートと契約構造を追跡する必要があります。経営陣はプラットフォームを交換可能と見なす前に移行計画を必要とします。これらの義務はプラットフォームに慣れても消えません。慣れることで見落としやすくなる可能性があります。

最も困難な作業は、穏やかな日に1つのクラスターを稼働させることではありません。頻繁なプラットフォーム移行を想定して設計されていないアプリケーションの下の基本層を変更することです。ワークロードは、ストレージの動作、バックアップツール、スナップショット、ネットワーキングの前提、長年にわたって蓄積された管理者の知識に依存する場合があります。したがって、移行はソフトウェアの選択のように見える一方で、実際には組織的な監査となる可能性があります。

Broadcom サポート面がガバナンスの課題を変える

引用されたサポートおよびナレッジページは Broadcom ドメインにあり、VMWare の製品およびドキュメント資料はソースセットの中心に残っています。この公開サポート面は、移行ガバナンスを記事の一部とするのに十分です。ウェブサイトの構成から顧客のプライベートな結果を推測するのは無責任ですが、顧客がサポート、ドキュメント、ナレッジ資料がどこにあるかを知らなければならないと言うのは妥当です。

サポート面の移行はルーチンを変えます。チケット経路、ナレッジベースの参照、アカウントアクセス、エンタイトルメントチェック、アドバイザリ監視は見直しが必要になる可能性があります。顧客が古いラン�ブック、ブックマーク、またはサポートソースに関する自動化を持っている場合、それらは更新が必要になるかもしれません。リスクはすべての顧客が失敗することではありません。リスクは運用記憶が公開サポート構造に遅れをとることです。

ここでソフトウェアライフサイクルとロックインが具体化します。ロックインは契約条件だけではありません。それはプラットフォームを中心とした手順、スクリプト、スキル、統合、復旧計画の蓄積です。顧客が技術的に移行できたとしても、それらの習慣を置き換えなければなりません。VMWare の公開サポート、ドキュメント、製品ページは、なぜその作業が評価に含まれるべきかを示しています。

セキュリティアドバイザリは製品の一部

インフラソフトウェアは通常のビジネスアプリケーションとは異なるセキュリティプロファイルを持ちます。仮想化層の脆弱性は、ホスト、管理インターフェース、バックアップ、メンテナンスウィンドウ、顧客アプリケーション間の調整を必要とする可能性があります。VMWare の公開セキュリティアドバイザリページはその面を可視化します。アドバイザリの存在は、特定の顧客がリスクにさらされていることやインシデントが発生したことを証明するものではありません。アドバイザリの取り込みがプラットフォーム運用の通常の一部であることを示しています。

購入者にとって、これはコスト計算を変えます。プラットフォーム価格は、それを安全に維持するコストと比較されるべきです。誰かがアドバイザリに購読し、深刻度を分類し、影響を受けるバージョンをマッピングし、変更をスケジュールし、互換性をテストし、例外を記録する必要があります。組織にそのプロセスが欠けている場合、リスクが適切に理解されていないプラットフォームを稼働し続ける可能性があります。プロセスがあれば、プラットフォームは管理可能になりますが、労力は計上されなければなりません。

ステータスページも同様の役割を果たします。一部の VMware サービスの公開サービス状態の証拠を提供できますが、すべての顧客環境を説明するものではありません。運用チームがプロバイダーまたは内部エスカレーションを開始する前に公開サービスコンテキストを確認するための一元的な場所が必要であるため、有用です。ローカルインフラが健全かどうかの証明にはなりません。

デスクトップハイパーバイザーは小さいながらも重要な依存関係を追加します。Workstation および Fusion 環境は、ローカルテスト、トレーニングラボ、レガシーアプリケーション、管理者ルーチンをサポートすることがよくあります。これらは企業のインフラ計画の戦略的中心ではないかもしれませんが、エンジニアが問題を再現し、変更を準備する方法を形成する可能性があります。これらのツールのアクセス、パッケージング、サポート、互換性が変更された場合、その影響は正式なアーキテクチャ図に現れる前に、開発および運用の習慣に現れる可能性があります。

移行は単一の決定ではない

VMWare の代替を検討している顧客は、パブリッククラウド、コンテナプラットフォーム、ハイパーコンバージドインフラ、オープンソース仮想化、マネージドプライベートクラウド、または現在のスタックのより遅い継続を比較するかもしれません。これらの選択肢はどれも無料ではありません。パブリッククラウドはコスト管理とガバナンスを変更します。コンテナは複雑性の一部をアプリケーションアーキテクチャに移行します。オープンソースオプションはスキルとサポート計画を必要とします。マネージドプライベートクラウドはベンダー境界を変更します。現状維持は親しみやすさを保ちますが、価格設定、サポート、ライフサイクルの変化に対するエクスポージャーを増やす可能性があります。

難しい質問は、移行リスクを考慮した後の安定したワークロードあたりのコストです。移行に長期間の並行運用、再トレーニング、互換性修正、書き直されたディザスタリカバリ手順が必要な場合、より安いプラットフォームがより高くつく可能性があります。親しみのあるプラットフォームは、そのライフサイクルやサポート構造が定期的なレビュー作業を生み出す場合、高くつく可能性があります。したがって、VMWare の価値とリスクは同じ場所にあります。それは深く組み込まれていることです。

したがって、規律ある移行レビューはインベントリから始めるべきです。どのワークロードが vSphere の動作に依存していますか？どのバックアップおよび監視ツールが現在のプラットフォームを前提としていますか？どのチームが復旧プロセスを知っていますか？どのデスクトップ仮想化ルーチンが開発チームやサポートチームをサポートしていますか？どのアドバイザリがまだ使用中のバージョンに適用されますか？答えは、維持、ゆっくりとした移行、またはワークロードの分割を正当化するかもしれません。間違いは、プラットフォームを代替機能リストだけで判断できるふりをすることです。

テストウィンドウも過小評価されがちなコストです。インフラソフトウェアは、依存するチームがリスクを受け入れられる場合にのみパッチ適用または交換が可能です。メンテナンスウィンドウには、所有者、サンプルワークロード、互換性チェック、監視基準、復旧計画が必要です。更新がホスト、管理ツール、バックアップの前提に同時に影響する場合、顧客は通常別々のキューで作業する人々を調整する必要があります。その調整は、ダウンタイムが発生しなくても、プラットフォームの経済的コストの一部です。

公開証拠が証明しないこと

公開ソースセットは、顧客数、更新行動、プライベートなライセンス結果、ワークロードパフォーマンス、ダウンタイムの影響、Broadcom の内部計画、地域データ局所性、施設所有権、または顧客内部の特定のアーキテクチャを確定するものではありません。これらの事実には、顧客の証拠、提出書類、契約、インシデント記録、または技術的開示が必要です。この記事は憶測によってそれらのギャップを埋めるべきではありません。

安全な結論は依然として意味があります。VMWare は、公開製品、ドキュメント、サポート、アドバイザリ、ステータス面が継続的な運用上の注意を必要とするため、主要なインフラソフトウェア依存関係であり続けます。これを一度きりのプラットフォーム選択として扱う顧客は、作業を過小評価する可能性があります。これをライフサイクル関係として扱う顧客は、維持、変更、段階的移行についてより明確な決定を下すことができます。

画像の境界と帰属

掲載画像は実際の Wikimedia Commons のサーバーラック写真であり、一般的な編集用インフラコンテキストとしてのみ使用されています。VMWare、Broadcom、その施設、スタッフ、顧客、設備、サービス状態、またはインシデントを示すものではありません。記事の主張は、引用された VMWare および Broadcom の公開ページ、ならびにステータスおよびアドバイザリ面に基づいており、画像からではありません。