Anwendungsbereitstellung im Vergleich: 2005 vs. 2015

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

James Ward, der Code schreibt (so seine eigene Beschreibung), hat kürzlich einen großartigen Artikel verfasst, in dem er die Anwendungsbereitstellung von heute mit der vor zehn Jahren verglich. Eines der besser gehüteten Geheimnisse der IT-Branche insgesamt ist, dass sich Änderungen an Anwendungsarchitekturen und Bereitstellungsverfahren direkt auf die Anwendungsauslieferung auswirken (also auf den eigentlichen Prozess, mit dem sichergestellt wird, dass Anwendungen schnell, sicher und für ihre Nutzer verfügbar sind). Die Veränderungen, die heute beispielsweise durch Microservices vorangetrieben werden, haben erhebliche Auswirkungen darauf, wie sie die Netzwerkarchitektur verändern werden – ebenso wie deren Bereitstellungsmodell.

Ich weiß, ich weiß. Sie denken jetzt, dass der Trend zu Microservices, Containerisierung und Cloud die Netzwerkebene abstrahiert und Anwendungen dadurch weniger davon abhängig macht. Und aus Sicht der Entwickler und vielleicht sogar des IT-Betriebs stimmt das auch. Dennoch ist weiterhin ein Netzwerk erforderlich: Die ausgetauschten Daten müssen nach wie vor durch diese Leitungen fließen, und die im Netzwerk angesiedelten Dienste sind weiterhin für viele Funktionen verantwortlich, die Anwendungen beschleunigen, schützen und ihre Verfügbarkeit gewährleisten. Änderungen daran, wo und wie Anwendungen zusammengestellt und bereitgestellt werden, wirken sich daher zwangsläufig auf diese Dienste aus – selbst wenn die Anwendung gar nichts von deren Existenz weiß (und ehrlich gesagt sollte sie das auch nie. In dieser Hinsicht sind sie wie Schutzengel.)

Angesichts dieser Beziehung – auch wenn sie von der Anwendung nicht erwidert wird – hat James’ Beitrag zu einer parallelen Betrachtung der Veränderungen angeregt, die sich in den vergangenen zehn Jahren bei der Bereitstellung von Anwendungen vollzogen haben.

Bereitstellungsarchitektur

2005	2015
Polonaise	Plattform

Im Jahr 2005 stellten Netzwerkteams (NetOps) die verschiedenen Anwendungsdienste, die für die Bereitstellung von Anwendungen erforderlich waren, in einer Architektur bereit, die wir gern als „Polonaise“ bezeichnen. Dabei handelte es sich um einzelne Punktlösungen. Wenn eine Anwendung beschleunigt werden sollte, wurde dafür ein Produkt zur Optimierung der Web-Performance auf einer eigenen, dedizierten Appliance bereitgestellt. Eine weitere Appliance übernahm den Lastausgleich, eine andere die Anwendungssicherheit und so weiter. So entstanden schließlich lange Ketten aus zahlreichen Appliances, die in beide Richtungen durchlaufen werden mussten.

Im Jahr 2004 kamen Application Delivery Controller auf (die 2005 allerdings noch sehr unausgereift waren) und entwickelten sich allmählich zu dem, was wir heute haben: einer Plattform. Diese Plattformen stellen gemeinsame Funktionen und Verarbeitungsressourcen bereit und lassen sich durch Module (oder Plug-ins, Add-ons oder wie auch immer man sie nennen möchte) erweitern. Der Plattformansatz verkürzt die Übertragungszeit im Netzwerk erheblich, ähnlich wie Containerisierung und Virtualisierung den Zeitaufwand für die Kommunikation zwischen Anwendungen und Diensten reduzieren. Zudem lassen sich damit die Betriebskosten senken, da eine gemeinsame Grundlage – die Plattform – genutzt wird, die die Verwaltung der verschiedenen Anwendungsdienste vereinheitlicht, die heute für die Bereitstellung einer Anwendung erforderlich sind.

Die Entwicklung vom Produkt zur Plattform ist von Vorteil, da sich die Anwendungsbereitstellung hin zu kurzlebigeren, modularen Architekturen verlagert, die neue Technologien wie Container und Microservices nutzen, und zunehmend in Cloud-Umgebungen erfolgt. Denn mit demselben standardisierten Kern lassen sich sowohl verschiedenste Anwendungsdienste als auch nur ein einzelner Dienst bereitstellen. Dadurch sinkt der Verwaltungsaufwand, wenn der Umfang der bereitgestellten Anwendungsdienste wächst. Zugleich können bei zunehmenden Anforderungen der Anwendungen bedarfsgerecht weitere Dienste hinzugefügt werden.

Bereitstellungsmethoden

2005	2015
Manuelle Bereitstellung	Programmierbare Bereitstellung

Im Jahr 2005 setzten sich webbasierte grafische Benutzeroberflächen gerade erst als Standard durch, und Anwendungsdienste wurden hauptsächlich über die Befehlszeilenschnittstelle bereitgestellt und konfiguriert. Dieser Prozess war wie alle manuellen Prozesse zeitaufwendig und nahm mit zunehmender Komplexität der Anwendungsdienste noch mehr Zeit in Anspruch. Da menschliche Fehler zu Problemen führen konnten und deren Auswirkungen erheblich waren – im Netzwerk vergrößert sich der Schadensradius einer Fehlkonfiguration exponentiell –, waren Kontrollen erforderlich, die zusätzlich Zeit kosteten. Kopieren und Einfügen war weit verbreitet, aber nicht narrensicher, und der Verwaltungsaufwand für die Dienste war so hoch, dass nur wichtigere Anwendungen von diesen Diensten profitieren konnten.

