InterClouds eigentlicher Test ist die akzeptierte Cloud-Verbindung

Zusammenfassung

• InterCloud sollte nach dem akzeptierten Cloud-Verbindungszustand beurteilt werden: dem Punkt, an dem Kundenabsicht, privater Transport, Routing-Richtlinie, Cloud-Provider-Übergabe, Sicherheitskontrollen, Überwachung und Support-Nachweise alle denselben funktionierenden Dienst beschreiben.
• Die Übernahme durch BSO verleiht der alten Betriebsfläche von InterCloud einen größeren Netzwerk- und Service-Desk-Kontext, macht aber auch Disziplin an den Grenzen unerlässlich: Käufer müssen wissen, welches Versprechen aus dem Cloud-Interconnect-Erbe von InterCloud stammt, welches aus dem Netzwerk von BSO und welches weiterhin von Cloud-Anbietern, Carriern und Kundenteams abhängt.

Das Unternehmen ist zu einem Grenzproblem geworden

InterCloud wird am leichtesten missverstanden, wenn es abstrakt als kleines Cloud-Unternehmen behandelt wird. Die nützlichere Sichtweise ist enger und anspruchsvoller. Es befindet sich im Raum zwischen Unternehmensnetzwerken und öffentlichen Cloud-Plattformen. Die frühere öffentliche Positionierung war softwaredefinierte Cloud-Interconnection: eine verwaltete Möglichkeit, Firmenstandorte, Rechenzentren und Cloud-Dienste zu verbinden, ohne dass jedes Kundenteam Leitungen, Routing, Sicherheitskontrollen und Betriebsverfahren von Grund auf zusammenstellen muss.

Die heutige öffentliche Oberfläche ist nun mit BSO verbunden, das im März 2025 bekannt gab, InterCloud nach Genehmigung durch das Handelsgericht Paris im Rahmen eines gerichtlichen Sanierungsverfahrens übernommen zu haben. Die eigene Domain von InterCloud leitet jetzt auf die öffentliche Website von BSO weiter. Das ist kein kosmetisches Detail. Es ändert, wie das Unternehmen gelesen werden muss.

Der Käufer kauft nicht einfach „Cloud“. Der Käufer kauft einen verwalteten Pfad in Cloud-Dienste. Dieser Pfad ist ein zusammengesetztes Objekt. Er umfasst physische Reichweite, Partnerreichweite, Cross-Connects, virtuelle Leitungen, Routing-Richtlinien, Zugriffsregeln, Überwachung, Service-Desk-Verfahren, Störungseigentümerschaft und Dokumentation. Eine Hyperscale-Plattform kann eine On-Ramp bereitstellen. Ein Carrier kann Transport verkaufen. Eine Rechenzentrumsplattform kann Interconnection verkaufen. Das Netzwerkteam eines Kunden kann BGP und Sicherheitsrichtlinien konfigurieren.

Der Anspruch von InterCloud, nun innerhalb des BSO-Perimeters, besteht darin, dass diese Einzelteile in einen kontrollierten Dienst mit weniger betrieblicher Fragmentierung verwandelt werden können.

Deshalb ist der akzeptierte Cloud-Verbindungszustand die richtige Linse. Der Ausdruck klingt verfahrenstechnisch, aber darin steckt die Wirtschaftlichkeit. Eine Verbindung ist nicht akzeptiert, nur weil ein Port existiert. Sie ist nicht akzeptiert, weil ein Portal meldet, dass die Bestellung abgeschlossen ist. Sie ist nicht akzeptiert, weil ein Verkaufsdiagramm eine Linie zwischen einem Kundennetzwerk und einem Cloud-Anbieter zeigt.

Sie ist akzeptiert, wenn der Kunde nachweisen kann, dass die Route die beabsichtigte Route ist, die Zugriffsrichtlinie die beabsichtigte Richtlinie ist, die Cloud-Seite die Anbindung erkennt, die Überwachungsoberfläche die richtigen Fehlermodi erkennt und der Eskalationspfad klar ist, wenn etwas abweicht.

Dies ist ein strengerer Test, als es eine Produktbroschüre tragen kann. Er trennt Netzwerkfähigkeit von Cloud-Ambition. Er trennt auch eine Automatisierungsgeschichte von einer Zuverlässigkeitsgeschichte. Ein Portal oder eine API kann die Zeit verkürzen, die benötigt wird, um einen Dienst anzufordern. Es kann eine wiederholte Änderung leichter ausdrückbar machen. Es kann manuellen Ticketverkehr reduzieren. Aber der Dienst ist nur dann zuverlässig, wenn die automatisierte Aktion mit genügend Nachweisen eintrifft, damit ein menschlicher Bediener, ein Sicherheitseigentümer und ein Geschäftseigentümer dem resultierenden Zustand vertrauen können.

Der BSO-Kontext ist wichtig, weil BSOs öffentliches Material ein breiteres globales Konnektivitäts- und Infrastrukturunternehmen beschreibt: private Cloud-Konnektivität, Cloud-zu-Cloud-Verbindungen, Managed Services, Service-Desk, Netzwerküberwachung, Rechenzentrumsabdeckung und ein Portal für Bestellungen und Ticketbearbeitung. Das Kartenmaterial des Netzwerks gibt an, eine Präsenz in mehr als 240 Rechenzentren in 33 Ländern, mehr als 50 Cloud-On-Ramps, bedeutende Cloud-Anbieter-Integration, Internet-Exchange-Erreichbarkeit und Börsenkonnektivität zu haben.

Dies sind Behauptungen von BSO und keine unabhängigen Leistungsmessungen, aber sie definieren den Maßstab des aktuellen Betriebsrahmens. Die alte Punktlösung von InterCloud muss nun vor diesem Rahmen verstanden werden.

Die rechtliche und markentechnische Grenze ist daher keine Fußnote. InterCloud hatte seine eigene öffentliche Geschichte, Produkte und Partnerlisten. BSO präsentiert die Übernahme nun als Kontinuitäts- und Expansionsschritt. Ein Kunde sollte nicht jede BSO-Netzwerkbehauptung als eine InterCloud-Produktbehauptung lesen und nicht jede alte InterCloud-Produktformulierung als aktuellen eigenständigen Dienst. Die sichere Lesart ist, dass das Cloud-Konnektivitätserbe von InterCloud in das größere Dienstleistungsportfolio von BSO aufgenommen wurde.

Die kommerzielle Frage ist, ob diese Kombination die Komplexität ausreichend reduziert, um die Gebühren für Managed Services, Migrationsaufwand und fortlaufende Überwachung zu rechtfertigen.

Was eine akzeptierte Verbindung tatsächlich erfordert

