Drastischer Umsatz-Rückgang bei Cisco durch SDN zu erwarten?

11 Kommentare Drucken

Die Cisco-Aktie fährt in den letzten Wochen Achterbahn. Langfristig werden über die nächsten Jahre an der Börse Umsatzeinbußen von bis zu 50% diskutiert. Dabei ist Cisco stellvertretend für die ganze Branche zu sehen. Wie real sind diese Szenarien? Erschüttern neue Technologien wie SDN und NSX von VMware die Fundamente der Netzwerkbranche? Hat VMware die Zukunft des Netzwerkmarktes in der Hand?

An dieser Stelle wird unterstellt, dass Sie die Grundideen von SDN kennen. Wenn nicht, sei auf das sehr gute Übersichtsvideo von Frau Borowka-Gatzweiler bei ComConsult-Study.tv verwiesen.

Drastischer Umsatz-Rückgang bei Cisco durch SDN zu erwarten?

Laufzeit des Originalvideos: 00:00

Ausschnitt aus dem Video: Software Defined Networking SDN in der technischen Analyse

Abonnenten von ComConsult-Study.tv können dort das vollständige Video in HD-Qualität sehen.

Der Witz bei dieser neuen Technologie ist, dass die lokalen Switches durch Universal-Switches ersetzt werden, die jede Form von Switching umsetzen können. Anstelle der bisherigen Aufteilung in Layer-2-, Layer-3- oder Layer-5-Switches erhalten wir einen einheitlichen Typ von Switch, der funktional alles kann. Es wird dabei eine Unterscheidung in Leistungsklassen geben (im Sinne der Anzahl bearbeitbarer Flows und der Bearbeitungstiefe). Erreicht wird dies durch Ersetzung der bisherigen L2- und L3-Tabellen in den Switches durch einen Universalmechanismus (Matching genannt), der auf allen Feldern eines Frames aufsetzen kann (abhängig von der Norm und den dabei unterstützten Feldern, gängigstes Beispiel ist momentan Open Flow in der neuesten Version). Flows sind nichts anderes als Match-Muster, die mit einer Aktion verbunden werden. Also zum Beispiel: Wenn die Zieladresse die IP-Adresse xyz ist, dann leite das Paket auf Port 17 weiter. Im Gegensatz zu den bisherigen Switching-Verfahren werden diese Flows nicht lokal festgelegt, sondern in einer zentralen Instanz, dem SDN-Controller. Der Controller bestimmt und lädt die Match-Aktions-Regeln auf die Switches. Verfahren wie Spanning Tree oder OSPF laufen dann also nicht mehr lokal auf jedem beteiligten Switch, sondern in einem zentralen Gerät.

Vereinfachen wir diese Sichtweise weiter, dann bedeutet das:

  • Lokale Switches werden durch Einheits-Massenswitches ersetzt.
  • Es gibt keine Unterscheidung mehr zwischen L2 und L3. Jeder Switch kann alles.
  • Der Rest ist Software in einem zentralen Controller.

Damit sind eine Reihe von Fragen verbunden:

  • Gibt es auf der Hardware-Ebene überhaupt noch Alleinstellungs-Merkmale?
  • Wer produziert die ASICs?
  • Ist eine zentrale Steuerung wirklich besser als eine dezentrale?
  • Wie muss man sich diese zentrale Software eigentlich vorstellen?

Die Frage der Alleinstellungsmerkmale wird davon abhängen wer diese Switches anbieten wird. Austauschbare Massenware so wie sie SDN in seiner Grundidee unterstellt kann und wird ja auch von anderen als den bisher etablierten Anbietern kommen. Das können bekannte Größen wie Intel sein (Intel hat seinen Hut bereits mit einem Referenz-Design in den Ring geworfen), das können aber auch völlig neue Anbieter zum Beispiel aus China sein. Je mehr neue Mitspieler in diesen Markt drängen, desto mehr wird sich ein neues Gefüge aus Preis und Leistung einstellen. Im Klartext: Mit hoher Wahrscheinlichkeit wird der Hardware-Umsatz drastisch einbrechen. SDN ist ein Synonym für einen Marktwechsel weg von der Hardware und hin zur Software.