Zeitsprung ins Jahr 2015 und zur DevOps-Revolution. Programmierbarkeit – sowohl durch APIs als auch durch vorlagenbasierte Konfigurationen – verändert alles, selbst im Netzwerk. Anwendungsdienste lassen sich nun über APIs automatisieren: mithilfe gängiger Frameworks wie Puppet und Chef, durch vorintegrierte Orchestrierungslösungen wie Cisco APIC und VMware NSX oder individuell mit Python, Perl, bash und curl. Vorlagen für Anwendungsdienste ermöglichen Standardisierung und Wiederverwendung und fördern die Behandlung der Infrastruktur „als Code“, sodass sich Continuous-Delivery-Verfahren auch auf das Netzwerk ausweiten lassen.

Obwohl Continuous Delivery bei der Anwendungsbereitstellung noch nicht so weit verbreitet ist wie in der Anwendungsentwicklung, hat sie sich weiterentwickelt (und entwickelt sich auch weiterhin), um programmierbare Bereitstellungsoptionen zu unterstützen, die durch eine schnellere Servicebereitstellung die Markteinführungszeit verkürzen und zugleich durch Automatisierung und Wiederverwendung die Betriebskosten senken.

Bereitstellungsformen

2005	2015
Großrechner	Virtualisiert

Im Jahr 2005 setzte ein Wettlauf um größere, bessere, schnellere und leistungsfähigere Netzwerkhardware ein. Steigende Ethernet-Geschwindigkeiten und die explosionsartige Zunahme webbasierter Anwendungen machten einen entsprechenden Ausbau der im Netzwerk eingesetzten Großsysteme erforderlich, um die Anforderungen an Anwendungsdienste zu erfüllen.

Heute liegt der Schwerpunkt auf einer hohen Dichte und der optimalen Nutzung von Ressourcen. Das bedeutet Virtualisierung und Cloud-Computing, die beide durch die Virtualisierung von Plattformen zur Anwendungsbereitstellung unterstützt werden. Plattformen zur Anwendungsbereitstellung können heute sowohl in Cloud-Umgebungen wie AWS, Microsoft Azure und Rackspace als auch als virtuelle Appliance bereitgestellt werden, die sich auf speziell entwickelter oder handelsüblicher Hardware einsetzen lässt. Diese Fähigkeit ist nicht nur für die Unterstützung von Cloud-Umgebungen erforderlich, sondern auch für die Anpassung an neue Architekturen wie Microservices. Microservices und Server selbst sind heute, wie James Ward anmerkt, „austauschbar, unveränderlich und kurzlebig …“

Das bedeutet, dass viele der Anwendungsdienste, die in den DevOps-Bereich übergehen – Lastverteilung, Anwendungssicherheit und Optimierung –, die Kriterien für ein softwaredefiniertes Rechenzentrum erfüllen müssen. Sie müssen zumindest in der Lage sein, sich auch in großem Maßstab in ein unveränderliches, kurzlebiges Modell einzufügen. Viele Plattformen für die Anwendungsbereitstellung erfüllen diese Voraussetzungen bereits heute und sind in Kombination mit programmierbaren Bereitstellungsoptionen für diese Herausforderung gerüstet.

Bereitstellungsverantwortung

Im Jahr 2005 – und in vielen Unternehmen auch heute noch – war das Netzwerkteam allein für die Bereitstellung und Verwaltung der Anwendungsauslieferung verantwortlich. Jeder Aspekt der Auslieferung, 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 abgestimmt, Tickets erstellt und die für die Auslieferung einer Anwendung erforderlichen Anwendungsdienste von Technikern manuell bereitgestellt und konfiguriert werden mussten.

Auch heute ist dies in vielen Unternehmen noch der Fall, doch die Auswirkungen von Cloud und Microservices in Verbindung mit der Einführung von DevOps ändern diese Situation. Der Wunsch nach IT as a Service ist groß, wobei die Verantwortung für die Konfiguration von Anwendungsdiensten auf Betriebs- oder sogar Entwicklungsteams übergeht. Anwendungsnahe Dienste müssen sowohl physisch als auch topologisch näher an der Anwendung angesiedelt sein. Dadurch übernimmt DevOps eindeutig die Federführung und die Verantwortung für die Bereitstellung und Konfiguration dieser Dienste.

Das bedeutet nicht, dass das Netzwerkteam seine Hände bei der Anwendungsbereitstellung in Unschuld wäscht. Es gibt einen erheblichen Anteil an Anwendungen und Unternehmensanforderungen, die auf herkömmlichere Weise bereitgestellte Anwendungsdienste erfordern und bei denen Zuverlässigkeit statt Agilität im Vordergrund steht. Diese Dienste fallen nach wie vor in den Zuständigkeitsbereich des Netzwerkteams und werden dort wahrscheinlich auch bleiben. Andere hingegen gehen bereits in die Verantwortung von DevOps über und werden dies auch weiterhin tun.

Die Anwendungsbereitstellung hat sich in den vergangenen zehn Jahren stark weiterentwickelt. Aus einer Reihe einzelner Produkte wurde eine einheitliche Plattform, die programmierbar ist und sich von leistungsstarker Spezialhardware hin zur Unterstützung von Hypervisoren und Cloud-Bereitstellungen gewandelt hat. Da mobile Anwendungen, Microservices und DevOps die Entwicklung, Bereitstellung und Auslieferung von Anwendungen weiterhin grundlegend verändern, ist auch künftig mit einer kontinuierlichen Weiterentwicklung der Dienste zu rechnen, die diese Anwendungen letztlich bereitstellen und dafür sorgen, dass sie schnell, sicher und verfügbar bleiben.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

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