Die konkrete Betriebssequenz beginnt, bevor eine Leitung in Betrieb ist. Ein Kunde entscheidet, dass eine Anwendung, ein Datenfluss, ein Büro, ein Rechenzentrum, eine Cloud-Region oder ein Cloud-zu-Cloud-Pfad private Konnektivität benötigt. Der Grund kann Latenz, Sicherheit, Compliance, vorhersagbares Routing, geringere Exposition gegenüber der Variabilität des öffentlichen Internets oder betriebliche Kontrolle sein.

Der Kunde muss dann diesen geschäftlichen Grund in eine technische Anforderung übersetzen: Endpunkte, Bandbreite, Diversität, Routenpräferenz, Sicherheitsanforderung, Cloud-Anbieter, Cloud-Region, Kontobesitz, VLAN- oder virtuelle Leitungsparameter, BGP-Details, Änderungsfenster, Überwachungserwartung und Ausweichpfad.

In einer schwachen Implementierung wird diese Anforderung zu einer Kette unzusammenhängender Tickets. Das Unternehmensteam eröffnet einen Carrier-Auftrag, bittet einen Cloud-Administrator, eine Cloud-seitige Ressource zu erstellen, bittet ein Sicherheitsteam, Traffic zu genehmigen, bittet ein Netzwerkteam, Routing zu konfigurieren, und wartet auf einen Rechenzentrums- oder Cross-Connect-Anbieter. Jeder Teilnehmer hat eine lokale Wahrheit. Die Cloud-Konsole zeigt möglicherweise eine virtuelle Schnittstelle. Der Carrier zeigt möglicherweise eine fertiggestellte Leitung. Der Unternehmensrouter hat möglicherweise eine Sitzung.

Das Sicherheitsteam hat möglicherweise eine Regel. Das Überwachungsteam hat möglicherweise ein Gerät. Nichts davon beweist allein den akzeptierten Zustand.

In einer stärkeren Implementierung fungiert der Anbieter als Zustandskoordinator. Er zeichnet den beabsichtigten Pfad, die Abhängigkeiten und die Nachweispunkte auf. Der akzeptierte Zustand sollte die physischen oder virtuellen Zugangsdetails, die Cloud-Anbieter-Übergabe, die Routing-Nachbarschaft, angekündigte und empfangene Routen, Richtlinienkontrollen, Zugriffskontrollen, Überwachungsprüfungen, Alarmweiterleitung, Supportkontakt und Änderungshistorie umfassen. Wenn die Verbindung ausfallsicher sein soll, sollte der akzeptierte Zustand das redundante Design zeigen, anstatt nur Widerstandsfähigkeit zu behaupten.

Wenn die Route zur Latenzoptimierung dienen soll, sollte der akzeptierte Zustand zeigen, welcher Pfad ausgewählt wurde und was außerhalb der Kontrolle des Anbieters bleibt.

Hier ist die alte Sprache von InterCloud zu Pathway und Autonomi relevant. Öffentliches Partnermaterial beschrieb InterCloud Pathway als einen verwalteten Ansatz für Cloud-Konnektivität und Autonomi als Self-Service-Plattform und API für Netzwerkkonnektivität über integrierte Anbieter. Diese Unterscheidung ist nützlich, da sie zwei Betriebsmodelle abbildet. Im verwalteten Modell kauft der Kunde weniger betrieblichen Aufwand und erwartet, dass der Anbieter mehr Design-, Bereitstellungs- und Supportverantwortung trägt.

Im Self-Service-Modell behält der Kunde mehr Kontrolle und mehr Verantwortung und nutzt eine Plattform, um Cloud-Konnektivitätsänderungen auszudrücken und zu wiederholen.

Keines der beiden Modelle ist automatisch besser. Ein Finanzinstitut mit einem kleinen Cloud-Networking-Team mag ein verwaltetes Design schätzen, da die Kosten eines falsch gerouteten kritischen Flusses höher sind als die Servicegebühr. Ein großes Plattformunternehmen mit erfahrenen Netzwerktechnikern möchte möglicherweise APIs, wiederholbare Projekte und eine Terraform-ähnliche Betriebsdisziplin. Ein reguliertes Unternehmen benötigt möglicherweise einen Anbieter, der hilft, Souveränitäts- und Sicherheitsgrenzen zu dokumentieren.

Ein schnelllebiges SaaS-Unternehmen benötigt möglicherweise schnelle Bereitstellung, erfordert aber dennoch den Nachweis, dass eine Änderung keine Kontrolle umgangen hat. Der akzeptierte Zustand muss jedem dieser Käufer dienen, ohne vorzutäuschen, dass sie die gleiche Betriebsfähigkeit haben.

Das erste kommerzielle Risiko besteht darin, dass der Käufer für Abstraktion zahlt und dann feststellt, dass die harte Arbeit nur verlagert, nicht beseitigt wurde. Private Cloud-Konnektivität reduziert einige Unsicherheiten, beseitigt aber nicht Routendesign, Zugriffsdesign, Incident Response, Cloud-seitige Berechtigungen oder die Abbildung von Anwendungsabhängigkeiten. Wenn das Kundenteam nicht versteht, welche Anwendungsflüsse von der Verbindung abhängen, kann der Anbieter die Anwendung nicht von allein widerstandsfähig machen.

Wenn der Kunde keine genauen Topologieaufzeichnungen führen kann, kann der Anbieter die Leitung wiederherstellen und die Anwendung bleibt dennoch gestört. Wenn der Cloud-Administrator ein virtuelles Netzwerk ändert, kann der Netzwerkpfad gesund sein, während der Dienst ausfällt.

Deshalb sollte das technische System als gemeinsame Steuerungsebene betrachtet werden, nicht als magische Leitung. Es verbindet das Netzwerk und die Automatisierung des Anbieters mit dem Inventar, den Cloud-Konten, den Sicherheitsregeln und den Betriebsgewohnheiten des Kunden. Der Anbieter kann Portalbestellungen, Überwachung, Ticket-Routing und verwaltete Service-Desk-Funktionen anbieten. Der Cloud-Anbieter kann Direct Connect, ExpressRoute, Partner Interconnect, FastConnect oder gleichwertige private Zugriffskonstrukte bereitstellen. Der Carrier oder die Rechenzentrumsplattform liefert den physischen Pfad.

Der Kunde besitzt weiterhin die Absicht. Akzeptanz ist die Ausrichtung dieser Domänen.

Die Wahrheit der Route ist das Produkt

Cloud-Konnektivitätsanbieter verkaufen oft Einfachheit, aber das zugrunde liegende System besteht aus Routing-Fakten. Welche Präfixe werden angekündigt? Welche Pfade werden akzeptiert? Welche Route wird bevorzugt? Welcher Ausweichpfad übernimmt? Welcher Traffic wird absichtlich ausgeschlossen? Welche Routenrichtlinie verhindert ein Leck? Welches Cloud-seitige Konstrukt terminiert die Verbindung? Welches Kundennetzsegment darf es nutzen? Ohne diese Antworten ist der Dienst ein Diagramm.