Wie professionell sind solche Lösungen überhaupt betreibbar, haben wir nicht aus gutem Grund dezentrale Lösungen? Nun eines ist klar. Eine zentrale Lösung ist im Längen einfacher zu programmieren als eine dezentrale Lösung. Der Algorithmus zur Bestimmung des kürzesten Weges in einem Graphen besteht nur aus wenigen Zeilen. Die passende Datenstruktur vorausgesetzt, wird das zu einer Trivialität. Dezentrale Verfahren haben eben keine Gesamtübersicht. Aber sie haben den Vorteil, dass sie auch funktionieren, wenn die Verbindung zur Zentrale unterbrochen ist. Ein dezentrales Verfahren ist in einem gewissen Umfang autonomer. Das kann man auch anders formulieren: bei einem zentralen Verfahren muss dafür gesorgt werden, dass der Zugang zu einer zentralen Instanz (es wird mindestens zwei geben müssen) mit einer hohen Wahrscheinlichkeit möglich ist (99,99999% oder so etwas).

Also die zentralen Verfahren werden einfacher. Dann kann ja jeder diese Software schreiben, oder?

Bevor Sie zur Tastatur greifen gibt es da noch ein paar Kleinigkeiten zu beachten. Natürlich liegt das primäre Ziel von SDN nicht nur in einer Ablösung der dezentralen Verfahren durch ein zentrales. Es geht auch darum, dass Netzwerke dynamischer werden, dass Kommunikationswege und Priorisierungen abhängig von der Betriebssituation dynamisch geändert werden können.

Beispiel 1: Lenkung von großen Backup- und Restore-Datenströmen dynamisch über unterschiedliche Wege und damit bessere Anpassung an die lokale Betriebssituation

Beispiel 2: Dynamische Bandbreiten-Zuweisung für Lync-Videokonferenzen gesteuert durch Lync selber

Beispiel 3: Dynamische Tunnel-Verfahren, um in einem Notfall Applikationen und Daten zwischen Rechenzentren oder hin zu einem Cloud-Provider schnell verlagern zu können

Die ersten größeren Anwendungsbereiche wird es vermutlich im Bereich Sicherheit und Netzwerk-Analyse geben. SDN gestattet es eben, einen bestimmten Flow zu einem zentralen Sicherheitsgerät oder einem zentralen Analysator für weitergehende Analysen umzulenken.

Das hört sich jetzt schon deutlich komplizierter an. Gut, dass Sie noch nicht zur Tastatur gegriffen haben. Aber wie muss man sich das strukturell vorstellen?

Tatsächlich ist die zentrale Steuerung nicht eine zentrale Software, sondern eine Architektur bestehend aus mehreren und grundverschiedenen Software-Elementen:

  • Die Controller-Software liefert die Basis-Funktionalität und stellt die Datenstrukturen und den Zugriff auf die Hardware-Switches im Feld bereit.
  • Die eigentliche Zusatzfunktionalität kommt aus Applikationen, die über das sogenannte North-Bound-Interface auf die Basis-Funktionalität zugreifen.

Zu dieser Software-Architektur gibt es momentan erhebliche Diskussionen, die an dieser Stelle aber mal als belanglos und typisch für den Aufbau einer neuen Technologie hintenan gestellt werden.

Die zentrale Frage dieser Software-Architektur ist eine andere:

  • Kann es wirklich sein, dass Applikationen direkt ins Netzwerk eingreifen und dynamisch Bandbreiten, Wege und Prioritäten festlegen?

Die Lync-Applikation von HP ist ein gutes Beispiel dafür. Stellen wir uns vor, dass der Vorstand eine Lync-Videokonferenz durchführen will (warum auch immer, keine Diskussion von Videokonferenz-Lösungen an dieser Stelle). Dann soll die Applikation dynamisch den Weg für den Vorstand im Netzwerk frei räumen. Im LAN, im WAN, eben überall. Vorstand ist schließlich Vorstand. Jetzt läuft aber gleichzeitig ein elementares Restore für die Mail-Server-Datenbank. Lync entscheidet jetzt von sich aus, diese Applikation zu blocken?

Fassen wir diese Diskussion kurz: Netzwerk-Applikationen können und dürfen nicht direkt auf Netzwerke zugreifen. Es muss etwas dazwischen geben, das zwischen dem Bedarf der verschiedenen Applikationen abwägt. Diese Instanz nennen wir Service-Orchestrierung.

