Vergleich der Application : 2005 vs. 2015

James Ward, der Code schreibt (seine Beschreibung), hat vor Kurzem einen tollen Artikel geschrieben, in dem er die Application heute mit der von vor zehn Jahren verglichen hat . Eines der besser gehüteten Geheimnisse der IT-Branche insgesamt ist, dass Änderungen in der Application und -bereitstellung direkte Auswirkungen auf die Application haben (den eigentlichen Prozess, der sicherstellt, dass Applications schnell, sicher und für ihre Verbraucher verfügbar sind). Die Veränderungen, die heute beispielsweise durch Microservices bewirkt werden, sind insofern gravierend, als sie sowohl die Netzwerkarchitektur als auch das Bereitstellungsmodell verändern werden.

Ich weiß, ich weiß. Sie meinen, dass der Trend hin zu Mikroservices, Containerisierung und Cloud das Netzwerk abstrahiert und Applications dadurch weniger abhängig von ihnen werden. Und das stimmt, aus der Sicht der Entwickler und vielleicht sogar der Betriebsabteilung. Aber ein Netzwerk ist immer noch erforderlich; die ausgetauschten Daten müssen immer noch über diese Leitungen fließen und die im Netzwerk vorhandenen Dienste sind immer noch für viele Funktionen verantwortlich, die Apps schnell machen, ihre Sicherheit gewährleisten und ihre Verfügbarkeit sicherstellen . Änderungen hinsichtlich des Ortes und der Art und Weise, wie Applications zusammengestellt und bereitgestellt werden, wirken sich daher zwangsläufig auf diese Dienste aus, selbst wenn die Application nichts von ihrer Existenz weiß (und ehrlich gesagt, sie sollte es nicht einmal wissen). In dieser Hinsicht sind sie wie Schutzengel.)

Angesichts dieser Beziehung – auch wenn sie von der Application nicht erwidert wird – inspirierte James‘ Artikel einen parallelen Blick auf die Änderungen bei der Bereitstellung von Applications in den letzten zehn Jahren.

Bereitstellungsarchitektur

2005	2015
Conga-Linie	Plattform

Bereits 2005 implementierten Netzwerkteams (NetOps) die verschiedenen Application , die für die Bereitstellung von Applications erforderlich sind, in einer Art „Conga-Reihe“. Dabei handelte es sich um individuelle Punktlösungen. Wenn Sie etwas brauchten, um die App schneller zu machen, haben Sie ein Produkt zur Optimierung der Web-Performance auf einer eigenen, persönlichen, privaten Box bereitgestellt. Eine weitere Box für den Lastenausgleich, eine weitere für die App-Sicherheit und so weiter. Schließlich bildeten sich lange Schlangen mit vielen Kisten, die jeweils in beide Richtungen durchquert werden mussten. 

Im Jahr 2004 kamen Application Delivery Controller auf (die im Jahr 2005 jedoch noch sehr unausgereift waren) und begannen sich zu dem zu entwickeln, was wir heute haben, nämlich eine Plattform . Diese Plattformen bieten gemeinsame Funktionen und Verarbeitung und können mit Modulen (oder Plug-Ins oder Add-Ons oder wie auch immer Sie sie nennen möchten) erweitert werden. Der Plattformansatz reduziert die Zeit, die man „auf der Leitung“ verbringt, erheblich, ähnlich wie Containerisierung und Virtualisierung die Zeit verkürzen, die für die Reise zwischen Applications und Diensten benötigt wird. Darüber hinaus bietet es die Möglichkeit, die Betriebskosten durch die Nutzung einer gemeinsamen Grundlage – der Plattform – zu senken, die die Verwaltung der verschiedenen Application normalisiert, die heute zur Bereitstellung einer Application erforderlich sind.

Die Entwicklung vom Produkt zur Plattform ist vorteilhaft, da die Application in mehr verfügbare, zerlegte Architekturen übergeht und dabei aufkommende Technologien wie Container und Mikrodienste sowie die Bereitstellung in Cloud-Umgebungen nutzt, da diese für die Bereitstellung einer Vielzahl von Application oder nur eines einzigen unter Verwendung desselben standardisierten Kerns verwendet werden können. Dies bedeutet einen geringeren Verwaltungsaufwand, wenn sich der Platzbedarf der bereitgestellten Application erweitert, und die Möglichkeit, bei wachsender Applications Dienste nach Bedarf hinzuzufügen.

Bereitstellungsmethoden

2005	2015
Manuelle Bereitstellung	Programmierbare Bereitstellung

Im Jahr 2005 kamen webbasierte GUIs gerade erst in den Standardgebrauch und die primäre Methode zum Bereitstellen und Konfigurieren von Application war die CLI. Dieser Prozess war wie alle manuellen Prozesse zeitaufwändig und nahm mit zunehmender Komplexität der Application sogar noch mehr Zeit in Anspruch. Das Auftreten von Problemen aufgrund menschlicher Fehler und die daraus resultierenden Auswirkungen (die Anwesenheit im Netzwerk vergrößert den Explosionsradius einer Fehlkonfiguration exponentiell) führten dazu, dass die damalige Aufsicht noch länger dauerte. Kopieren und Einfügen war weit verbreitet, aber nicht narrensicher, und der Verwaltungsaufwand für die Verwaltung der Dienste war so erheblich, dass nur die wichtigeren Applications von den Vorteilen dieser Dienste profitieren konnten.