Der Markt von InterCloud ist besonders empfindlich gegenüber der Routenwahrheit, da die Multi-Cloud-Sprache sehr unterschiedliche Designs verbergen kann. Ein Unternehmen kann separate Clouds für separate Anwendungen nutzen. Es kann eine einzige Arbeitslast über mehr als eine Cloud betreiben. Es kann ein privates Rechenzentrum mit einer öffentlichen Cloud verbinden. Es kann Daten zwischen Cloud-Anbietern verschieben. Es kann Niederlassungen über einen softwaredefinierten Edge in Cloud-Dienste einbinden. Dies sind nicht dieselben Architekturen.

Sie stellen unterschiedliche Anforderungen an Routing, Identität, Sicherheit, Kosten und Ausfallbedingungen. Ein Anbieter, der sie nicht unterscheiden kann, wird übermäßige Versprechungen machen.

BSOs öffentliches Cloud Connect-Material betont direkte private Routen zu großen Cloud-Anbietern, anpassbares Routing, Latenz und Bandbreite sowie Verfügbarkeit durch eigene Points of Presence und Partner-Rechenzentren. Das Cloud-zu-Cloud-Material betont direkte private Pfade zwischen Cloud-Anbietern oder Regionen mit der Möglichkeit, Latenz, Diversität oder Wert zu priorisieren. Diese Behauptungen sind kommerziell nur dann bedeutsam, wenn sie in ein Routen-Design auf Ebene übersetzt werden.

Ein Käufer sollte fragen, welcher Pfad privat ist, welches Segment von Partnern abhängt, welche Routen von BSO kontrolliert werden, welche vom Cloud-Anbieter kontrolliert werden und wo die eigene Netzwerkrichtlinie des Kunden beginnt.

Routenlecks sind der offensichtlichste Fehlermodus, aber nicht der einzige. Ein weniger dramatischer Routenfehler kann ebenso schädlich sein. Eine Route könnte von der falschen Umgebung akzeptiert werden. Eine Sicherungsroute könnte Traffic durch eine Jurisdiktion leiten, die der Kunde vermeiden wollte. Ein für niedrige Latenz vorgesehener Pfad könnte über einen vermeidbaren Standort haarnadelförmig verlaufen. Ein Routenfilter könnte ein neues Subnetz während einer Migration blockieren. Eine Cloud-seitige Routentabelle könnte korrekt zeigen, während eine Firewall-Regel Traffic verwirft.

Das beobachtbare Symptom des Kunden könnte „Cloud ist langsam“ oder „Anwendung ist ausgefallen“ sein, aber die betriebliche Frage ist, ob der akzeptierte Verbindungszustand noch dem beabsichtigten Zustand entspricht.

Die Automatisierung des Anbieters kann helfen, wenn sie Absichten aufzeichnet und mit der Realität vergleicht. Sie kann schaden, wenn sie wiederholte Aktionen ohne Überprüfung abweichen lässt. Schnelle Bereitstellung ist nützlich, wenn die Aufgabe sich wiederholt und gut spezifiziert ist: eine Verbindung zu einem bekannten Anbieter hinzufügen, Kapazität erweitern, eine Routenpräferenz anpassen, einen Cloud-zu-Cloud-Pfad erstellen oder eine weitere Region unter einer bekannten Richtlinie bereitstellen.

Sie ist gefährlich, wenn jede neue Aktion als Routine behandelt wird, obwohl sich die Anwendung, die Datenklassifizierung, der regulatorische Kontext oder die Ausfalltoleranz geändert haben.

Aus diesem Grund sollte Produktzuverlässigkeit nicht mit Softwarefähigkeit verwechselt werden. Eine softwaredefinierte Schnittstelle kann Bestellungen, Inventar und Überwachung anzeigen. Sie kann eine Änderungsanforderung leichter wiederholbar machen. Sie kann einen saubereren Prüfpfad erzeugen als E-Mail und Tabellenkalkulationen. Aber zuverlässige Cloud-Konnektivität erfordert konservative Voreinstellungen, Routenvalidierung, Zugriffsüberprüfung, Rollback-Disziplin und eine Überwachung, die sowohl die Leitung als auch die Dienstabhängigkeit erkennt.

Der Käufer sollte Automatisierung wünschen, aber keine Automatisierung, die von der Netzwerktechnik losgelöst ist.

Die BSO-Übernahme könnte dies stärken, wenn BSOs breiteres Netzwerk und Service-Desk-Funktionen umfassendere Nachweise rund um die Verbindung liefern. Sie könnte es schwächen, wenn Produktgrenzen unklar werden und Kunden nicht erkennen können, welches Team welchen Zustand besitzt. Die Integration nach einer Übernahme ist nicht nur eine Markenübung. Es ist eine Übung im Support-Zustand.

Der Kunde muss wissen, ob eine von InterCloud stammende Verbindung über den Service-Desk von BSO unterstützt wird, wie die Schweregrade zugewiesen werden, wo historische Designaufzeichnungen liegen, welches Portal die Quelle der Wahrheit enthält und wie eine Änderung genehmigt wird.

Zugriffsrichtlinie ist der stille Fehlerpunkt

Der zweite Test ist der Zugriff. Private Konnektivität wird oft als Sicherheitsverbesserung verkauft, weil sie gewöhnliche öffentliche Internetpfade vermeidet. Das ist teilweise wahr, aber unvollständig. Ein privater Pfad kann dennoch falschen Traffic transportieren, die falsche Umgebung exponieren oder Kontrollen umgehen, die der Kunde für obligatorisch hielt. Die Verbindung selbst ist nicht die Richtlinie. Sie ist der Transport, über den die Richtlinie durchgesetzt werden muss.

In der Praxis hat das Zugriffsproblem mehrere Schichten. Der Kunde hat Identitäts- und Autorisierungsregeln für Cloud-Konten und Netzwerkänderungen. Der Anbieter hat Portalkonten, Service-Desk-Berechtigungen und Änderungsverfahren. Der Cloud-Anbieter hat seine eigenen Ressourcenberechtigungen. Das Netzwerk hat Routenfilter, VLAN-Trennung, Firewall-Regeln und möglicherweise Verschlüsselungsanforderungen. Das Sicherheitsteam hat eine Sicht auf Datenklassifizierung, Protokollierung und Incident Response. Ein Cloud-Konnektivitätsanbieter schafft Wert, wenn er hilft, dass diese Schichten kohärent bleiben.