Jetzt wird ein wenig klarer, dass wir bei SDN über einen erheblichen und sehr umfangreichen Software-Überbau sprechen.

Damit sind folgende Fragen verbunden:

  • Wer kann diese Software schreiben und liefern?
  • Wie teuer kann solche Software werden?

Die Applikationen, die über das Northbound-API auf die zukünftige Orchestrierung zugreifen, können im Prinzip von beliebigen Anbietern kommen. Sicherheitsanbieter werden sich hier ebenso austoben wie Load-Balancer, UC-Hersteller, Speicher-Software-Hersteller (Backup, Snapshot, Restore). Die Frage ist, wer den Controller und die Orchestrierung liefern kann.

Und um diese Frage geht es im Kern. Dabei sind mindestens zwei Szenarien denkbar:

  • Die heutigen Netzwerk-Hersteller liefern statt Hardware in Zukunft diese Software-Lösungen.
  • Neue Anbieter verdrängen die heutigen Hersteller.

Genau über diese Frage diskutiert die Börse in New York im Moment. Und da fließen historische Erfahrungswerte ein. In der Vergangenheit ist es so gut wie nie vorgekommen, dass eine Transformation von einem Hardware- zu einem Software-Unternehmen funktioniert hat. Für Cisco würde das bedeuten, dass kein Stein auf dem anderen bleibt und am Ende ein neues Unternehmen steht. Vielleicht ist der Übergang der klassischen TK zu UCC ein gutes Beispiel für diesen Übergang. Und bis heute blockieren die Hardware-lastigen Abteilungen hier den Übergang zu einer wirklich überzeugenden Software. Dies hat die Tür für neue Anbieter wie Microsoft geöffnet. Mit einem veränderten und Cloud-unterstützen Arbeitsplatzmodell wie es Office 365 liefert wird Microsoft vermutlich mit Lync in den nächsten Jahren den anderen UCC-Anbietern das Leben schwer machen. In Deutschland wird Lync bisher nicht als Teil von Office 365 angeboten, von daher wird das vielleicht nicht so beobachtet. Doch auf dem Weltmarkt tobt der Kampf Google kontra Microsoft. Funktional hat Microsoft die besseren Karten, im Endeffekt wird die Frage entscheiden, wie qualitativ integriert und nutzbar Office 365 werden wird. Jedenfalls war die Entscheidung, Yammer zum Standard-Bestandteil der E3-Lizenz zu machen, eine gute Entscheidung.

Also zurück zur Software. Kann man sich vorstellen, dass Cisco ein Software-Unternehmen wird? Und was wird das für die Margen bedeuten? Vielleicht sollte man die Frage auch anders herum stellen.

Welchem Anbieter trauen wir zu, eine Software mit diesem Grad an Komplexität und Know-How zu schreiben?

Damit rückt VMware ins Rampenlicht. VMware steht unter Druck, sein Geschäftsmodell zu erweitern. Traditionelle Virtualisierungs-Software kann wohl kaum länger zu diesen Preisen vermarktet werden. Auch hier drückt Microsoft mit Hyper-V und Massensoftware gewaltig. VMware zeigt bereits mit NSX Flagge. Tatsächlich gibt es im Umfeld virtualisierter Rechenzentren einen Bedarf für Service-bewusste Netzwerke. Dazu gibt es ganz verschiedene Lösungsansätze. Auf der Netzwerkebene hätte Shortest Path Bridging so wie von Avaya angeboten gute Karten (mit vielen offenen Fragen zur handhabbaren Menge der Service-Tags). Aber die zentrale Frage ist, ob die Lösung nicht aus dem Hypervisor kommen muss. Wir von ComConsult Research halten diese Frage für eine der dominanten Fragen des nächsten Jahres.

Momentan gibt es auch zu VMware kaum tragfähige Alternativen. Der Anbieter muss erfahren in der Produktion großer und komplexer Software sein und er muss passende Lizenzmodelle kennen. Für Microsoft ist das Thema zu speziell und Oracle wird hier vermutlich nicht einsteigen wollen.

