要約
- InterCloud は、受け入れられたクラウド接続状態によって評価されるべきである。それは、顧客の意図、プライベートトランスポート、ルーティングポリシー、クラウドプロバイダーへのハンドオフ、セキュリティ制御、監視、サポート証跡のすべてが同一の稼働サービスを示す時点である。
- BSO による買収は、旧 InterCloud の運用面に、より大規模なネットワークとサービスデスクのコンテキストをもたらすが、同時に境界規律の重要性を高める。すなわち、バイヤーは、どの約束が InterCloud のクラウド相互接続の遺産に由来し、どの約束が BSO のネットワークに由来し、どの約束がいまだにクラウドプロバイダーやキャリア、顧客チームに依存しているのかを知る必要がある。
企業は境界問題となった
InterCloud は、抽象的に小さなクラウド企業として扱われると最も誤解されやすい。より有益な見方は、より狭く、より要求水準が高い。同社は、エンタープライズネットワークとパブリッククラウドプラットフォームの間の領域に位置している。かつての公的なポジショニングは、ソフトウェア定義のクラウド相互接続であり、これは、企業サイト、データセンター、クラウドサービスをリンクするにあたり、各顧客チームが回線、ルーティング、セキュリティ制御、運用手順を一から組み立てる必要のない管理手法である。現在の公的な表面は、BSO に結びついており、同社は2025年3月、司法再編手続きの一環としてパリ商事裁判所の承認を得て、InterCloud を買収したと発表した。InterCloud の独自ドメインは現在、BSO の公開サイトへと解決される。これは表面的な詳細ではない。同社の見方を変えるものである。
バイヤーは単に「クラウド」を購入しているわけではない。バイヤーはクラウドサービスへの管理された経路を購入している。その経路は複合的な物体である。それには、物理的リーチ、パートナーリーチ、クロスコネクト、仮想回線、ルーティングポリシー、アクセスルール、監視、サービスデスク手順、インシデント所有権、文書化が含まれる。ハイパースケールプラットフォームはオンランプを公開できる。キャリアはトランスポートを販売できる。データセンタープラットフォームは相互接続を販売できる。顧客のネットワークチームは BGP とセキュリティポリシーを構成できる。InterCloud の主張は、現在 BSO の境界内にあるが、これらの断片を、運用上の断片化が少ない、管理されたサービスに転換できるということである。
受け入れられた接続が実際に要求するもの
具体的な運用シーケンスは、回線が稼働する前から始まる。顧客は、アプリケーション、データフロー、オフィス、データセンター、クラウドリージョン、またはクラウド間のパスにプライベート接続が必要だと判断する。その理由は、レイテンシ、セキュリティ、コンプライアンス、予測可能なルーティング、パブリックインターネットの変動への露出低減、あるいは運用制御である。顧客は次に、そのビジネス要件を、エンドポイント、帯域幅、冗長性、ルート優先度、セキュリティ要件、クラウドプロバイダー、クラウドリージョン、アカウント所有権、VLAN または仮想回線パラメータ、BGP 詳細、変更ウィンドウ、監視の期待値、代替パスといった技術的なリクエストに変換しなければならない。
脆弱な実装では、そのリクエストは一連の分断されたチケットの連鎖になる。エンタープライズチームはキャリア回線を発注し、クラウド管理者にクラウド側リソースの作成を依頼し、セキュリティチームにトラフィックの承認を求め、ネットワークチームにルーティングの設定を依頼し、データセンターまたはクロスコネクトプロバイダーを待つ。各参加者はそれぞれの部分的な真実を持つ。クラウドコンソールには仮想インターフェースが表示され、キャリアは回線完了を示し、エンタープライズルーターにはセッションが存在し、セキュリティチームにはルールがあり、監視チームにはデバイスがある。それだけでは受け入れられた状態を証明しない。
より強固な実装では、プロバイダーが状態コーディネーターとして機能する。プロバイダーは意図された経路、依存関係、証明ポイントを記録する。受け入れられた状態には、物理的または仮想的なアクセスの詳細、クラウドプロバイダーへのハンドオフ、ルーティングアジャセンシー、広報および受信ルート、ポリシー制御、アクセス制御、監視チェック、アラームルーティング、サポート連絡先、変更履歴が含まれるべきである。接続に耐障害性が求められる場合、受け入れられた状態は単に冗長性を主張するのではなく、冗長設計を示すべきである。経路がレイテンシ最適化を目的とするのであれば、選択された経路と、プロバイダーの制御外にある部分を示すべきである。
ここで、InterCloud の過去の Pathway および Autonomi という用語が意味を持つ。公開パートナー資料では、InterCloud Pathway はクラウド接続へのマネージドアプローチ、Autonomi は統合プロバイダーを通じたネットワーク接続のセルフサービスプラットフォームおよび API と説明されていた。この区別は有用である。なぜなら、それが2つの運用モデルに対応するからだ。マネージドモデルでは、顧客は運用負荷を減らして購入し、プロバイダーがより多くの設計、展開、サポート責任を負うことを期待する。セルフサービスモデルでは、顧客はより多くの制御と責任を保持し、プラットフォームを使ってクラウド接続の変更を表現し、繰り返す。
どちらのモデルが自動的に優れているわけではない。小規模なクラウドネットワーキングチームを持つ金融機関は、クリティカルなフローが誤った経路に乗るコストがサービス料金よりも高いため、マネージド設計を評価するかもしれない。洗練されたネットワークエンジニアを擁する大規模プラットフォーム企業は、API、反復可能なプロジェクト、Terraform スタイルの運用規律を望むかもしれない。規制対象のエンタープライズは、データ主権とセキュリティ境界を文書化するためにプロバイダーの支援を必要とするかもしれない。俊敏な SaaS 企業は迅速なプロビジョニングを必要とするが、変更が制御を迂回しなかったという証拠を依然として必要とする。受け入れられた状態は、これらの各バイヤーに、同じ運用能力を持っているかのように装うことなく、対応しなければならない。
最初の商業的リスクは、バイヤーが抽象化に対して支払い、その後、困難な作業が単に移動されただけで、除去されていないことに気づくことである。プライベートクラウド接続は一部の不確実性を低減するが、経路設計、アクセス設計、インシデント対応、クラウド側の権限、アプリケーション依存関係のマッピングを排除するわけではない。顧客チームが、どのアプリケーションフローがその接続に依存しているかを理解していなければ、プロバイダー単独でアプリケーションを耐障害性にすることはできない。顧客が正確なトポロジ記録を維持できなければ、プロバイダーが回線を復旧しても、アプリケーションが壊れたままになるかもしれない。クラウド管理者が仮想ネットワークを変更すれば、ネットワークパスが健全であってもサービスが失敗する。
それゆえ、技術システムは魔法のパイプではなく、共同のコントロールプレーンとして捉えるべきである。それはプロバイダーのネットワークと自動化を、顧客のインベントリ、クラウドアカウント、セキュリティルール、運用手順と結びつける。プロバイダーは、ポータル注文、監視、トラブルチケットルーティング、マネージドサービスデスク機能を提供するかもしれない。クラウドプロバイダーは、Direct Connect、ExpressRoute、Partner Interconnect、FastConnect、あるいは同等のプライベートアクセス構造を提供するかもしれない。キャリアまたはデータセンタープラットフォームは物理パスを提供する。顧客が依然として意図を所有する。受容とは、それらのドメインの整合性である。
経路の真実こそが製品である
クラウド接続プロバイダーはしばしばシンプルさを売りにするが、その基盤となるシステムはルーティングの事実から構築されている。どのプレフィックスが広報されているか？どのパスが受け入れられているか？どのルートが優先されるか？どの障害パスが引き継ぐか？どのトラフィックが意図的に除外されているか？どのルートポリシーがリークを防いでいるか？どのクラウド側構造が接続を終端するか？顧客のどのネットワークセグメントがそれを利用できるか？これらの答えがなければ、サービスは単なる図に過ぎない。
InterCloud の市場は、経路の真実に特に敏感である。なぜなら、マルチクラウドという言葉がまったく異なる設計を隠蔽し得るからだ。ある企業は、異なるアプリケーションに異なるクラウドを使用するかもしれない。単一のワークロードを複数のクラウドにまたがって実行するかもしれない。プライベートデータセンターをパブリッククラウドに接続するかもしれない。クラウドプロバイダー間でデータを移動するかもしれない。ソフトウェア定義エッジを通じて支社をクラウドサービスに接続するかもしれない。これらは同じアーキテクチャではない。それらは異なるルーティング、アイデンティティ、セキュリティ、コスト、障害条件を課す。これらを区別できないプロバイダーは過剰な約束をするだろう。
BSO の公開する Cloud Connect 資料は、主要クラウドプロバイダーへの直接プライベートルート、カスタマイズ可能なルーティング、レイテンシと帯域幅、自社拠点とパートナーデータセンターを通じた可用性を強調している。クラウド間接続の資料は、クラウドプロバイダーまたはリージョン間の直接プライベートパスを強調し、レイテンシ、冗長性、または価値を優先する能力を謳う。これらの主張は、ルートレベルの設計に変換されて初めて商業的に意味を持つ。バイヤーは、どのパスがプライベートか、どのセグメントがパートナー依存か、どのルートが BSO によって制御され、どれがクラウドプロバイダーによって制御され、そして顧客自身のネットワークポリシーがどこから始まるかを問うべきである。
ルートリークは最も明白な障害モードだが、それだけではない。劇的でないルートエラーでも同様に損害を与え得る。ルートが誤った環境に受け入れられるかもしれない。バックアップルートが、顧客が回避したいと考えていた法域をトラフィックが通過する原因になるかもしれない。低レイテンシを意図したパスが、回避可能な地点を経由してヘアピンするかもしれない。ルートフィルターが移行中に新しいサブネットをブロックするかもしれない。クラウド側のルートテーブルは正しく指していても、ファイアウォールルールがトラフィックをドロップするかもしれない。顧客が観測する症状は「クラウドが遅い」や「アプリケーションが落ちている」かもしれないが、運用上の質問は、受け入れられた接続状態がいまだに意図された状態と一致しているかどうかである。
プロバイダーの自動化は、意図を記録し現実と比較すれば役立つ。確認なしに反復的なアクションを放置すれば害になる。高速プロビジョニングは、タスクが反復的で明確に規定されている場合に有用である。すなわち、既知のプロバイダーへの接続追加、容量拡張、ルート優先度の調整、クラウド間パスの作成、または既知のポリシー下での別リージョンのプロビジョニングである。しかし、アプリケーション、データ分類、規制状況、障害耐性が変化しているにもかかわらず、あらゆる新しいアクションが定型業務として扱われるなら危険である。
この理由から、製品の信頼性をソフトウェアの機能と混同すべきではない。ソフトウェア定義インターフェースは、注文、インベントリ、監視を公開できる。変更リクエストを容易に反復可能にできる。電子メールやスプレッドシートよりもクリーンな監査証跡を生成できる。しかし、信頼性の高いクラウド接続には、保守的なデフォルト、ルート検証、アクセスレビュー、ロールバック規律、そして回線とサービス依存関係の両方を見る監視が必要である。バイヤーは自動化を望むべきだが、ネットワークエンジニアリングから切り離された自動化ではない。
BSO による買収は、BSO のより広範なネットワークとサービスデスク機能が接続に関するより完全な証拠を提供するならば、これを強化し得る。製品境界が不明瞭になり、顧客がどのチームがどの状態を所有しているのか判別できなくなれば、弱化し得る。買収後の統合はブランドの演習だけではない。それはサポート状態の演習である。顧客は、InterCloud 起源の接続が BSO のサービスデスクを通じてサポートされるのか、重大度がどのように割り当てられるのか、設計履歴がどこにあるのか、どのポータルが真実のソースを含むのか、変更がどのように承認されるのかを知る必要がある。
アクセスポリシーは静かな障害点である
二つ目のテストはアクセスである。プライベート接続は、通常のパブリックインターネットパスを回避するため、セキュリティ向上として売られることが多い。それは部分的には真実だが、不完全である。プライベートパスでも、誤ったトラフィックを運んだり、誤った環境を露出させたり、顧客が必須と考えていた制御を迂回したりする可能性がある。接続自体がポリシーではない。それは、ポリシーが強制されなければならないトランスポートである。
実務上、アクセスの問題には幾層ものレイヤーがある。顧客はクラウドアカウントやネットワーク変更に対するアイデンティティと承認ルールを持つ。プロバイダーはポータルアカウント、サービスデスク権限、変更手順を持つ。クラウドプロバイダーは独自のリソース権限を持つ。ネットワークはルートフィルター、VLAN 分離、ファイアウォールルール、そして場合によっては暗号化要件を持つ。セキュリティチームはデータ分類、ログ取得、インシデント対応のビューを持つ。クラウド接続プロバイダーは、これらのレイヤーの一貫性維持を支援することで価値を生み出す。
これが、セキュリティ自動化が必要であると同時に危険でもある理由である。反復的な接続タスクに英雄的な手作業を要求すべきではない。類似のクラウド回線を10本開設する顧客が、毎回承認プロセスをゼロから構築し直すべきではない。標準テンプレート、既知のアーキテクチャ、事前合意された制御が摩擦を減らす。しかし、自動化はセキュリティ上の判断を保持しなければならず、単にネットワークのステップを加速するだけではいけない。新しい接続が規制対象データを運ぶ場合、管轄区域の境界を越える場合、またはクラウドワークロードに機密性の高いオンプレミスシステムへのアクセスを許可する場合、汎用テンプレートは緩すぎるかもしれない。
ここで、InterCloud の主権とパフォーマンスに関する従来のポジショニングが重要になる。公開された説明は、企業が重要なデータトラフィックのセキュリティ、主権、パフォーマンスを制御できるようにすることを強調していた。それはこの市場にとって正しい約束だが、証明は具体的でなければならない。トラフィックはどこへ行くのか？どのプロバイダーがそれに触れるのか？どのクラウドリージョンがそれを終端するのか？どのデータセンター拠点が関与するのか？フェイルオーバー時にどのルートが使用されるのか？どのログが経路を示すのか？どの制御が、許可されていない環境が接続を使用するのを阻止するのか？経路とポリシーの証拠を伴わない主権の主張はマーケティングに過ぎない。
データ主権とローカリティは、クラウドアーキテクチャがもはやオンプレミスかパブリッククラウドかの単純な選択ではなくなったため、より複雑化している。ワークロードは、パブリッククラウドリージョン、ソブリンクラウドリージョン、プライベートクラウド、SaaS サービス、管理ネットワークパスを同時に使用する場合がある。例えば、Oracle の公開する FastConnect パートナー資料には、ヨーロッパおよび米国の複数拠点、主権関連のヨーロッパ拠点を含むパートナーとして Intercloud が掲載されている。この種の掲載は可能性のあるリーチの証拠ではあるが、特定の顧客データが望ましい法域に留まっていることの証拠ではない。顧客は依然として設計記録を必要とする。
アクセスポリシーの不一致は、目に見える停止よりも高くつく可能性がある。停止はアラームを引き起こす。不一致は持続するかもしれない。トラフィックが意図しない経路を通って機能するかもしれない。チームが移行中により広範なアクセスを許可し、それを狭めるのを忘れるかもしれない。クラウド管理者が、ネットワークチームに知らせずにサブネットを追加するかもしれない。ファイアウォールオブジェクトが便宜的に再利用されるかもしれない。したがって、受け入れられた状態にはセキュリティビューが含まれるべきである。すなわち、トラフィックが通過できるだけでなく、意図されたトラフィックのみが通過できることを示すことである。
労働力への影響は実在する。適切なプライベートクラウド接続は、ネットワークチームとセキュリティチームの作業内容を変える。彼らは、すべてのクロスコネクトを原理原則から交渉する時間を減らし、意図の維持、例外のレビュー、エスカレーション対応、自動化がリスクのあるパターンを常態化させなかったかのチェックに、より多くの時間を費やすようになる。それは一部の手間を減らすかもしれないが、熟練した監督の必要性を取り除くわけではない。多くの組織では、希少な作業がアーキテクチャと証拠にシフトする。
監視がサービスの管理可能性を決める
三つ目のテストは監視である。プライベート接続は、プロバイダーと顧客が適切な時点で正しい状態を確認できるときに、運用上有用となる。回線が稼働していてもアプリケーションが使用不能である場合がある。ルートが存在していてもレイテンシが許容範囲を超えている場合がある。クラウド側リソースが健全でも、顧客ファイアウォールが経路をドロップしている場合がある。プロバイダーは自社のバックボーンを見ることができても、顧客は失敗したトランザクションしか見えない場合がある。監視はこれらの部分的なビューを橋渡ししなければならない。
BSO の公開資料は、その監視態勢についていくつかの手がかりを提供している。ポータルページには、自動注文、チケット管理、請求と並んで、ネットワーク監視および分析が説明されている。マネージドサービス資料には、インフラ監視、インシデント対応、サービスデスク、プロアクティブ監視が説明されている。過去の公開資料では、マルチキャリアネットワークパフォーマンス監視に関する Accedian とのパートナーシップが説明されており、容量、使用率、レイテンシ、パケットロス、関連指標の可視化が含まれていた。これらのいずれも、今日の特定の InterCloud 顧客接続の振る舞いを証明するものではないが、監視が後付けではなく、公開された運用ナラティブの一部であることを示している。
受け入れられた接続状態には、何が監視され、何が監視されていないかが含まれるべきである。プロバイダーは、ポート、仮想回線、BGP セッション、ルートテーブル、パケットロス、レイテンシ、ジッター、使用率、クラウド側可用性、顧客拠点機器を監視しているのか、それともそれらの一部だけか？アラートは顧客チケットと関連付けられているか？顧客はポータルを通じて可視性を持っているか？警告と重大停止の間に違いはあるか？プロバイダーは、顧客がアプリケーション症状に気づく前に劣化した経路を検出するか？これらの質問は、一般的な可用性表明よりも重要である。
モニタリングの死角は、特にハンドオフポイントでよく見られる。キャリアはクリーンなトランスポートセグメントを見ているかもしれない。クラウドプロバイダーは利用可能なオンランプを見ているかもしれない。マネージドプロバイダーは自社のバックボーンを見ているかもしれない。顧客はアプリケーションのタイムアウトを見ているのかもしれない。マルチパーティシステムでは、各当事者が技術的には正しくても、運用上は不完全であり得る。マネージドクラウド接続プロバイダーの価値の一部は、その診断ギャップを縮小する能力にある。
バイヤーは、監視をダッシュボードの見た目に矮小化するプロバイダーに懐疑的であるべきだ。ダッシュボードは運用モデルではない。難しい質問は、ダッシュボードとユーザーエクスペリエンスが一致しないときに何が起こるかである。誰が最初のアクションを取るのか？誰が責任追及を避けるために十分な証拠を見ることができるのか？誰がクラウドプロバイダーやキャリアに連絡するのか？誰が経路変更、ロールバック、またはエスカレーションの権限を持つのか？誰が、劣化したリンクが単なるバックグラウンドメトリックではなく、ビジネスインシデントであると判断するのか？
インシデントリカバリは、受け入れられた状態がストレス下でテストされる瞬間である。ルートがリークし、クラウドオンランプが故障し、キャリアセグメントが劣化し、セキュリティルールが新しいプレフィックスをブロックし、あるいは計画された変更が予期しないレイテンシ経路を生み出すかもしれない。顧客は修正だけを必要としているのではない。プロバイダーが、何が変わり、何が故障し、どのような回避策が適用され、どの状態が今や受け入れられたと見なされるべきかを再構築できるかどうかを知る必要がある。その記録がなければ、同じインシデントが再発し得る。
BSO の公開連絡資料は、ポータル顧客に対して、緊急事態や重大な停止の際には優先度「高」または「非常に高」でサービスデスクチケットを開くよう指示している。これは、期待されるエスカレーションチャネルを明らかにするため、有用なシグナルである。しかし、チケットチャネルは正面玄関に過ぎない。運用品質は、分類、所有権、証拠収集、コミュニケーション頻度、復旧権限に依存する。主要なクラウド接続プロバイダーは、チケットを受け取れるかどうかではなく、クロスドメインのインシデントを検証された状態へと導けるかどうかで評価されるべきである。
展開条件が約束の成否を決める
クラウド接続は、どこでも同じように容易なわけではない。展開条件が重要である。既に BSO の POP、パートナーデータセンター、またはクロスコネクトアクセスが容易な場所にいる顧客は、サイトがオフネットでローカルキャリアに依存している顧客とは立場が異なる。サポートが充実したクラウドリージョンに接続する顧客は、パートナーオプションが少ないリージョンを対象とする顧客とは異なる。整然とした IP アドレッシング、文書化されたトポロジ、規律あるクラウドアカウントを持つ顧客は、ネットワークが断片化し、管理されていない例外がある顧客よりもサービスが容易である。
BSO の Cloud Connect 資料では、ネットワークが到達している場所、またはパートナーデータセンターを通じてアクセスを提供できるとし、オフネットの顧客にはクラウドへの設計された経路が必要であると述べている。この一文に商業的真実の多くが込められている。「利用可能」は「単純」と同じではない。オフネットの場合、プロバイダーはサードパーティのローカルアクセスを必要とするかもしれない。冗長性が要求される場合、設計には物理的および論理的に分離されたパスが必要になるかもしれない。クラウドプロバイダーのオンランプが顧客の希望する市場にない場合、経路に地域的な妥協が生じるかもしれない。レイテンシがサービス購入の理由であるなら、顧客はプロバイダーの名目上の名前ではなく、実際の経路を気にしなければならない。
これはクラウド間接続にも同様に当てはまる。プライベートパスを通じてクラウドプロバイダー間でデータを移動することは、一部のパブリックインターネットの不確実性を回避し、一部のトラフィックコストを削減できるかもしれないが、新たな依存レイヤーを生み出す。顧客は、クラウドイグレスポリシー、プロバイダーのポート料金、マネージド接続料金、帯域幅コミットメント、ルート設計、運用サポートを理解しなければならない。アプリケーションがクロスクラウドレイテンシや障害セマンティクスに耐えられるように構築されていなければ、優れたプライベートパスがアーキテクチャを単純化することはない。
したがって、単位経済性は束として分析すべきである。明白なコストはマネージド接続サービス料金である。あまり明白でないコストには、移行計画、変更ウィンドウ、クラウドプロバイダー料金、データ転送料金、ハードウェアまたはポートコミットメント、セキュリティレビュー、監視統合、スタッフトレーニング、継続的な監督が含まれる。便益側には、ネットワークの複雑性低減、より予測可能なパフォーマンス、プライベートルーティング、迅速な反復プロビジョニング、一回限りのキャリアプロジェクトの減少、より良好なインシデント対応面が含まれる。この取引は、回避される複雑性が現実のものである場合にのみ魅力的となる。
これはミッドマーケットのバイヤーにとって高いハードルである。単一のクラウドを使用し、ほとんどがインターネット向けアプリケーションである小規模企業は、マネージドプライベートクラウド接続プロバイダーを必要としないかもしれない。複数リージョン、規制対象データ、レイテンシに敏感なプロセス、プライベートアプリケーション、支社ネットワーク、またはクラウド変更作業を繰り返す企業は、より強い必要性があるかもしれない。商業的な問いは、プライベートクラウド接続が良いかどうかではない。顧客のワークロードと運用モデルが十分に複雑で、サービスが継続的な分断よりも安価になるかどうかである。
InterCloud の既存顧客は、BSO 内で移行またはサポートされる場合、特別な展開問題に直面する。彼らは継続性を必要とするが、同時に明確さも必要とする。どの製品名が引き続き有効か？どのサービスレベルが適用されるか？どのポータルを使用すべきか？どのサポート番号やチケットカテゴリーが重要か？BSO のどの機能が現在利用可能で、どれが契約変更を必要とするか？買収発表は、InterCloud 顧客へのサービス継続性を強調した。その約束の運用バージョンは感情ではなく、文書化である。
上流の依存関係スタックはブランドよりも大きい
クラウド接続プロバイダーは、自社が販売するサービスを完全に制御しているわけではない。経路の一部を制御し、他の部分は契約し、残りの部分を調整する。InterCloud および BSO は、オンランプやクラウド側構造をクラウドプロバイダーに依存している。物理的相互接続をデータセンターに依存している。オフネットリーチや一部の長距離経路をキャリアに依存している。ルーティング機器、監視システム、サポートツール、アイデンティティシステム、顧客記録に依存している。顧客は、請求書に一社のサプライヤーが表示されていようと多数であろうと、これらすべてに依存している。
この依存関係スタックは、それ自体が弱点なのではない。それが市場の性質である。AWS Direct Connect、Azure ExpressRoute、Google Partner Interconnect、Oracle FastConnect はいずれも、顧客環境とクラウドリソース間のプライベートまたはパートナー媒介接続という同じ基本概念を形式化している。クラウドプロバイダーがクラウド側サービスを提供する。パートナーとキャリアがリーチを拡張する。ネットワークプラットフォームとマネージドプロバイダーが結果をパッケージ化する。バイヤーは、その統合をどの程度自ら行うかを選択する。
リスクは、パッケージ化が障害の所有権を不明瞭にすることである。ルート問題は顧客のルーター内部にあるかもしれない。物理的問題はクロスコネクトにあるかもしれない。仮想回線の問題はクラウドプロバイダーにあるかもしれない。レイテンシの予想外は、マネージドプロバイダーの直接制御外のルート選択に起因するかもしれない。ファイアウォールの不一致は、顧客のセキュリティチームの所有かもしれない。ポータルエラーはサービスプロバイダーの所有かもしれない。すべてが単一のクラウド接続として販売されている場合でも、インシデントプロセスはこれらの区別を保持しなければならない。
それゆえ、プロバイダーの証拠規律が重要になる。成熟したプロバイダーは、「このセグメントは当社が管理し、このセグメントはパートナーが管理し、このセグメントは顧客が管理し、これが現時点の証明である」と言えなければならない。それは、顧客が停止時にフォレンジックコーディネーターになることを要求すべきではない。また、単一のプロバイダーがマルチパーティ経路の全レイヤーを保証できることを示唆すべきでもない。
BSO のより大規模なネットワークは、より多くのリーチと運用能力を同一組織内にもたらすことで、一部の依存関係リスクを低減するかもしれない。また、顧客がルート知識を保持せずに、あまりにも多くの接続決定を単一サプライヤーに移行すると、集中リスクを生み出すかもしれない。最良のバイヤー姿勢は、盲目的な信頼でも、永続的な自前主義の懐疑論でもない。それは構造化された依存関係管理である。すなわち、何がアウトソースされ、何が所有し続けるべきかを知り、各受領ポイントで証拠を要求することである。
競合と代替品が商業的上限を規定する
InterCloud は、同じ語彙を使う企業とのみ競合するわけではない。代替品の集合は広範である。大企業は、クラウドプロバイダーやキャリアから直接購入し、社内エンジニアを使ってサービスを組み立てることができる。Equinix Fabric やデータセンター相互接続プラットフォームを使用できる。Megaport や Console Connect を使ってネットワークアズアサービス型のプロビジョニングができる。グローバルテレコムプロバイダー、SD-WAN ベンダー、マネージドサービスプロバイダー、クラウドシステムインテグレーターを利用できる。また、パブリックインターネットに暗号化とアプリケーションレイヤーの耐障害性を加えれば十分と判断することもできる。
この代替品集合が価格決定力を制限し、製品を形成する。InterCloud および BSO は、時間、地理的リーチ、専門スキルが不足している顧客にとって、内製組み立てよりも優れていなければならない。また、管理責任を求める顧客に対しては、純粋なセルフサービスプラットフォームよりもガイドが充実していなければならない。クラウド変更を繰り返す顧客に対しては、従来のキャリアプロジェクトよりも柔軟でなければならない。運用可能な接続を必要とし、アドバイスだけを求めない顧客に対しては、一般的なクラウドコンサルティングよりも具体的でなければならない。
最も強い商業的ケースは、反復的タスクを持つ顧客である。一度限りのプライベート接続は多くのプロバイダーが対応できる。価値が高まるのは、顧客がクラウドリージョンを繰り返し追加し、容量を調整し、新しいサイトを接続し、ルートポリシーを変更し、移行を実行し、インシデントフェイルオーバーを管理し、または事業部門全体で一貫した証拠を必要とする場合である。その世界では、プラットフォームとマネージドサービスが、一連の特注プロジェクトを制御された運用パターンに変えることができる。
最も弱いケースは、顧客側の所有権が不明確であることを、プロバイダーに補償させようとする顧客である。アプリケーションチーム、クラウドチーム、ネットワークチーム、セキュリティチームが意図について合意できない場合、外部プロバイダーは回線をプロビジョニングできても、ビジネス上の正しさを定義することはできない。それは、組織のあいまいさに起因する障害の責めを負わされる目に見える当事者になるかもしれない。それが監督コストを引き上げ、単位経済性を弱める。
ここで、組織と労働力への影響を真剣に考慮すべきである。成功するマネージドクラウド接続の展開は、価値の低い調整作業を縮小できる。手動でのキャリアとのやり取りの数を減らせる。記録を標準化できる。クラウドチームに、承認された接続へのより速いパスを提供できる。セキュリティチームに、より明確なレビュー面を提供できる。しかし、それには接続意図の指名オーナーも必要とする。顧客組織内の誰かが、「受け入れられ」の意味を決定しなければならない。
誰もその状態を所有しなければ、あらゆるプロバイダーの約束が脆弱になる。ネットワークチームは到達可能性のために最適化するかもしれない。セキュリティチームは制限のために最適化するかもしれない。クラウドチームは速度のために最適化するかもしれない。財務部門は低い経常課金のために最適化するかもしれない。アプリケーション所有者はユーザーエクスペリエンスのために最適化するかもしれない。プロバイダーは、混合された要件を満たさなければならない。バイヤーのガバナンスが優れているほど、プロバイダーの自動化の価値は高まる。
顧客の証拠は存在するが完全ではない
InterCloud と BSO に関する公開市場の証拠は有用だが、限界がある。BSO は、マネージドネットワーク、クラウドインフラ、接続の隣接分野で顧客参照やケーススタディ資料を公開している。同社サイトでは、サポート、テクノロジー、クラウド間のページに顧客名や引用が表示されている。Equinix は InterCloud をリセラーパートナーとして掲載し、InterCloud のマネージドおよびセルフサービスのクラウド接続製品を説明している。Oracle は、FastConnect パートナーとして地域別に Intercloud を掲載している。LinkedIn や市場データベースには、InterCloud のソフトウェア定義クラウド相互接続プロバイダーとしての来歴が保存されている。フランスの企業情報ソースには、InterCloud の法人アイデンティティと法的提出履歴が記録されている。フランスのテクノロジーメディアは BSO の買収と司法再編の背景を報じた。
これらは、カテゴリーと運用境界を確立するには十分である。しかし、顧客固有のパフォーマンスを確立するには不十分である。InterCloud の現在の平均修理時間、実際の顧客ルート安定性、停止履歴、解約率、収益、価格設定、サービスレベル達成度、買収後統合の品質を示す公開証拠パックは存在しない。これらの事実は非公開で存在するかもしれないが、公開資料から推測すべきではない。
このことは重要である。なぜなら、クラウド接続市場には、方向性としてはもっともらしいが、運用上は具体性を欠く主張が溢れているからだ。「セキュア」は、プライベートトランスポート、暗号化、ポリシー制御、監視、またはそれらすべてを意味し得る。「低レイテンシ」は、ルートオプション、測定結果、またはパブリックインターネットパスと比較した相対的改善を意味し得る。「グローバル」は、自社ネットワーク、パートナーリーチ、クラウドオンランプのカバレッジ、または商業的利用可能性を意味し得る。「マネージド」は、設計支援、24時間サポート、アクティブ監視、または単なるチケットパスを意味し得る。本気のバイヤーは定義を求める。
BSO の買収発表は、InterCloud をパブリックおよびプライベートクラウド環境向けの直接接続サービスにおけるキープレイヤーと位置づけ、この取引が InterCloud 顧客への中断なきサービスを保証しつつ、テクノロジーを BSO に統合すると述べた。この声明は商業的に重要だが、依然として公開買収ナラティブである。バイヤーの次の質問は運用に関するものであるべきだ。すなわち、現在のサービスカタログ、サポートモデル、ポータルの挙動、エスカレーションフロー、技術的受け入れ基準を示せ、と。
最も強力な証拠は、往々にして平凡である。プロバイダーは、機微な詳細を除いた受入記録の例を示せるか？経路変更がどのように要求され、承認され、実装され、テストされ、ロールバックされるかを示せるか？監視がチケットの重大度にどのようにマッピングされるかを示せるか？クラウドプロバイダーにオンランプの問題が発生した場合に何が起こるかを示せるか？顧客インベントリがどのように最新に保たれるかを示せるか？これらは華やかな質問ではない。それらは、マネージド接続サービスと、高価なだけのパイプを区別する質問である。
障害モードは予測可能である
既知の障害モードは珍しいものではない。第一は、ルートリークまたはルートポリシーのミスである。これは古典的なネットワーク障害である。トラフィックを誤った経路にさらしたり、到達可能性を不安定にしたりするからである。良好な制御には、プレフィックスフィルタリング、変更レビュー、段階的ロールアウト、ルート監視、ロールバック手順が含まれる。
第二は、アクセスポリシーの不一致である。接続は機能するが、誤った送信元、宛先、サブネットが許可される。あるいは、セキュリティ制御が更新されなかったために、意図されたフローがブロックされる。良好な制御には、接続作業をセキュリティ承認に結びつける変更記録、ならびにネットワーク側とアプリケーション側の両方からの変更後検証が含まれる。
第三は、レイテンシの予想外である。バイヤーはより高速または予測可能なパスを期待したが、実装されたルート、フェイルオーバーパス、クラウド側依存関係が異なる挙動を示す。良好な制御には、パス文書化、ベースライン測定、現実的なパフォーマンスに関する表現、およびどのセグメントがプロバイダーの直接制御外かについての明確化が含まれる。
第四は、クラウドオンランプの停止または劣化である。プライベートパスは依然として、クラウドプロバイダーのロケーションやパートナーハンドオフに依存している場合がある。良好な制御には、冗長設計、クラウドリージョン認識、エスカレーション連絡先、および文書化されたフェイルオーバー選択肢が含まれる。
第五は、監視の死角である。プロバイダーは自社の回線を健全と見なしているが、顧客はアプリケーション障害を経験する。良好な制御には、共有メトリクス、必要に応じた合成チェック、ルートとセッションの可視性、およびプロバイダー境界で停止しないインシデント手順が含まれる。
第六は、キャリアハンドオフ障害である。オフネットアクセスとパートナーパスは、遅延と曖昧さを持ち込む可能性がある。良好な制御には、明示された依存関係、物理的冗長性記録、キャリアエスカレーション手順、ラストマイル障害の明確な所有権が含まれる。
第七は、買収後の製品境界の混乱である。顧客は、従来の InterCloud サービス、BSO ブランドのサービス、またはハイブリッドサポートモデルのいずれを使用しているのか分からないかもしれない。良好な制御には、サービスマッピング、契約の明確性、サポート移行通知、および最新の運用文書が含まれる。
第八は、インシデントエスカレーションの遅延である。適切なチームが適切な証拠を十分迅速に受け取れない。良好な制御には、重大度の定義、ポータル規律、連絡経路、事前合意された緊急手順が含まれる。
これらの障害のいずれも、InterCloud や BSO の提案を無効にするものではない。それらは作業を定義する。このカテゴリーの企業は、これらの障害の可能性を低くし、より可視化し、より迅速に解決できるようになったときに成功する。それらを例外的なケースとして扱うときに失敗する。
実践的バイヤーテスト
実践的なバイヤーは、BSO を通じた InterCloud を、簡潔で要求水準の高い受入チェックリストで評価すべきである。第一に、サービス境界を特定する。どの法人がサービスを契約するのか？どの製品が販売されているのか？どの部分が InterCloud の遺産に由来し、どの部分が BSO のネットワークまたはマネージドサービスに由来するのか？第二に、経路を特定する。どのサイト、データセンター、クラウドリージョン、オンランプが関与しているのか？どのセグメントがオンネットで、どれがパートナー依存で、どれが顧客管理か？第三に、ポリシーを特定する。どのルート、プレフィックス、アクセスルール、セキュリティ制御がサービスを定義するのか？
第四に、運用面を特定する。注文、監視、チケットにどのポータルが使われるのか？どのイベントがアラートを生成するのか？どの重大度レベルが適用されるのか？どのサポートチームが初動対応を所有するのか？第五に、証拠を特定する。接続が受け入れられた際に、どのような証明が生成されるのか？変更後にどのような証明が生成されるのか？インシデント中にどのような証明が利用可能か？第六に、経済性を特定する。経常サービス料金、クラウドプロバイダー料金、データ転送の前提、移行コスト、スタッフ監督コストは何か？第七に、出口計画を特定する。サービスが期待外れだった場合、設計は他のプロバイダーまたは直接クラウド接続にどの程度移植可能か？
このチェックリストは重く聞こえるかもしれないが、停止中に曖昧さを発見するよりも安価である。また、このカテゴリーを尊重している。マネージドクラウド接続は、基盤となるシステムが困難であるからこそ価値がある。それを単純なものとして扱うことは、購入する理由を台無しにする。
InterCloud にとって、機会は依然として現実である。エンタープライズの分散化は弱まっていない。クラウドリージョン、ソブリンクラウドの提供、プライベートアプリケーション、SaaS 依存、データ集約型ワークロードは増え続けている。パブリックインターネットは、ビジネスクリティカルなトラフィックにとって常に適切な基盤とは限らない。内部チームはしばしば過負荷である。プライベートリーチ、クラウドプロバイダーハンドオフ、運用証拠、サービスデスク規律を組み合わせることができるプロバイダーは、価値を創造できる。
リスクも同様に現実である。マルチクラウドの言葉は膨張している。顧客は、クラウドの抽象化がコストを除去するのではなく、しばしば隠蔽することを学んだ。クラウドプロバイダーの直接サービスは改善している。相互接続プラットフォームは成熟している。ネットワークアズアサービスの競合が目に見えている。バイヤーは信頼できる代替案を組み立てることができる。したがって、BSO 内の InterCloud は、語彙ではなく実行で勝たなければならない。
決定的な問いは単純である。変更後またはインシデント後に、プロバイダーは受け入れられた状態を証明できるか？それができるなら、サービスは単なる接続性ではない。それは、エンタープライズネットワークとクラウドプラットフォームの間の困難な境界に対する運用制御である。それができなければ、バイヤーは同じ古い不確実性の上に、もう一つの管理レイヤーを重ねただけに終わる。
これが、今や InterCloud に対する適切な基準である。会社がクラウド相互接続と言えるかどうかではない。BSO が広範なネットワークを持っているかどうかではない。ポータルが注文を発行できるかどうかではない。基準は、顧客の意図したクラウド接続が、通常の変更圧力下および停止圧力下で、繰り返し、検証され、監視され、サポート可能で、経済的に防御可能な状態になるかどうかである。それ以外はすべて、経路のパンフレット版に過ぎない。