Deshalb ist Sicherheitsautomatisierung sowohl notwendig als auch gefährlich. Sich wiederholende Konnektivitätsaufgaben sollten keinen heldenhaften manuellen Aufwand erfordern. Ein Kunde, der zehn ähnliche Cloud-Leitungen eröffnet, sollte den Genehmigungsprozess nicht jedes Mal von Grund auf neu aufbauen müssen. Standardvorlagen, bekannte Architekturen und vorab vereinbarte Kontrollen reduzieren Reibung. Aber die Automatisierung muss die Sicherheitsentscheidung bewahren, nicht nur den Netzwerkschritt beschleunigen.

Wenn eine neue Verbindung regulierte Daten transportiert, eine Zuständigkeitsgrenze überschreitet oder einer Cloud-Arbeitslast Zugang zu einem sensiblen On-Premises-System gewährt, kann eine generische Vorlage zu locker sein.

InterClouds alte Positionierung bezüglich Souveränität und Leistung ist hier relevant. Öffentliche Beschreibungen betonten, Unternehmen die Kontrolle über Sicherheit, Souveränität und Leistung ihres kritischen Datenverkehrs zu geben. Das ist das richtige Versprechen für diesen Markt, aber der Beweis ist spezifisch. Wohin geht der Datenverkehr? Welcher Anbieter berührt ihn? Welche Cloud-Region terminiert ihn? Welcher Rechenzentrumsstandort ist beteiligt? Welche Route wird bei einem Failover verwendet? Welche Logs zeigen den Pfad? Welche Kontrollen verhindern, dass eine nicht autorisierte Umgebung die Verbindung nutzt?

Eine Souveränitätsbehauptung ohne Pfad- und Richtliniennachweise ist Marketing.

Datensouveränität und -lokalität sind komplizierter geworden, weil die Cloud-Architektur nicht mehr nur eine Wahl zwischen On-Premises und Public Cloud ist. Eine Arbeitslast kann gleichzeitig eine Public Cloud Region, eine souveräne Cloud-Region, eine Private Cloud, einen SaaS-Dienst und einen verwalteten Netzwerkpfad nutzen. Das öffentliche FastConnect-Partnermaterial von Oracle führt Intercloud beispielsweise als Partner in mehreren europäischen und US-amerikanischen Standorten auf, einschließlich souveränitätsbezogener europäischer Standorte.

Eine solche Auflistung ist ein Hinweis auf potenzielle Reichweite, kein Nachweis dafür, dass die Daten eines bestimmten Kunden in einer gewünschten Jurisdiktion bleiben. Der Kunde benötigt weiterhin eine Designaufzeichnung.

Eine Zugriffsrichtlinien-Inkonsistenz kann teurer sein als ein sichtbarer Ausfall. Ein Ausfall löst Alarme aus. Eine Inkonsistenz kann bestehen bleiben. Traffic könnte über einen unbeabsichtigten Pfad funktionieren. Ein Team könnte während einer Migration breiteren Zugriff gewähren und vergessen, ihn einzuschränken. Ein Cloud-Administrator könnte ein Subnetz hinzufügen, ohne das Netzwerkteam zu informieren. Ein Firewall-Objekt könnte aus Bequemlichkeit wiederverwendet werden. Der akzeptierte Zustand sollte daher eine Sicherheitssicht enthalten: nicht nur, dass Traffic passieren kann, sondern dass nur beabsichtigter Traffic passieren kann.

Die Arbeitsauswirkungen sind real. Gute private Cloud-Konnektivität ändert, was Netzwerk- und Sicherheitsteams tun. Sie verbringen weniger Zeit damit, jeden Cross-Connect von Grund auf zu verhandeln, und mehr Zeit damit, Absichten aufrechtzuerhalten, Ausnahmen zu überprüfen, Eskalationen zu bearbeiten und zu prüfen, ob Automatisierung ein riskantes Muster normalisiert hat. Das mag einige Plackerei reduzieren, beseitigt aber nicht die Notwendigkeit qualifizierter Aufsicht. In vielen Organisationen verlagert es die knappe Arbeit hin zu Architektur und Nachweisen.

Überwachung entscheidet, ob der Dienst handhabbar ist

Der dritte Test ist die Überwachung. Private Konnektivität wird betrieblich nützlich, wenn Anbieter und Kunde den richtigen Zustand zur richtigen Zeit sehen können. Eine Leitung kann aktiv sein, während eine Anwendung unbrauchbar ist. Eine Route kann existieren, während die Latenz außerhalb der Toleranz liegt. Eine Cloud-seitige Ressource kann gesund sein, während eine Kunden-Firewall den Pfad blockiert. Ein Anbieter kann sein Backbone sehen, während der Kunde nur fehlgeschlagene Transaktionen sieht. Überwachung muss diese partiellen Ansichten überbrücken.

BSOs öffentliches Material gibt mehrere Hinweise auf seine Überwachungshaltung. Die Portalseite beschreibt Netzwerküberwachung und -analysen neben automatisierter Bestellung, Ticketverwaltung und Abrechnung. Das Material zu Managed Services beschreibt Infrastrukturüberwachung, Incident Response, Service-Desk und proaktive Überwachung. Älteres öffentliches Material beschrieb eine Partnerschaft mit Accedian für die Leistungsüberwachung von Multi-Carrier-Netzwerken, einschließlich Einblick in Kapazität, Nutzung, Latenz, Paketverlust und verwandte Indikatoren.

Nichts davon beweist das Verhalten einer spezifischen InterCloud-Kundenverbindung heute, aber es zeigt, dass Überwachung Teil der öffentlichen Betriebserzählung ist und nicht ein nachträglicher Einfall.

Der akzeptierte Verbindungszustand sollte umfassen, was überwacht wird und was nicht. Überwacht der Anbieter den Port, die virtuelle Leitung, die BGP-Sitzung, die Routentabelle, Paketverlust, Latenz, Jitter, Auslastung, die Cloud-seitige Verfügbarkeit, die Kunden-Endgeräte oder nur eine Teilmenge? Werden Alarme mit Kundentickets korreliert? Hat der Kunde Einblick über ein Portal? Gibt es einen Unterschied zwischen einer Warnung und einem schwerwiegenden Ausfall? Erkennt der Anbieter einen verschlechterten Pfad, bevor der Kunde ein Anwendungssymptom bemerkt? Diese Fragen sind wichtiger als eine generische Verfügbarkeitsaussage.

Überwachungsblindstellen treten besonders häufig an Übergabepunkten auf. Der Carrier sieht möglicherweise ein sauberes Transportsegment. Der Cloud-Anbieter sieht möglicherweise eine verfügbare On-Ramp. Der verwaltete Anbieter sieht möglicherweise sein Backbone. Der Kunde sieht möglicherweise einen Anwendungs-Timeout. In einem Mehrparteiensystem kann jede Partei technisch korrekt und betrieblich unvollständig sein. Der Wert eines verwalteten Cloud-Konnektivitätsanbieters liegt teilweise in der Fähigkeit, diese diagnostische Lücke zu verringern.

