Wegwerfinfrastruktur für Wegwerf-Apps

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Konferenzprogramme. Orientierung auf Veranstaltungen. Konkrete Aufgaben, wie der Kauf eines Hauses oder die Aufnahme eines Autokredits.

Wenn Sie für einen dieser Zwecke eine App installiert haben, dann haben Sie eine sogenannte „Disposable Mobile App“ (DMA) installiert. Diese Apps sind für einen einzigen Anwendungsfall konzipiert und sollen anschließend wie Broschüren „weggeworfen“, also gelöscht werden, bis sie wieder benötigt werden. Solche Apps sind zwangsläufig klein, agil und äußerst kurzlebig. Manchmal existieren sie nur für kurze Zeit – etwa zur Unterstützung einer Veranstaltung wie einer Wahl, der Fußball-Weltmeisterschaft oder eines Musikfestivals. In anderen Fällen bleiben sie serverseitig lange bestehen, jedoch nicht auf dem Endgerät, beispielsweise als Begleitung durch den Prozess einer Immobilienfinanzierung.

Diese Apps erfreuen sich zunehmender Beliebtheit und gelten als eine Art „Micro-App“ (die Microservices sehr ähnlich ist, jedoch für die Entwicklung durch Drittanbieter und nicht für die interne Entwicklung konzipiert wurde).

Der Grund, warum es wichtig ist, auf die Existenz solcher Apps hinzuweisen, liegt darin, dass sie sehr unterschiedliche Lebenszyklen haben können. Von ihrer Entstehung bis zu ihrem Ende existieren sie möglicherweise nur wenige Tage, Wochen oder Monate. Sie tauchen plötzlich auf und verschwinden ebenso schnell wieder. Meist sind sie kurzlebig, weshalb auch die sie unterstützende Infrastruktur wahrscheinlich nur vorübergehend benötigt wird.

In einer Zeit virtualisierter Rechenzentren, in der Software die IT verschlingt, ist diese Vorstellung nicht mehr so verrückt, wie sie einst geklungen haben mag. Schließlich werfen wir keine Hardware im Wert von mehreren Tausend Dollar weg. Es sind lediglich ein paar Bits, die sich mit einem Druck auf die Eingabetaste mühelos bereitstellen und wieder entfernen lassen.

Das mag ausreichen, wenn Ihre einzige Sorge hinsichtlich der Infrastruktur einem Web-/App-Server gilt. Doch diese Anwendungen müssen skalierbar sein und benötigen Unterstützung bei der Performance (schließlich handelt es sich um mobile Apps, bei denen der Großteil der Verarbeitung serverseitig – also in der Cloud – erfolgt). Das wiederum erfordert mehrere Komponenten dessen, was gemeinhin als Netzwerkinfrastruktur gilt: Dienste für Lastverteilung, Caching und Optimierung. Folglich müssen auch diese „austauschbar“ sein. Sie müssen sich als Software (oder virtuell) bereitstellen lassen und über einen robusten Satz von APIs und Vorlagen verfügen, mit denen sie schnell provisioniert, konfiguriert und später wieder entfernt werden können. Außerdem müssen sie Cloud-fähig, Cloud-aktiviert oder „cloudifiziert“ sein (je nachdem, welchen Marketingbegriff Sie bevorzugen), damit die Infrastruktur und die Dienste, die diese austauschbaren Apps unterstützen, ebenso flexibel und austauschbar sind wie die Anwendungen, die sie bereitstellen.

Das bedeutet auch, dass ein DevOps-Ansatz für die Verwaltung dieser äußerst dynamischen Umgebungen immer wichtiger wird, in denen deutlich mehr Apps in kürzeren Zyklen bereitgestellt und wieder verworfen werden. Ein einzelner, monolithischer Ansatz nach dem Motto „eine App für alle unsere Angebote“ entspricht nicht unbedingt der Art und Weise, wie kurzlebige mobile Apps konzipiert und bereitgestellt werden. Sie sind fokussiert und zweckgebunden, das heißt, sie stellen bestimmte Funktionen bereit, die niemals erweitert werden. Weitere Funktionen und Zwecke werden dann durch andere Apps abgedeckt. Dadurch steigt die Gesamtzahl der benötigten Anwendungen, und der IT-Betrieb gerät zusätzlich unter Druck, diese Apps bereitzustellen und auszuliefern. Jede dieser Apps verfügt über spezifische Dienste, Konfigurationen und Überwachungsanforderungen, die auf die jeweilige App zugeschnitten werden müssen. In der Welt der Anwendungen gibt es keine Universallösung. Das ist ein deutlicher Unterschied zu einer Welt, in der die Infrastrukturkonfiguration während der gesamten Lebensdauer einer App weitgehend unverändert bleiben kann, abgesehen von Anpassungen an Leistung oder Sicherheit. Für den IT-Betrieb, der die Infrastruktu

Deshalb wird es für die Infrastruktur immer wichtiger, nicht nur softwarebasiert oder virtualisiert zu sein und nicht nur eine robuste API für die Bereitstellung und Konfiguration anzubieten, sondern sich auch auf die Einbindung in die wachsenden Automatisierungsökosysteme beliebter Frameworks und Toolsets wie Puppet und Chef, VMware und Cisco, OpenStack und Salt Stack zu konzentrieren. Diese Frameworks ermöglichen es, dass Continuous Delivery aus der Entwicklung in den IT-Betrieb übergreift und schaffen die Voraussetzungen dafür, dass Infrastruktur ebenso einfach in Betrieb genommen wie außer Betrieb genommen werden kann.

Software verschlingt die IT, doch das sollte als etwas Positives betrachtet werden. DevOps als Ansatz für das Lebenszyklusmanagement über das gesamte Anwendungs- und Infrastrukturspektrum hinweg ist notwendig, um das Wachstum zu bewältigen, das dadurch entsteht, dass Software die Welt verschlingt. CA und Vanson Bourne haben in einer weltweiten Umfrage messbare Vorteile der Einführung eines DevOps-Ansatzes festgestellt: 21 % der Befragten gaben an, dass dadurch mehr neue Software und Dienste möglich seien, und 18 % verzeichneten eine kürzere Markteinführungszeit.

Diese Art von Agilität und Geschwindigkeit ist eine Grundvoraussetzung, wenn kurzlebige Apps und die für ihre Bereitstellung erforderliche kurzlebige Infrastruktur unterstützt werden sollen. Ein zentrales Problem für die IT besteht darin, dass das Netzwerk nach wie vor ein Hindernis darstellt. Laut einer EMA-Studie nannten 39 % der Unternehmen im Jahr 2014 „langsame manuelle Prozesse zur Neukonfiguration der Infrastruktur, um sie an Veränderungen anzupassen“ als erhebliches Problem.

Die Anwendung von DevOps auf „das Netzwerk“ wird dazu beitragen, diesen erheblichen Engpass auf dem Weg zur Produktivumgebung zu beseitigen. Dazu gehört auch, dass wir uns von unseren vorgefassten Meinungen über die Beschaffenheit des Netzwerks lösen (es ist Hardware! Es ist unantastbar! Dafür bin ich nicht zuständig!) und uns überlegen, welche Teile des Netzwerks sich dafür eignen, ebenso als kurzlebig behandelt zu werden wie die Anwendungen, die es bereitstellt.

Ü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