Wie die Cloud leidet auch SDN unter Definitionsmüdigkeit

In der Frühphase der Cloud-Geschichte, also vor noch gar nicht so langer Zeit, gab es häufig Berichte über Wachstum und Akzeptanz, die die beispiellose Marktdurchdringung der „Cloud“ anpriesen, ohne zwischen ihren primären Modellen zu unterscheiden (das sind, falls Sie es vergessen haben, IaaS, PaaS und SaaS). Es schien, als würden alle drei Modelle ein unglaubliches Wachstum verzeichnen und als würde die Cloud – wie von manchen vorhergesagt – das Rechenzentrum, so wie wir es kennen, verdrängen.

Spulen wir einige Jahre vor, und wir haben bessere Marktaufschlüsselungen gesehen, die darauf schließen lassen, dass der beeindruckende Aufstieg der Cloud hauptsächlich auf der SaaS-Seite der Welt stattfand, da LOB-Anteilseigner (Line of Business, Geschäftsbereiche) Vorteile in der Umstellung von einem Modell, bei dem die IT vorgefertigte Software für uns implementiert, zu einem Modell, bei dem SaaS uns gibt, was wir heute wollen, sahen. Das bislang größte Wachstum im Bereich „Cloud“ ist zweifellos auf die Verlagerung von Geschäftsabläufen von lokalen Standorten zu Anwendungen „in der Cloud“ zurückzuführen.

Bedenken Sie, dass „ bis 2018 59 % aller Cloud-Workloads Software-as-a-Service (SaaS)-Workloads sein werden; 2013 waren es nur 41 %.“ Cisco prognostiziert, dass bis 2018 28 % aller Cloud-Workloads Infrastructure-as-a-Service (IaaS)-Workloads sein werden (ein Rückgang gegenüber 44 % im Jahr 2013). 13 % aller Cloud-Workloads werden 2018 Platform-as-a-Service (PaaS)-Workloads sein (ein Rückgang gegenüber 15 % im Jahr 2013).  Die folgende Grafik bietet eine vergleichende Analyse der IaaS-, PaaS- und SaaS-Prognosen von 2013 bis 2018. “ ( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )

Wenn Sie also ein Unternehmen allgemein fragen, ob es die „Cloud“ einführt, wird die Wahrscheinlichkeit groß sein, dass Sie ein „Ja“ erhalten. Dies sagt nichts darüber aus, welche Art von Cloud sie einführen, und macht es daher nahezu unmöglich, vorherzusagen oder zu kommentieren, welche Herausforderungen sie aufgrund der Einführung bewältigen müssen. Schließlich bringt jedes Cloud-Modell seine eigenen Herausforderungen mit sich. Manche davon sind gleich (Identitätsmanagement kann bei allen drei Modellen ein Problem darstellen), andere hingegen nicht (die Sicherheit von Web-Anwendungen stellt vor allem bei IaaS-bereitgestellten Apps eine Herausforderung dar, nicht bei SaaS).

Im Grunde ist der Begriff „Cloud“ ohne eine entsprechende Qualifizierung ziemlich bedeutungslos.

Dies gilt heute auch für SDN, wo eine Vielzahl von Modellen im Spiel sind, jedes mit seinen eigenen einzigartigen Architekturanforderungen und damit Herausforderungen.

Betrachten Sie diese Schimpftirade meines Kollegen Nathan Pearce zur Einbeziehung von Overlay-Protokollen (VXLAN und NVGRE) in die Definition von SDN: Welches SDN-Protokoll ist das richtige für Sie ? Nathan schlägt zu Recht vor, dass wir, wenn wir Overlay-Protokolle in die Definition von SDN aufnehmen, auch andere Kapselungsprotokolle als SDN benennen müssen.

Das Problem besteht natürlich darin, dass SDN wie die Cloud unter der breiten Einbeziehung mehrerer Modelle leidet. Es gibt die traditionelle (oder klassische, wenn Sie das bevorzugen) Definition, die auf OpenFlow basiert und nur das zustandslose Netzwerk (Schichten 2-4) umfasst. Es gibt das Architekturmodell, das sich auf die Operationalisierung des Netzwerks konzentriert und den Programmierbarkeitsaspekt von SDN aus der Perspektive der Automatisierung von Bereitstellung und Verwaltung betrachtet. Dies wird oft allgemein als „Netzwerkmanagement und Orchestrierung“ (MANO) bezeichnet.