Der Käufer sollte jedem Anbieter gegenüber skeptisch sein, der Überwachung auf eine Dashboard-Ästhetik reduziert. Ein Dashboard ist kein Betriebsmodell. Die schwierige Frage ist, was passiert, wenn das Dashboard und die Benutzererfahrung nicht übereinstimmen. Wer ergreift die erste Maßnahme? Wer kann genügend Nachweise einsehen, um Schuldzuweisungen zu vermeiden? Wer kontaktiert den Cloud-Anbieter oder Carrier? Wer hat die Befugnis, umzuleiten, zurückzusetzen oder zu eskalieren? Wer entscheidet, dass eine verschlechterte Verbindung ein Geschäftsvorfall und keine Hintergrundmetrik ist?

Die Wiederherstellung nach einem Vorfall ist der Moment, in dem der akzeptierte Zustand unter Stress getestet wird. Eine Route kann lecken, eine Cloud-On-Ramp kann ausfallen, ein Carrier-Segment kann sich verschlechtern, eine Sicherheitsregel kann ein neues Präfix blockieren, oder eine geplante Änderung kann einen unerwarteten Latenzpfad erzeugen. Der Kunde braucht nicht nur eine Lösung. Er muss wissen, ob der Anbieter rekonstruieren kann, was sich geändert hat, was ausgefallen ist, welche Problemumgehung angewendet wurde und welcher Zustand nun als akzeptiert gelten soll. Ohne diese Aufzeichnung kann derselbe Vorfall erneut auftreten.

BSOs öffentliches Kontaktmaterial weist Portal-Kunden an, ein Service-Desk-Ticket mit hoher oder sehr hoher Priorität für Notfälle oder größere Ausfälle zu eröffnen. Das ist ein nützliches Signal, weil es den erwarteten Eskalationskanal offenbart. Aber ein Ticketkanal ist nur die Eingangstür. Die betriebliche Qualität hängt von Klassifizierung, Zuständigkeit, Beweissammlung, Kommunikationsrhythmus und Wiederherstellungsbefugnis ab.

Ein bedeutender Cloud-Konnektivitätsanbieter sollte nicht danach beurteilt werden, ob er ein Ticket entgegennehmen kann, sondern danach, ob er einen domänenübergreifenden Vorfall in Richtung eines verifizierten Zustands bewegen kann.

Bereitstellungsbedingungen bestimmen, ob das Versprechen hält

Cloud-Konnektivität ist nicht überall gleichermaßen einfach. Die Bereitstellungsbedingungen sind wichtig. Ein Kunde, der sich bereits in einem BSO-Point of Presence, einem Partner-Rechenzentrum oder an einem Standort mit einfachem Cross-Connect-Zugang befindet, ist in einer anderen Position als ein Kunde, dessen Standort netzfern ist und von einem lokalen Carrier abhängt. Ein Kunde, der eine Verbindung zu einer gut unterstützten Cloud-Region herstellt, ist in einer anderen Position als einer, der eine Region mit weniger Partneroptionen anvisiert.

Ein Kunde mit sauberer IP-Adressierung, dokumentierter Topologie und disziplinierten Cloud-Konten ist einfacher zu bedienen als einer mit fragmentierten Netzwerken und nicht verwalteten Ausnahmen.

BSOs Cloud Connect-Material besagt, dass der Zugang dort bereitgestellt werden kann, wo sein Netzwerk reicht oder über Partner-Rechenzentren, und dass netzferne Kunden entworfene Pfade in die Cloud benötigen. Dieser Satz trägt einen Großteil der kommerziellen Wahrheit. „Verfügbar“ ist nicht dasselbe wie „einfach“. Wenn der Kunde netzfern ist, benötigt der Anbieter möglicherweise lokalen Zugang von Drittanbietern. Wenn Diversität erforderlich ist, kann das Design physisch und logisch getrennte Pfade erfordern.

Wenn die On-Ramp eines Cloud-Anbieters nicht im bevorzugten Markt des Kunden liegt, kann der Pfad einen regionalen Kompromiss beinhalten. Wenn Latenz der Grund für den Kauf des Dienstes ist, muss sich der Kunde um die tatsächliche Route kümmern und nicht um den nominellen Anbieternamen.

Dasselbe gilt für Cloud-zu-Cloud-Konnektivität. Daten über private Pfade zwischen Cloud-Anbietern zu bewegen, kann einige Unsicherheiten des öffentlichen Internets vermeiden und einige Datenverkehrskosten senken, schafft aber eine neue Abhängigkeitsebene. Der Kunde muss die Egress-Richtlinien der Cloud, Portgebühren der Anbieter, Gebühren für verwaltete Konnektivität, Bandbreitenverpflichtungen, Routendesign und betrieblichen Support verstehen. Wenn die Anwendung nicht darauf ausgelegt war, Cloud-übergreifende Latenz- oder Fehlersemantik zu tolerieren, wird ein besserer privater Pfad die Architektur nicht einfach machen.

Die Einheitsökonomie sollte daher als Bündel analysiert werden. Die offensichtlichen Kosten sind die Gebühr für den verwalteten Konnektivitätsdienst. Weniger offensichtliche Kosten umfassen Migrationsplanung, Änderungsfenster, Cloud-Anbieter-Gebühren, Datenübertragungsgebühren, Hardware- oder Portverpflichtungen, Sicherheitsüberprüfung, Überwachungsintegration, Personalschulung und laufende Aufsicht. Die Nutzenseite umfasst reduzierte Netzwerkkomplexität, vorhersagbarere Leistung, privates Routing, schnellere wiederholte Bereitstellung, weniger einmalige Carrier-Projekte und eine bessere Vorfallsoberfläche.

Das Angebot ist nur attraktiv, wenn die vermiedene Komplexität real ist.

Das ist eine hohe Messlatte für einen mittelständischen Käufer. Ein kleines Unternehmen, das eine Cloud und größtenteils internetorientierte Anwendungen nutzt, benötigt möglicherweise keinen verwalteten privaten Cloud-Konnektivitätsanbieter. Ein Unternehmen mit mehreren Regionen, regulierten Daten, latenzempfindlichen Prozessen, privaten Anwendungen, Zweigstellennetzwerken oder wiederkehrenden Cloud-Änderungsarbeiten hat möglicherweise einen stärkeren Fall. Die kommerzielle Frage ist nicht, ob private Cloud-Konnektivität gut ist.

Es geht darum, ob die Arbeitslast und das Betriebsmodell des Kunden komplex genug sind, damit der Dienst günstiger ist als die fortgesetzte Fragmentierung.