Schneller Vorlauf ins Jahr 2015 und zur DevOps-Revolution. Programmierbarkeit – sowohl in APIs als auch in vorlagenbasierten Konfigurationen – verändert alles, auch im Netzwerk. Application können jetzt über APIs mithilfe gängiger Frameworks wie Puppet und Chef automatisiert werden, mit Orchestrierungslösungen wie Cisco APIC und VMware NSX vorintegriert und individuell mit Python, Perl, Bash und Curl gesteuert werden. Application ermöglichen die Standardisierung und Wiederverwendung und fördern die Behandlung der Infrastruktur „als Code“, um kontinuierliche Bereitstellungsverfahren auf das Netzwerk auszuweiten.

Obwohl die Application bei der Application nicht so weit verbreitet ist wie die kontinuierliche Bereitstellung, hat sie sich weiterentwickelt (und entwickelt sich auch weiterhin weiter), um programmierbare Bereitstellungsoptionen zu unterstützen, die die Markteinführungszeit durch schnellere Bereitstellung von Diensten verkürzen und durch Automatisierung und Wiederverwendung die Betriebskosten senken.

Bereitstellungsformfaktoren

2005	2015
Großes Eisen	Virtualisiert

Im Jahr 2005 herrschte ein regelrechter Wettlauf um die Entwicklung größerer, besserer, schnellerer und leistungsfähigerer Netzwerkhardware. Steigende Ethernet-Geschwindigkeiten und eine explosionsartige Zunahme webbasierter Applications machten eine ergänzende Erweiterung der im Netzwerk eingesetzten Großhardware erforderlich, um die Anforderungen an Application zu unterstützen.

Heute liegt der Fokus auf Dichte und optimaler Ressourcennutzung. Damit sind Virtualisierung und Cloud Computing gemeint, die beide durch die Virtualisierung von Application unterstützt werden. Application können jetzt in Cloud-Umgebungen wie AWS, Microsoft Azure und Rackspace sowie in einer virtuellen Appliance eingesetzt werden, die entweder auf speziell entwickelter oder handelsüblicher Hardware bereitgestellt werden kann. Diese Fähigkeit ist nicht nur eine Voraussetzung für die Unterstützung von Cloud-Umgebungen, sondern auch für die Anpassung an neue Architekturen wie Microservices. Microservices und Server selbst sind heute, wie James Ward anmerkt, „wegwerfbar, unveränderlich und flüchtig….“

Dies bedeutet, dass viele der Application , die in den DevOps-Bereich verlagert werden – Lastausgleich, Application und Optimierung – die Kriterien für ein softwaredefiniertes Rechenzentrum erfüllen müssen. Sie müssen zumindest in der Lage sein, in ein unveränderliches, verfügbares Modell im großen Maßstab zu passen. Heute gibt es viele Plattformen zur Application , die in Kombination mit programmierbaren Implementierungsoptionen bereit sind, sich dieser Herausforderung zu stellen.

Bereitstellungsverantwortung

Im Jahr 2005 – und in vielen Organisationen auch heute noch – ist das Netzwerkteam vollständig für die Implementierung und Verwaltung der Application verantwortlich. Jeder Aspekt der Bereitstellung, von der Beschaffung über die Bereitstellung bis hin zur Konfiguration, wurde und wird häufig noch immer vom Netzwerkbetrieb übernommen. Dieses unzusammenhängende Modell führte zu Verzögerungen, da Anforderungen ausgearbeitet, Tickets erstellt und Ingenieure die zur Bereitstellung einer App erforderlichen Application manuell bereitgestellt und konfiguriert wurden.

Heute ist dies in vielen Organisationen noch der Fall, doch die Auswirkungen von Cloud und Microservices in Kombination mit der Einführung von DevOps ändern dies. Der Wunsch nach „IT as a Service“ ist groß und die Verantwortung für die Konfiguration der Application wird zunehmend auf Betriebs- oder sogar Entwicklungsteams verlagert. Es besteht die Notwendigkeit, dass application Dienste sowohl physisch als auch topologisch näher an der App angesiedelt werden. Dadurch liegt die Verantwortung für die Bereitstellung und Konfiguration dieser Dienste eindeutig bei DevOps.

Dies bedeutet jedoch nicht, dass das Netzwerkteam sich aus der Application zurückzieht. Es gibt einen erheblichen Anteil an Applications und Unternehmensanliegen, die Application erfordern, die auf traditionellere Weise bereitgestellt werden, wobei der Schwerpunkt eher auf Zuverlässigkeit als auf Agilität liegt. Diese Dienste liegen noch immer im Verantwortungsbereich des Netzwerkteams und werden dies wahrscheinlich auch bleiben. Andere jedoch liegen bereits in der Verantwortung von DevOps und werden dies auch weiterhin tun.

Die Application hat in den letzten zehn Jahren große Fortschritte gemacht. Es hat sich von einer Reihe von Produkten zu einer einheitlichen Plattform entwickelt, wurde programmierbar und wandelte sich von der Big Iron-Plattform zu einem System, das Hypervisoren und die Bereitstellung in der Cloud unterstützt. Da Applications , Microservices und DevOps die Art und Weise, wie Applications erstellt, implementiert und bereitgestellt werden, weiterhin radikal verändern, können wir mit einer kontinuierlichen Weiterentwicklung der Dienste rechnen, die diese Applications letztendlich bereitstellen und dafür sorgen, dass sie schnell, sicher und verfügbar bleiben.