Dann gibt es das Modell, das eine Art Mix darstellt. Es basiert auf Programmierbarkeit, um ein automatisiertes Netzwerk über den gesamten Stack hinweg aufzubauen. Es umfasst alle sieben OSI-Schichten, konzentriert sich jedoch auf die Fähigkeit des Netzwerks, sein Routing und die Durchsetzung von Richtlinien basierend auf dem Echtzeitverkehr anzupassen.  Dies wird eher als „automatisierte Netzwerke“ bezeichnet.

Jedes dieser drei Modelle bringt seine eigenen Herausforderungen (und auch Vorteile) mit sich. Und nichts hindert ein Unternehmen daran, diese Modelle zu kombinieren, um seine Ziele zu erreichen (ähnlich wie 82 % der Unternehmen eine Multi-Cloud-Strategie planen (RightScale, State of the Cloud 2015)). Aber es bleibt die Tatsache: Wenn Sie jemanden fragen, ob er SDN einführt oder implementiert, und er mit „Ja“ antwortet, haben Sie in Wirklichkeit keine Ahnung, was er eigentlich tut. Ist es OpenFlow? OpenStack? Offenes Tageslicht? Öffnen-wir-haben-einige-Skripte-geschrieben-um-das-Netzwerk-zu-automatisieren?

Die aktuellen Statistiken zur Einführung von SDN sind nicht sehr inspirierend und sicherlich nicht annähernd so vielversprechend wie die Cloud, die sich in einem vergleichbaren Stadium der Marktreife befand.

Doch angesichts der unterschiedlichen Definitionen ist es durchaus plausibel (und wahrscheinlich), dass es nicht an mangelnder Akzeptanz oder mangelndem Interesse liegt, sondern vielmehr an einem Mangel an einer gemeinsamen Definition.

Ich werde dies mit einigen Daten untermauern, die besagen, dass Organisationen vielleicht nicht sagen, dass sie SDN (oder DevOps, was das betrifft, da es ebenfalls unter Definitionsmüdigkeit leidet) betreiben, es aber wahrscheinlich tun.

In den für unseren jüngsten Bericht „State of Application Delivery“ (2016, der, nun ja, 2016 verfügbar sein wird) zusammengestellten Ergebnissen war die Zahl der Antworten, die tatsächlich „SDN nutzen“, ziemlich düster, wenn man bedenkt, wie viele Jahre SDN schon „das Ding ist, das man machen muss“. Aber wenn man sich die Antworten zum Einsatz von Automatisierung und Skripting genauer ansieht, sieht das Ganze schon ganz anders aus: 67 % der Befragten verwenden mindestens ein Automatisierungstool oder -framework; über die Hälfte verwendet zwei oder mehr.

Und mit „Tool“ oder „Framework“ meine ich Python, Juju, Chef, Puppet, OpenStack, VMware und Cisco.

Die Verwendung solcher Frameworks und Tools deutet auf ein größeres Interesse an den beiden letztgenannten Definitionen von SDN hin – denjenigen, die sich auf Automatisierung und Orchestrierung konzentrieren – als an der klassischen OpenFlow-basierten Definition.

Aber wir (also diejenigen von uns, die die Umfrage zusammengestellt haben) haben nicht nach jedem einzelnen SDN-Modell gefragt; wir haben nach „SDN“ im Allgemeinen gefragt. Dadurch bleibt die Definition ebenso interpretierbar wie die Ergebnisse der Umfragen zur frühen Einführung des weit gefassten Oberbegriffs „Cloud“.

Wir müssen den Begriff SDN und seine Bedeutung sorgfältiger verwenden. Sind Overlay-Protokolle enthalten? Sind Overlay-Protokolle nicht enthalten? Sprechen wir über Netzwerkautomatisierung oder über die Automatisierung von Netzwerken? Oder konzentrieren wir uns auf klassische, OpenFlow-basierte Netzwerkmodelle?

Die Antwort auf diese Frage wird letztlich jedem ein besseres Verständnis dafür vermitteln, wie SDN heute angenommen wird (oder nicht), und wird (hoffentlich) verhindern, dass meinen armen Kollegen der Kopf platzt, wenn jemand vorschlägt, Overlay-Protokolle als „SDN“ aufzunehmen.