InterClouds Altkunden, sofern sie innerhalb von BSO migriert oder unterstützt werden, stehen vor einer besonderen Bereitstellungsfrage. Sie benötigen Kontinuität, aber auch Klarheit. Welche Produktnamen bleiben in Kraft? Welche Service-Level gelten? Welches Portal soll verwendet werden? Welche Supportnummern oder Ticketkategorien sind relevant? Welche BSO-Funktionen stehen ihnen nun zur Verfügung, und welche erfordern eine kommerzielle Änderung? Die Übernahmeankündigung betonte die Servicekontinuität für InterCloud-Kunden. Die betriebliche Version dieses Versprechens ist Dokumentation, nicht Gefühl.

Der Upstream-Abhängigkeitsstapel ist größer als die Marke

Kein Cloud-Konnektivitätsanbieter kontrolliert vollständig den Dienst, den er verkauft. Er kontrolliert Teile des Pfades, schließt Verträge für andere und koordiniert den Rest. InterCloud und BSO sind für On-Ramps und Cloud-seitige Konstrukte von Cloud-Anbietern abhängig. Sie sind für die physische Zusammenschaltung von Rechenzentren abhängig. Sie sind für netzferne Reichweite und einige Fernstrecken von Carriern abhängig. Sie sind von Routing-Ausrüstung, Überwachungssystemen, Support-Tools, Identitätssystemen und Kundendatensätzen abhängig.

Der Kunde ist von all dem abhängig, unabhängig davon, ob die Rechnung einen oder mehrere Lieferanten zeigt.

Dieser Abhängigkeitsstapel ist an sich keine Schwäche. Es ist die Natur des Marktes. AWS Direct Connect, Azure ExpressRoute, Google Partner Interconnect und Oracle FastConnect alle formalisieren dieselbe Grundidee: private oder partnervermittelte Konnektivität zwischen Kundenumgebungen und Cloud-Ressourcen. Der Cloud-Anbieter stellt den Cloud-seitigen Dienst bereit. Partner und Carrier erweitern die Reichweite. Netzwerkplattformen und verwaltete Anbieter verpacken das Ergebnis. Käufer wählen, wie viel von dieser Integration sie selbst durchführen möchten.

Das Risiko besteht darin, dass die Verpackung die Fehlereigentümerschaft verschleiert. Ein Routenproblem kann im Router des Kunden liegen. Ein physisches Problem kann in einem Cross-Connect liegen. Ein Problem mit einer virtuellen Leitung kann bei einem Cloud-Anbieter liegen. Eine Latenzüberraschung kann aus einer Routenwahl resultieren, die außerhalb der direkten Kontrolle des verwalteten Anbieters liegt. Eine Firewall-Fehlanpassung kann dem Sicherheitsteam des Kunden gehören. Ein Portal-Fehler kann dem Dienstleister gehören.

Wenn alles als eine Cloud-Verbindung verkauft wird, muss der Vorfallprozess dennoch diese Unterscheidungen aufrechterhalten.

Deshalb ist die Nachweisdisziplin des Anbieters entscheidend. Ein reifer Anbieter sollte in der Lage sein zu sagen: Dieses Segment gehört uns, dieses Segment wird von einem Partner kontrolliert, dieses Segment wird vom Kunden kontrolliert, und dies ist der aktuelle Nachweis. Er sollte nicht verlangen, dass der Kunde während eines Ausfalls zum forensischen Koordinator wird. Noch sollte er implizieren, dass ein einzelner Anbieter jede Schicht eines Mehrparteienpfades garantieren kann.

BSOs größeres Netzwerk kann ein gewisses Abhängigkeitsrisiko verringern, indem es mehr Reichweite und Betriebskapazität in dieselbe Organisation bringt. Es kann auch ein Konzentrationsrisiko schaffen, wenn der Kunde zu viele Konnektivitätsentscheidungen an einen einzigen Lieferanten auslagert, ohne Routenwissen zu behalten. Die beste Käuferhaltung ist nicht blindes Vertrauen oder permanente Do-it-yourself-Skepsis. Es ist ein strukturiertes Abhängigkeitsmanagement: Wissen, was ausgelagert ist, wissen, was weiterhin in Eigenverantwortung bleibt, und zu jedem Akzeptanzpunkt Nachweise verlangen.

Wettbewerber und Substitute definieren die kommerzielle Obergrenze

InterCloud konkurriert nicht nur mit Unternehmen, die dasselbe Vokabular verwenden. Die Substitute sind breit gefächert. Ein großes Unternehmen kann direkt bei Cloud-Anbietern und Carriern einkaufen und interne Ingenieure nutzen, um den Dienst zusammenzustellen. Es kann Equinix Fabric oder eine Rechenzentrums-Interconnection-Plattform nutzen. Es kann Megaport oder Console Connect für die Bereitstellung im Network-as-a-Service-Stil verwenden. Es kann einen globalen Telekommunikationsanbieter, einen SD-WAN-Anbieter, einen Managed Service Provider oder einen Cloud-Systemintegrator nutzen.

Es kann auch entscheiden, dass öffentliches Internet plus Verschlüsselung und Ausfallsicherheit auf Anwendungsebene ausreichend ist.

Diese Substitute begrenzen die Preissetzungsmacht und formen das Produkt. InterCloud und BSO müssen besser sein als die interne Zusammenstellung für Kunden, denen Zeit, geografische Reichweite oder Fachkenntnisse fehlen. Sie müssen geführter sein als reine Self-Service-Plattformen für Kunden, die verwaltete Verantwortlichkeit wünschen. Sie müssen flexibler sein als traditionelle Carrier-Projekte für Kunden mit wiederholten Cloud-Änderungsmustern. Sie müssen konkreter sein als generische Cloud-Beratung für Kunden, die betriebliche Konnektivität benötigen, nicht Ratschläge.

Der stärkste kommerzielle Fall ist ein Kunde mit sich wiederholenden Aufgaben. Eine einmalige private Verbindung kann von vielen Anbietern abgewickelt werden. Der Wert steigt, wenn der Kunde wiederholt Cloud-Regionen hinzufügt, Kapazität anpasst, neue Standorte anbindet, Routenrichtlinien ändert, Migrationen durchführt, Vorfall-Failover handhabt oder konsistente Nachweise über Geschäftsbereiche hinweg benötigt. In dieser Welt können eine Plattform und ein verwalteter Dienst eine Abfolge von Einzelprojekten in ein kontrolliertes Betriebsmuster verwandeln.

Der schwächste Fall ist ein Kunde, der will, dass der Anbieter unklare kundenseitige Zuständigkeiten kompensiert. Wenn Anwendungsteams, Cloud-Teams, Netzwerkteams und Sicherheitsteams sich nicht auf die Absicht einigen können, kann ein externer Anbieter zwar Leitungen bereitstellen, aber die geschäftliche Korrektheit nicht definieren. Er kann zur sichtbaren Partei werden, die für Fehler verantwortlich gemacht wird, die durch organisatorische Ambiguität verursacht werden. Das erhöht die Aufsichtskosten und schwächt die Einheitsökonomie.