Damit sind wir beim Fazit und der aktuellen Prognose: Wir werden in den nächsten Monaten einen intensiven Wettbewerb zwischen Cisco und VMware beobachten. Cisco wird mit allen Mitteln versuchen, eine Etablierung von NSX zu verhindern. Mit NSX hat VMware eine Tür im wichtigen Netzwerk-Software-Markt der Zukunft.

SDN und die Zukunft des Netzwerkmarktes wird sich nicht am Bedarf entscheiden. Sie wird sich an der Frage entscheiden, wer die neuen Lösungen und zu welchem Preis anbieten wird.

zugeordnete Kategorien: LAN
zugeordnete Tags: , , , ,

Sie fanden diesen Beitrag interessant? Sie können



11 Kommentare zu "Drastischer Umsatz-Rückgang bei Cisco durch SDN zu erwarten?":

  1. Dr. Krystian Wencel schreibt:

    Ein zweifellos hochinteressenter und zugleich brisanter Artikel. Doch ist er leider rein Technologie orientiert. Was uns die NSA-Affäre und Snowden-Enthüllungen gelehrt haben bzw. lehren sollten, ist: Technologie ist nicht mehr eine Sache des technischen Fortschritts und seiner Machbarkeit in Form des Austausches von Hardware durch Software. Technologie ist eine politische Waffe (schon immer gewesen), die immer und überall Anwendung findet und mit deren Auswirkungen wir uns intensivst auseinandersetzen müssen, um unsere eigene Wettbewerbsfähigkeit zu sichern und zu schützen. Leider haben unsere Politik, ihre Organe, aber auch die Wirtschaft diese Erkenntnis vergessen. Wir können zwar Autos bauen, aber bei IT sind wir ein Entwicklungsland.
    Ich bin absolut davon überzeugt, dass Software hier das Rennen für sich entscheiden wird und kann dem Beitrag nur voll zustimmen. Folglich kann man nicht mehr abwarten wer gewinnt, sondern wir müssen sehr schnell lernen, aus diesen Trends politische und sicherheitstechnische Konsequenzen abzuleiten. Nicht umsonst geht China mit Huawei und ZTE den eigenen unabhängigen Weg.
    Stellen wir uns einfach mal vor, diese Entwicklung von SDN und NSX seien nicht nur technologisch getrieben, sondern auch politisch gefördert, dann kommt jeder Leser von selbst auf weitreichende Schlussfolgerungen. Für neue IT-Start-ups also ein geniales Betätigungsfeld. Doch bevor die Sicherheit und Abwehr für SDN und NSX nicht durch neue möglichst eigene Produkte gewährleistet sind, sollte man vorerst bei den bisher noch „bewährten“ dezentralen Lösungen mit den ohnehin fragilen Schutzmechanismen bleiben.

  2. Dr. Kauffels schreibt:

    Der Artikel ist – wie könnte es bei dem Autor anders sein – auf einem hohen fachlichen Niveau und ich möchte die Inhalte nicht insgesamt in Frage stellen. Allerdings denke ich, dass der Autor und auch manche Kommentatoren des Börsengeschehens die eher trivialen Dinge in dieser Welt gerne vergessen. Es geht ja primär um die Frage, warum Cisco in den nächsten Quartalen so deutlich Umsatz verlieren wird, dass Herr Chambers nicht umhin kam, das mittels einer miserablen Prognose zu versehen. Es geht aber um die NÄCHSTEN Quartale, also 2,3, oder 4 und nicht um die Aussicht für das ab jetzt 13. oder 27. Quartal. Es mag ja sein, dass dieses ganze Software-Gedöns (wie der Rheinländer sagen würde) irgendwann einmal tatsächlich funktioniert, aber bis es dem Kunden so viel nützt, dass er es auch so oft kauft, dass es letztlich den Gewinn eines Herstellers steigert, werden noch einige Jahre vergehen. Die Wahrheit ist viel trivialer:

    1. Der Bedarf für neue Lösungen und Erweiterungen steigt offensichtlich langsamer als prognostiziert und langsamer als in den letzten Jahrzehnten üblich. Das sieht man an den Schnittstellen, 10 GbE ist sicher etabliert, aber 40 GbE tut sich noch sehr schwer.
    2. Bevor Geld ausgegeben wird, stellt man die Frage, ob man nicht mit einer Cloud-basierten externen Lösung billiger wegkommt als mit einer eigenen.

    1. und 2. sind angesichts einer immer noch angespannten Wirtschaftslage und besonders vor dem Hintergrund ggf. gewünschter Flexibilität absolut legitim.

    3. Die Cisco-Strategie „viel hilft viel“ geht nicht auf. Aktuell existieren DREI unterschiedliche Systematiken für den Aufbau von RZ-Netzen. Die Erwartungen an Insieme waren sehr hoch. Es kann aber doch wohl nicht wahr sein, dass jetzt nach rund zwei Jahren das Ergebnis des Spinoffs ein – zugegebenermaßen eindrucksvoller – 40 G-Switch ist, den man dann mit irgendeiner mit viel Pipapo angekündigten anwendungs-orientierten Software betreiben soll. Drei neue Strategien und mehr als 1000 APIs in einem Jahr sind zu viel für die Entscheidungsträger in RZs, sie sitzen lieber aus, ob nicht eine 4. und 5. hinzukommt, bevor sie etwas kaufen. Das Problem scheint auch auf Cisco begrenzt zu sein, denn Juniper, Brocade und Exteme Networks haben das Problem nicht, die Ergebnisse lagen aktuell über den Erwartungen. Sie nerven ja auch nicht mit neuen Strategien im 2-Monats-Takt. Cisco ist momentan für meine Begriffe in einem Status wie IBM vor 25-30 Jahren. Für ein Problem bekam man bei IBM damals auch immer drei Antworten, je nachdem, wen man fragte war die Lösung (für das gleiche Problem !!!) eine Host-Erweiterung, ein System 6000 oder ein Token Ring. Wenn Cisco die Transformation zu einem Unternehmen mit klarer Service-Orientierung nicht schafft, bedarf es keines externen Feindes oder einer Entwicklung wie SDN um rasant in ernsthafte Probleme zu geraten. Ich schließe mich persönlich eher den Stimmen an, die sagen, dass Chambers ein Auslaufmodell ist.

    Ich habe schon oft erwähnt, dass die „billigen Standard-Switches“ zumindestens aktuell kein gangbarer Weg sind. Tatsache ist, dass diese ganzen Software-Träume nur funktionieren, wenn die Hardware erheblich mehr leistet als jetzt. Das sieht man genau bei der Chip-Entwicklung. Diese Differenzierung wird es immer geben und sie wird in Zukunft sogar noch zu wesentlich mehr Varianten führen. Beispiele sind vor allem Offloads komplexerer Funktionen wie Tunnelbildung, Sicherheitsfunktionen, VM-Migration oder IPv6-Support. Wenn das nicht in Hardware vorhanden ist, wird SDN Software mit der wünschenswerten Geschwindigkeit einer Weinbergschnecke vor sich hin arbeiten.

    Die Herbeizitierung eines Problems der Netzwerk-Hersteller durch VMware halte ich für verfehlt, es wird nicht besser durch laufende Wiederholung. Ein RZ-Betreiber wäre mit dem Klammerbeutel gepudert, wenn er sich in Abhängigkeit von nur einem Hersteller von Virtualisierungssoftware begibt. Netz und Server-Software waren 30 Jahre getrennt. Das sollte auch weiterhin so bleiben.

    Hinsichtlich der Sicherheitsproblematik stimme ich meinem Vorkommentator zu.

  3. beier schreibt:

    Sehr geehrter Dr. Suppan,

    bitte mal z.B. im Comer nachlesen, wie der IP Routing Algorithmus in der Realität abläuft; kleiner Tipp: das Paket wird nicht nur weitergeleitet, sondern auch dessen Header verändert. Wenn man das nicht macht, kommt man in Teufelsküche.

    schöne Grüße,

    Eddie Beier

  4. beier schreibt:

    …und spätestens ab Layer 4 wird es dann „stateful“. Ich habe noch keine OpenFlow Spec gesehen, die irgendwas in dieser Richtung macht. Auch z.B. der vSwitch ist absichtlich komplett „stateless“. Die White Boxes bestehen nur aus schnellen, relativ dummen Broadcom Chips, die können nicht „stateful“.

    schönes WE,

    Eddie Beier

    • Cornelius Höchel-Winter schreibt:

      Nicht nur virt. Switche sondern alle heutigen Switche arbeiten stateless. Noch nicht einmal Router arbeiten stateful. Das kommt erst dann zum Tragen, wenn Sie Security machen wollen.
      Die Frage ist also, ob Sie mit einem SDN-Switch Firewall spielen wollen. Dann muss der SDN-Switch dazu in der Lage sein, Statusinformationen, also Beginn und Ende eines Flows, zu erkennen und zum Controller zu übertragen. Ob hierzu OpenFlow tatsächlich das richtige Protokoll ist, würde ich im Moment auch in Frage stellen. Aber OpenFlow ist nicht die einige Möglichkeit, um SDN umzusetzen!

      • beier schreibt:

        Hallo Hr. Höchel-Winter,

        nach meinem SDN Verständnis:
        – Firewall ist ein Beispiel für eine virtualisierte Netzfunktionen (VNF)
        – NFV (Network Functons Virtualisation) ist Teil eine SDN Strategie und beinhaltet auch z.B. Lizenzmamagement und das Ausrollen von VNFs
        – VNFs laufen als VMs im Cluster auf x86 Basis

        schöne Grüße aus Nürnberg,

        Eddie Beier

  5. Dr. Jürgen Suppan schreibt:

    Hallo Herr Beier,

    mein Verständnis von SDN ist, dass auch Inhalt in Form einer action verändert werden kann und auch je nach Protokoll muss. Dafür muss der ASIC eine mehrstufige Bearbeitung unterstützen, was soweit ich das sehe alle speziell für SDN entworfenen ASCIs auch machen. Wenn Sie da eine andere Information haben, wäre ich für eine weitere Rückmeldung dankbar, da dies ist absolut elementare Frage ist. Mit Bezug auf Comer (den ich sehr schätze) ist meine Sichtweise, dass alle Algorithmen eine Neuprogrammierung erfordern. Die große Frage ist dabei, ob man zwingend das bestehende nachprogrammiert oder einfach die neue Ausgangslage nutzt und Algorithmen neu definiert. Das läuft in die komplexe Frage der Migration mit einer möglichen Koexistenz beider Welten rein.

    Viele Grüße
    Dr. Jürgen Suppan

    • beier schreibt:

      ….ich glaube, mit IPv8 warten wir noch ein bisschen. Nachdem sich das v4 ja als extrem hartnäckig erwiesen hat und Alle sehr viel Mühe verwenden, auf v6 zu migrieren, wird man sich damit keine Freunde machen….

      schöne Grüße

      Eddie Beier

  6. Dr. Kauffels schreibt:

    Ich habe in meiner Serie „Chip, Chip Hurra“ einige moderne Chips vorgestellt und man kann recht genau sehen, welche Eigenschaften sie haben. Es hat wohl nur kaum jemand gelesen. Ein Switch Chip hat schlicht nicht die Aufgabe, sich Zustände zu merken, sondern seine Aufgabe ist es, ein ankommendes Paket möglichst schnell wieder über den richtigen Port hinauszuwerfen. Alles andere ist Prozessoren vorbehalten, die in diesem Zusammenhang ebenfalls verbaut werden müssen. Sie können sich dann auch Zustände merken. Allerdings sehe ich eine ganz klare Tendenz, mit zunehmender Integrationsdichte auch Koprozessoren für Offloads direkt mit in der IC-Struktur zu verbauen. Je nach Aufgabe können diese natürlich auch Zustandsinformationen verarbeiten. Was mich an dem gesamten Open Flow ärgert, ist, dass die aktuelle Spezifikation einige JAHRE hinter den Fähigkeiten der aktuellen Chips ist, also für Open Flow sind alle Chips dumm wie Brot. Wahrscheinlich deswegen, weil die Erfnder von Open Flow als Software Kings wohl nichts von Chips verstehen. Besser ist schon die Spezifikation von Intel. Die Netzwerk-Hersteller, allen voran Cisco, nutzen natürlich jetzt fröhlich genau diese Lücke zwischen nur elementarer Standardisierung (mit Open Flow) und massiv anderen technischen Möglichkeiten (mit den Power-Chips) um die Eier ihrer proprietären Lösungen zur Brut auszulegen. Und aktuell klappt das auch ganz gut. Es besteht sogar eine gewisse positive Wahrschenlichkeit, dass aus dem ganzen SDN bezogen auf seine Grundideen nichts wird, weil die Standardisierung, die eigentlich benötigt wird, massiv hinterherhängt und somit die Hersteller völlig freie Bahn haben, um ihre proprietären Netzwerk-Betriebssysteme so aufzumotzen, dass sie nach außen hin wie „SDN“ aussehen, vielleicht gibt es ja gnädiger Weise sogar eine beschränkte Schnittstelle für Fremdsoftware. Es wird interessant sein, zu sehen, was Provider machen. Sie fürchten ja die Abhängigkeit von einem Hersteller wie der Teufel das Weihwasser und haben auch allen Grund dazu. Provider könnten SDN in ihrem Sinne vorantreiben. Dabei entstehen aber dann Lösungen, die der, sagen wir mal deutsche Mittelstandskunde, kaum brauchen können wird. Unterm Strich hat die SDN-Diskussion an der Börse bereits einen Milliarden-Schaden angerichtet, ohne in irgendeiner Weise an irgend einer Stelle wirklich nützlich geworden zu sein. Es ist natürlich auch ein Problem, dass jeder mit diskutiert, der die drei Buchstaben unfallfrei hintereinander setzen kann. Ich erwarte ehrlich gesagt, dass sich SDN als Blase herausstellt, die irgendwann einmal laut platzt. Wichtig wäre dann für einen Anwender nur, nicht grade dann mit im Regen zu stehen.

    • beier schreibt:

      Sehr geehrter Dr. Kauffels,

      – wenn sich ein Kunde in eine technologische Sackgasse begiebt, war er m.E. nicht gut beraten worden
      – Carrier Produkte, die dem Kunden nichts nützen, haben sicher keine Zukunft
      – das Problem bei vielen Standardisierungsgremien ist, dass es zu Viele gibt, die bremsen und zu Wenige, die die Sache voran bringen
      – Es stünde m.E. einem international tätigen Netzwerk-Beratungsunternehmen gut zu Gesicht, sich in der ONF zum Wohle seiner Kunden zu engagieren. Mitglied kann man da werden:
      https://www.opennetworking.org/index.php?option=com_content&view=category&layout=blog&id=18&Itemid=115&lang=en
      – da kann dann auch vorhandenes Chip-Knowhow gewinnbringend für Alle eingebracht werden.

      schöne Grüße

      Eddie Beier

      • Dr. Kauffels schreibt:

        Sehr geehrter Herr Beier

        Ich bin nicht sicher, dass die ONF Interessen der normalen überwiegend mittelständischen Betreiber oder Behörden, wie sie die Stammkundschaft der Veranstaltungen der ComConsult-Akademie bilden, vertreten würde. Wenn Sie sich die Gründungsmitglieder ansehen, werden sie überwiegend Provider finden. Und wie schon ausgeführt, ist SDN für diese ein spannendes Konzept. Ich gehe sogar so weit zu behaupten, dass verschiedene Mitglieder der ONF gar kein Interesse daran haben, dass private Unternehmensnetze besser werden, ganz im Gegenteil. Die Perspektive, den verzweifelten Unternehmen letztlich Cloud-Leistung verkaufen zu können, ist doch viel verlockender für die Provider. Das einzig Spannende an der ONF ist, dass hier verschiedene Unternehmen zusammen sitzen, die alle richtig Geld haben. Normalerweise bekommt am Ende derjenige den Standard, der über die längste Zeit die meisten Standardiseure und Standardiseusen zum Präsentieren, Nerven und Abstimmen in die Gremien schickt. Das hat nichts mit Wissenschaft oder der Suche nach einer wirklich optimalen Lösung zu tun. Normalerweise war das bei den Netzen eben Cisco, so wie früher Siemens bei Standards rund um das Telefon. Bei der ONF ist der Ausgang nicht klar. Sorry, das ich alles so schwarz und knochenhart sehe, das kommt einfach davon, dass ich seit über 30 Jahren dabei bin und seit über 25 Jahren keine Illusionen mehr habe.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.