Application müssen Apps folgen, so wie sie Daten folgen.
Die Einführung der Cloud und mittlerweile auch von Containern hat die traditionelle Stovepipe-Netzwerkarchitektur, die jahrzehntelang das Design von Rechenzentren dominiert hat, auf den Kopf gestellt. Die Kontrolle über den Datenverkehr ist nicht mehr auf klar definierte Standorte in einer einzelnen Netzwerkarchitektur beschränkt. Mittlerweile sind sie über das Internet und das gesamte Rechenzentrum verteilt, da Container die Application immer weiter einschränken.
Diese Verteilung der Applications führt zu verheerenden Betriebsstörungen, da die Sichtbarkeit, Sicherheit und Leistung der Applications und der unterstützenden Infrastruktur durch die Kontrolle des Datenpfad nicht mehr gewährleistet werden kann.
Es ist klar, dass der traditionelle strategische Kontrollpunkt des Netzwerks gestört wird und mit ihm die Application , die lange Zeit dessen Existenz vorausgesetzt haben.
Seit Jahren werden diese Application auf Plattformen bereitgestellt, die als Application Delivery Controller bezeichnet werden. Der ADC wiederum hat sich auf Hardware verlassen, die die nötige Skalierbarkeit und Geschwindigkeit bietet, um die Leistungs- und Verfügbarkeitsanforderungen des Unternehmens zu erfüllen. Der ADC als Hardwarelösung wurde durch die Anforderung konkretisiert, die Last von Hunderten und Tausenden von Applications in einem einzigen Gerät bewältigen zu können. Diese Wahl wurde durch Applications diktiert, die an die Daten gebunden sind, für die sie die primäre Schnittstelle darstellen.
Application sind jedoch nicht an die Hardware gebunden, da es sich dabei schon immer um Software handelte und dies auch immer war. Der Vorteil speziell entwickelter Hardware lag schon immer in ihrer Fähigkeit, Leistung und Skalierbarkeit zu verbessern und im Vergleich zu Standardhardware um Größenordnungen bessere Ergebnisse zu erzielen.
So wie Application nicht an die Hardware gebunden sind, sind Applications auch nicht an das Rechenzentrum gebunden. Tatsächlich sind Applications stärker an ihre Daten gebunden. Wenn diese Daten verschoben werden, werden auch die Applications verschoben. Dieser Ursache-Wirkungs-Zusammenhang ist für die Zukunft der Application von entscheidender Bedeutung, da wir kurz davor stehen, mehr Daten zu generieren, als wir übertragen können. Laut Ciscos „ The Zettabyte Era“: Trends und Analysen “ werden wir bis 2021 60 Zettabyte (ZB) an Daten generieren. Unsere Kapazität zum Verschieben dieser Daten ist mit 3,3 ZB allerdings nach wie vor viel geringer. Aufgrund der Schwerkraft der Daten sind Applications zwangsläufig an die Umgebung gebunden, in der sich die Daten befinden. Diese Umgebung kann das Rechenzentrum sein, sie kann sich jedoch auch in der Cloud befinden.
Diese Kopplung von Applications an ihre Daten zeigt sich auch in einer ähnlichen Kopplung von Application an Applications. Wenn Applications sich verändern, müssen auch ihre Application verändert werden. Dies hat Auswirkungen auf den Datenpfad.
Architektur und Betriebsmodelle haben sich weiterentwickelt, um einen vorhersehbaren Datenpfad zu ermöglichen. Doch diese Vorhersehbarkeit ist jetzt nicht mehr gegeben. Für die Dienste, aus denen Cloud-basierte Applications bestehen, gilt keine vorgeschriebene Interkonnektivität.
Vernetzte Dienste müssen sich verändern.
Der einzelne, klar definierte Datenpfad und damit auch die strategischen Kontrollpunkte, an denen Application traditionell bereitgestellt wurden, sind verschwunden. Der Datenpfad ist jetzt variabel, dynamisch und verteilt. Es gibt mehr davon, da Cloud und Unternehmen anwendungsbezogene Ansätze für Entwicklung, Einsatz und Bereitstellung übernehmen. Application können jetzt überall entlang dieses Pfades eingefügt und ausgeführt werden.
Um den Applications folgen zu können, muss die Application ein Modell für Application übernehmen, das nicht auf das Rechenzentrumsnetzwerk beschränkt ist. Stattdessen muss das Unternehmen alternative Bereitstellungsstandorte und Betriebsmodelle in Betracht ziehen, die Cloud-native und servicebasierte Angebote umfassen.
Dieser Ansatz führt neue Optionen für das Einfügen und Bereitstellen von Application ein. Application können in die Application oder den Client eingefügt, aber innerhalb der Grenzen einer Cloud oder als Dienst ausgeführt werden. Sie können als Binärkomponenten in die Application integriert oder in Metadaten wie Tags eingeschlossen werden. Der Standort wird weniger wichtig als die Möglichkeit, den Applications zu folgen, während sie ihren Daten folgen.
Optionen sind Chancen
Es ist verlockend, diese Optionen als Bedrohung zu betrachten, da sie der Bereitstellung eines herkömmlichen ADC nicht förderlich sind. Sie stören die herkömmlichen Bereitstellungsarchitekturen von Natur aus und zwingen sowohl Anbieter als auch Application dazu, ihre Domänen über die komfortablen Grenzen des Netzwerks hinaus auszudehnen.
Doch es ist besser, diese Optionen als die Chancen zu sehen, die sie sind. Diese neuen Optionen bieten die Möglichkeit, neue Application und Betriebsmodelle zu nutzen, um weiterhin Application bereitzustellen und so sicherzustellen, dass Apps sicher, schnell und verfügbar sind.