Hier sollten die Auswirkungen auf Organisation und Arbeit ernst genommen werden. Eine erfolgreiche verwaltete Cloud-Konnektivitätsbereitstellung kann geringwertige Koordinationsarbeit reduzieren. Sie kann die Anzahl manueller Carrier-Interaktionen verringern. Sie kann Aufzeichnungen standardisieren. Sie kann Cloud-Teams einen schnelleren Weg zu genehmigter Konnektivität geben. Sie kann Sicherheitsteams eine klarere Überprüfungsfläche bieten. Aber sie verlangt auch einen benannten Eigentümer für die Konnektivitätsabsicht. Jemand in der Kundenorganisation muss entscheiden, was „akzeptiert“ bedeutet.

Wenn niemand diesen Zustand besitzt, wird jedes Anbieterversprechen angreifbar. Das Netzwerkteam mag für Erreichbarkeit optimieren. Das Sicherheitsteam mag für Einschränkung optimieren. Das Cloud-Team mag für Geschwindigkeit optimieren. Die Finanzabteilung mag für niedrigere wiederkehrende Kosten optimieren. Der Anwendungseigentümer mag für Benutzererfahrung optimieren. Der Anbieter muss eine gemischte Anforderung erfüllen. Je besser die Governance des Käufers, desto wertvoller wird die Automatisierung des Anbieters.

Kundennachweise sind vorhanden, aber nicht vollständig

Die öffentlichen Marktnachweise rund um InterCloud und BSO sind nützlich, haben aber Grenzen. BSO veröffentlicht Kundenreferenzen und Fallstudienmaterial in angrenzenden Bereichen verwalteter Netzwerke, Cloud-Infrastruktur und Konnektivität. Die Website zeigt Kundennamen und Zitate auf Support-, Technologie- und Cloud-zu-Cloud-Seiten. Equinix führt InterCloud als Reseller-Partner und beschreibt die verwalteten und Self-Service Cloud-Konnektivitätsprodukte von InterCloud. Oracle listet Intercloud unter den FastConnect-Partnern nach Region.

LinkedIn und Marktdatenbanken bewahren die historische Beschreibung von InterCloud als softwaredefinierten Cloud-Interconnect-Anbieter. Französische Unternehmensinformationsquellen dokumentieren die Unternehmensidentität von InterCloud und die Geschichte der rechtlichen Unterlagen. Französische Technologiemedien berichteten über die BSO-Übernahme und den Kontext des gerichtlichen Sanierungsverfahrens.

Das reicht aus, um die Kategorie und die Betriebsgrenze festzulegen. Es reicht nicht aus, um die kundenspezifische Leistung zu belegen. Es gibt kein öffentliches Beweispaket, das die aktuelle durchschnittliche Reparaturzeit, die tatsächliche Routenstabilität der Kunden, die Ausfallhistorie, die Abwanderung, den Umsatz, die Preisgestaltung, die Einhaltung von Service-Levels oder die Qualität der Integration nach der Übernahme zeigt. Diese Fakten mögen privat existieren, sollten aber nicht aus öffentlichem Material abgeleitet werden.

Das ist wichtig, weil die Märkte für Cloud-Konnektivität voller Behauptungen sind, die richtungsweisend plausibel und betrieblich unterspezifiziert sind. „Sicher“ kann privaten Transport, Verschlüsselung, Richtlinienkontrollen, Überwachung oder alles davon bedeuten. „Niedrige Latenz“ kann eine Routenoption, ein gemessenes Ergebnis oder eine relative Verbesserung gegenüber öffentlichen Internetpfaden bedeuten. „Global“ kann eigenes Netzwerk, Partnerreichweite, Cloud-On-Ramp-Abdeckung oder kommerzielle Verfügbarkeit bedeuten. „Verwaltet“ kann Designhilfe, 24-Stunden-Support, aktive Überwachung oder nur einen Ticketpfad bedeuten.

Ein ernsthafter Käufer fragt nach Definitionen.

BSOs Übernahmeankündigung präsentierte InterCloud als einen Schlüsselakteur für direkte Konnektivitätsdienste in öffentlichen und privaten Cloud-Umgebungen und erklärte, die Transaktion werde einen unterbrechungsfreien Dienst für InterCloud-Kunden sicherstellen, während Technologien in BSO integriert werden. Diese Aussage ist kommerziell wichtig, aber es ist immer noch eine öffentliche Übernahmeerzählung. Die Folgefrage des Käufers sollte betrieblicher Natur sein: Zeigen Sie den aktuellen Servicekatalog, das Supportmodell, das Portalverhalten, den Eskalationsablauf und die technischen Akzeptanzkriterien.

Der stärkste Beweis ist oft banal. Kann der Anbieter ein Beispiel für einen Akzeptanzdatensatz mit entfernten sensiblen Details zeigen? Kann er zeigen, wie eine Routenänderung angefordert, genehmigt, implementiert, getestet und zurückgesetzt wird? Kann er zeigen, wie die Überwachung den Ticketschweregraden zugeordnet wird? Kann er zeigen, was passiert, wenn ein Cloud-Anbieter ein On-Ramp-Problem hat? Kann er zeigen, wie das Kundeninventar aktuell gehalten wird? Das sind keine glamourösen Fragen. Es sind die Fragen, die einen verwalteten Konnektivitätsdienst von einer teuren Leitung unterscheiden.

Die Fehlermodi sind vorhersehbar

Die bekannten Fehlermodi sind nicht exotisch. Der erste ist ein Routenleck oder Fehler in der Routenrichtlinie. Dies ist der klassische Netzwerkfehler, da er Datenverkehr dem falschen Pfad aussetzen oder die Erreichbarkeit destabilisieren kann. Gute Kontrollen umfassen Präfixfilterung, Änderungsüberprüfung, gestaffelte Einführung, Routenüberwachung und Rollback-Verfahren.

Der zweite ist eine Zugriffsrichtlinien-Inkonsistenz. Eine Verbindung funktioniert, aber die falsche Quelle, das falsche Ziel oder das falsche Subnetz ist erlaubt. Oder der beabsichtigte Fluss wird blockiert, weil eine Sicherheitskontrolle nicht aktualisiert wurde. Gute Kontrollen umfassen Änderungsaufzeichnungen, die die Konnektivitätsarbeit mit der Sicherheitsgenehmigung verbinden, sowie eine Nachänderungsvalidierung sowohl von der Netzwerk- als auch von der Anwendungsseite.

Der dritte ist eine Latenzüberraschung. Der Käufer erwartete einen schnelleren oder vorhersagbareren Pfad, aber die implementierte Route, der Ausweichpfad oder die Cloud-seitige Abhängigkeit verhält sich anders. Gute Kontrollen umfassen Pfaddokumentation, Basismessung, realistische Leistungssprache und Klarheit darüber, welche Segmente außerhalb der direkten Anbieterkontrolle liegen.

