In der Anfangszeit der Cloud, die noch gar nicht so lange zurückliegt, waren häufig Berichte über Wachstum und Akzeptanz zu lesen, in denen die beispiellose Marktdurchdringung der „Cloud“ angepriesen wurde, ohne zwischen ihren wichtigsten Modellen zu unterscheiden (falls Sie es vergessen haben: IaaS, PaaS und SaaS). Dadurch entstand der Eindruck, dass alle drei Modelle ein unglaubliches Wachstum verzeichneten und die Cloud, wie von einigen vorhergesagt, das Rechenzentrum, wie wir es kannten, verdrängen würde.
Spulen wir einige Jahre vor: Inzwischen liegen uns detailliertere Marktanalysen vor, die zeigen, dass der beeindruckende Aufstieg der Cloud vor allem auf den SaaS-Bereich zurückzuführen war. Denn die Verantwortlichen in den Fachabteilungen (LOB, Line of Business) erkannten die Vorteile des Wechsels von einem Modell, bei dem die IT für sie Standardsoftware implementiert, zu einem Modell, bei dem SaaS ihnen sofort das bietet, was sie benötigen. Das mit Abstand größte Wachstum im „Cloud“-Bereich ist bislang zweifellos auf die Verlagerung von Geschäftsprozessen aus der lokalen Infrastruktur in Anwendungen „in der Cloud“ zurückzuführen.
Bedenken Sie: „Bis 2018 werden 59 % aller Cloud-Workloads auf Software-as-a-Service (SaaS) entfallen, gegenüber 41 % im Jahr 2013. Cisco prognostiziert, dass bis 2018 28 % aller Cloud-Workloads auf Infrastructure-as-a-Service (IaaS) entfallen werden, gegenüber 44 % im Jahr 2013. 13 % aller Cloud-Workloads werden 2018 auf Platform-as-a-Service (PaaS) entfallen, gegenüber 15 % im Jahr 2013. Die folgende Grafik bietet eine vergleichende Analyse der Prognosen für IaaS, PaaS und SaaS für den Zeitraum von 2013 bis 2018.“ (http://softwarestrategiesblog.com/tag/idc-saas-forecasts/)
Wenn man ein Unternehmen also ganz allgemein fragt, ob es die „Cloud“ nutzt, lautet die Antwort wahrscheinlich ja. Das sagt jedoch nichts darüber aus, welche Art von Cloud es nutzt, und macht es daher nahezu unmöglich, vorherzusagen oder einzuschätzen, mit welchen Herausforderungen es infolge der Einführung konfrontiert sein könnte. Schließlich bringt jedes Cloud-Modell seine eigenen Herausforderungen mit sich. Einige davon betreffen alle Modelle – so kann etwa das Identitätsmanagement bei allen drei Modellen problematisch sein –, andere hingegen nicht: Die Sicherheit von Webanwendungen stellt vor allem bei in IaaS-Umgebungen bereitgestellten Anwendungen eine Herausforderung dar, nicht bei SaaS.
Im Grunde genommen ist der Begriff „Cloud“ ohne eine nähere Bestimmung also ziemlich bedeutungslos.
Dies gilt heute auch für SDN, wo verschiedene Modelle zum Einsatz kommen, die jeweils ihre eigenen architektonischen Anforderungen und damit auch Herausforderungen mit sich bringen.
Betrachten Sie diese Tirade meines Kollegen Nathan Pearce über die Einbeziehung von Overlay-Protokollen (VXLAN und NVGRE) in die Definition von SDN: Welches SDN-Protokoll ist das richtige für Sie?. Nathan weist zu Recht darauf hin, dass wir, wenn wir Overlay-Protokolle in die Definition von SDN aufnehmen, auch andere Kapselungsprotokolle als SDN bezeichnen müssen.
Das Problem besteht natürlich darin, dass SDN – ähnlich wie Cloud – unter der weit gefassten Einbeziehung verschiedener Modelle leidet. Da ist zum einen die traditionelle (oder klassische, wenn Sie so wollen) Definition, die auf OpenFlow basiert und ausschließlich das zustandslose Netzwerk (Schichten 2–4) umfasst. Zum anderen gibt es das Architekturmodell, das sich auf die Operationalisierung des Netzwerks konzentriert und die Programmierbarkeit von SDN aus der Perspektive der Automatisierung von Bereitstellung und Verwaltung betrachtet. Dies wird häufig allgemein als „Netzwerkmanagement und -orchestrierung“ (MANO) bezeichnet.
Dann gibt es noch ein Modell, das gewissermaßen eine Mischform darstellt und auf Programmierbarkeit setzt, 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, seine Routing-Entscheidungen und die Durchsetzung von Richtlinien auf Grundlage des Echtzeit-Datenverkehrs anzupassen. Treffender wird dies als „automatisierte Netzwerke“ bezeichnet.
Jedes dieser drei Modelle bringt seine eigenen Herausforderungen (aber auch Vorteile) mit sich. Und nichts hindert ein Unternehmen daran, diese Modelle miteinander zu kombinieren, um seine Ziele zu erreichen (ähnlich wie 82 % der Unternehmen eine Multi-Cloud-Strategie planen (RightScale, State of the Cloud 2015)). Tatsache ist jedoch: Wenn man jemanden fragt, ob er SDN einführt oder implementiert, und die Antwort „Ja“ lautet, weiß man noch lange nicht, was tatsächlich damit gemeint ist. Geht es um OpenFlow? OpenStack? OpenDaylight? Open-wir-haben-ein-paar-Skripte-zur-Netzwerkautomatisierung-geschrieben?
Die aktuellen Zahlen zur Einführung von SDN sind wenig ermutigend und reichen bei Weitem nicht an die Werte heran, die Cloud-Technologien in derselben Phase der Marktreife verzeichneten.
Angesichts der unterschiedlichen Definitionen ist es jedoch durchaus plausibel (und wahrscheinlich), dass es in Wirklichkeit nicht an Akzeptanz oder Interesse mangelt, sondern vielmehr an einer einheitlichen Definition.
Ich werde das mit einigen Daten untermauern, die zeigen, dass Unternehmen vielleicht nicht ausdrücklich sagen, dass sie SDN einsetzen (oder übrigens DevOps, das ebenfalls unter einer gewissen Definitionsmüdigkeit leidet), es aber wahrscheinlich dennoch tun.
In den Ergebnissen, die für unseren neuesten Bericht „State of Application Delivery“ zusammengestellt wurden (die Ausgabe 2016 wird nun ja 2016 erscheinen), fiel die Zahl der Antworten, die tatsächlich auf eine Nutzung von SDN hindeuteten, ziemlich ernüchternd aus – wenn man bedenkt, seit wie vielen Jahren SDN schon als das Maß aller Dinge gilt. Betrachtet man jedoch die Antworten zum Einsatz von Automatisierung und Skripting genauer, ergibt sich ein völlig anderes Bild: 67 % der Befragten verwenden mindestens ein Automatisierungstool oder -Framework; mehr als die Hälfte nutzt zwei oder mehr.
Und mit „Tool“ oder „Framework“ meine ich unter anderem 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 – also an jenen, bei denen Automatisierung und Orchestrierung im Mittelpunkt stehen, und nicht an der klassischen, auf OpenFlow basierenden Definition.
Aber wir (also diejenigen von uns, die die Umfrage erstellt haben) haben nicht nach jedem einzelnen SDN-Modell gefragt, sondern ganz allgemein nach „SDN“. Dadurch bleibt die Definition Auslegungssache – genauso wie der weit gefasste Oberbegriff „Cloud“ die Ergebnisse früher Umfragen zur Einführung dieser Technologie offen für Interpretationen ließ.
Wir müssen sorgfältiger damit umgehen, wie wir den Begriff SDN verwenden und was wir darunter verstehen. Umfasst er Overlay-Protokolle? Oder nicht? Sprechen wir von Netzwerkautomatisierung oder von der Automatisierung von Netzwerken? Oder konzentrieren wir uns auf klassische, OpenFlow-basierte Netzwerkmodelle?
Die Antwort auf diese Frage wird letztlich allen ein besseres Verständnis davon vermitteln, inwieweit SDN heute angenommen wird (oder auch nicht), und (hoffentlich) verhindern, dass meinen armen Kollegen der Kopf platzt, wenn jemand vorschlägt, Overlay-Protokolle ebenfalls unter „SDN“ zu fassen.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...