Der vierte ist ein Ausfall oder eine Verschlechterung der Cloud-On-Ramp. Der private Pfad kann weiterhin von einem Cloud-Anbieterstandort oder einer Partnerübergabe abhängen. Gute Kontrollen umfassen redundantes Design, Bewusstsein für Cloud-Regionen, Eskalationskontakte und dokumentierte Ausweichoptionen.

Der fünfte ist eine Überwachungsblindstelle. Der Anbieter sieht seine Leitung als gesund an, während der Kunde einen Anwendungsausfall erlebt. Gute Kontrollen umfassen gemeinsame Metriken, synthetische Prüfungen wo angemessen, Routen- und Sitzungseinsicht sowie Vorfallverfahren, die nicht an der Anbietergrenze enden.

Der sechste ist ein Fehler bei der Carrier-Übergabe. Netzferner Zugang und Partnerpfade können Verzögerungen und Mehrdeutigkeiten mit sich bringen. Gute Kontrollen umfassen benannte Abhängigkeiten, physische Diversitätsaufzeichnungen, Eskalationsverfahren für Carrier und klare Zuständigkeit für die letzte Meile.

Der siebte ist Produktgrenzenverwirrung nach einer Übernahme. Ein Kunde weiß möglicherweise nicht, ob er einen alten InterCloud-Dienst, einen BSO-markierten Dienst oder ein hybrides Supportmodell nutzt. Gute Kontrollen umfassen Service-Mapping, Vertragsklarheit, Mitteilungen zur Support-Migration und aktuelle Betriebsdokumentation.

Der achte ist eine Verzögerung bei der Vorfalleskalation. Das richtige Team erhält möglicherweise nicht schnell genug die richtigen Nachweise. Gute Kontrollen umfassen Schweregraddefinitionen, Portaldisziplin, Kontaktpfade und vorab vereinbarte Notfallverfahren.

Keiner dieser Fehler macht das Angebot von InterCloud oder BSO ungültig. Sie definieren die Arbeit. Ein Unternehmen in dieser Kategorie ist erfolgreich, wenn es diese Fehler weniger wahrscheinlich, sichtbarer und schneller lösbar macht. Es scheitert, wenn es sie als Randfälle behandelt.

Der praktische Käufertest

Ein praktischer Käufer sollte InterCloud durch BSO anhand einer kurzen, anspruchsvollen Akzeptanzcheckliste bewerten. Erstens: Identifizieren Sie die Dienstgrenze. Welche juristische Person schließt den Dienstvertrag ab? Welches Produkt wird verkauft? Welche Teile stammen aus dem InterCloud-Erbe und welche aus dem Netzwerk oder den Managed Services von BSO? Zweitens: Identifizieren Sie den Pfad. Welche Standorte, Rechenzentren, Cloud-Regionen und On-Ramps sind beteiligt? Welche Segmente sind netzeigen, partnerabhängig oder kundengesteuert? Drittens: Identifizieren Sie die Richtlinie.

Welche Routen, Präfixe, Zugriffsregeln und Sicherheitskontrollen definieren den Dienst?

Viertens: Identifizieren Sie die Betriebsoberfläche. Welches Portal wird für Bestellungen, Überwachung und Tickets verwendet? Welche Ereignisse lösen Alarme aus? Welche Schweregrade gelten? Welches Supportteam übernimmt die Erstreaktion? Fünftens: Identifizieren Sie die Nachweise. Welcher Nachweis wird erstellt, wenn die Verbindung akzeptiert wird? Welcher Nachweis wird nach einer Änderung erstellt? Welcher Nachweis ist während eines Vorfalls verfügbar? Sechstens: Identifizieren Sie die Wirtschaftlichkeit.

Was sind die wiederkehrenden Servicegebühren, Cloud-Anbieter-Gebühren, Annahmen zur Datenübertragung, Migrationskosten und Personalkosten für die Aufsicht? Siebtens: Identifizieren Sie den Ausstiegsplan. Falls der Dienst enttäuscht, wie portabel ist das Design zu einem anderen Anbieter oder zu direkter Cloud-Konnektivität?

Diese Checkliste mag schwerfällig erscheinen, aber sie ist günstiger als Mehrdeutigkeiten während eines Ausfalls zu entdecken. Sie respektiert auch die Kategorie. Verwaltete Cloud-Konnektivität ist gerade deshalb wertvoll, weil das zugrunde liegende System schwierig ist. Es als einfach zu behandeln, untergräbt den Grund, es zu kaufen.

Für InterCloud ist die Gelegenheit nach wie vor real. Unternehmen werden nicht weniger verteilt. Cloud-Regionen, souveräne Cloud-Angebote, private Anwendungen, SaaS-Abhängigkeiten und datenintensive Arbeitslasten vermehren sich weiter. Das öffentliche Internet ist nicht immer das richtige Substrat für geschäftskritischen Datenverkehr. Interne Teams sind oft überlastet. Ein Anbieter, der private Reichweite, Cloud-Anbieter-Übergaben, betriebliche Nachweise und Service-Desk-Disziplin kombinieren kann, kann Wert schaffen.

Das Risiko ist ebenso real. Die Multi-Cloud-Sprache ist aufgebläht worden. Kunden haben gelernt, dass Cloud-Abstraktion oft Kosten verbirgt, anstatt sie zu beseitigen. Direkte Cloud-Anbieter-Dienste verbessern sich. Interconnection-Plattformen sind ausgereift. Network-as-a-Service-Wettbewerber sind sichtbar. Käufer können glaubwürdige Alternativen zusammenstellen. InterCloud innerhalb von BSO muss daher durch Ausführung gewinnen, nicht durch Vokabular.

Die entscheidende Frage ist einfach: Kann der Anbieter nach einer Änderung oder einem Vorfall den akzeptierten Zustand nachweisen? Wenn ja, ist der Dienst nicht nur Konnektivität. Es ist betriebliche Kontrolle über eine schwierige Grenze zwischen Unternehmensnetzwerken und Cloud-Plattformen. Wenn nicht, bleibt dem Käufer nur eine weitere Managementebene auf der gleichen alten Unsicherheit.

Das ist der angemessene Standard für InterCloud jetzt. Nicht ob das Unternehmen Cloud-Interconnect sagen kann. Nicht ob BSO ein breites Netzwerk hat. Nicht ob ein Portal eine Bestellung aufgeben kann. Der Standard ist, ob die beabsichtigte Cloud-Verbindung eines Kunden zu einem verifizierten, überwachbaren, unterstützbaren und wirtschaftlich vertretbaren Zustand wird, und zwar wiederholt, unter gewöhnlichem Änderungsdruck und unter Ausfalldruck. Alles andere ist nur die Hochglanzversion der Route.