Software frisst immer noch IT: Der nächste Kurs sind Application

Schon 2015 habe ich festgestellt, dass die Software die IT auffrisst . Grundlage hierfür waren Daten aus verschiedenen Branchenquellen, darunter RightScale, HBR, PWC und andere. Von der Entwicklung über die Bereitstellung bis hin zur Auslieferung übernahm die Software überall die Führung.

Aber selbst dann war die Infiltration von Software in das Netzwerk – auf der Produktionsseite des Hauses – noch minimal. Oh, die Zeichen waren da und sogar viele der Tools und APIs, die wir brauchten. Doch während die Breite der Pipeline ein ausgefallenes Mahl darstellte, waren die Entwicklung die Hauptspeise und die Bereitstellung und Auslieferung lediglich der Nachtisch.

Das war damals, das ist heute. Und wir beobachten derzeit, dass Bereitstellung und Auslieferung nun zu den drei Hauptgerichten im Menü der Application gehören.

Die Daten? Ausgewählt aus der F5-Forschung der letzten zwei Jahre. Die digitale Transformation gilt als treibende Kraft hinter all dieser Automatisierung und all diesem Wandel, doch sollte man die disruptiven Auswirkungen der öffentlichen Cloud im Allgemeinen nicht übersehen.

Unabhängig davon, wer das Verdienst (oder die Schuld?) dafür trägt, dass sich die Waage zugunsten der Software verschoben hat, lässt sich nahezu nicht bestreiten, dass die Software immer noch die IT auffrisst.

Entwicklung

Das Entwicklungssegment der Application wurde schon immer von Software gesteuert. Wir haben Software zum Erstellen der verschiedenen Bibliotheken und ausführbaren Dateien verwendet. Wir haben Software zum Speichern von Codeversionen verwendet, lange bevor es Git gab oder CI/CD zu einem gängigen* Begriff wurde.

Was nicht immer automatisiert war, war die vollständige Abdeckung des Entwicklungssegments. Automatisiertes Test- und Konfigurationsmanagement sowie ereignisgesteuerte Build-Systeme waren damals noch nicht so weit verbreitet wie heute.

Dank Cloud und DevOps ist das Entwicklungssegment der Application weitgehend zu einem „Software, die die Software erstellt“-Unterfangen geworden.

Bereitstellung

Cloud und DevOps erhalten erneut die Führung, wenn es darum geht, den Bedarf an mehr Automatisierung im Bereitstellungssegment voranzutreiben. Dieses Segment „andere Seite der Produktionswand“ wird von Ops dominiert, die die Bereitstellung der App-Infrastruktur sowie die Build- und Testprozesse automatisieren. Das war nie wirklich das Problem. Das Problem sei der „Rest der Pipeline“. Der Teil der Pipeline, der aus der Netzwerkinfrastruktur bestand, die die Plattformen für die Application bereitstellte, die zum Skalieren, Sichern und Beschleunigen von Apps erforderlich sind.

Es ist dieses Segment der Application , das derzeit einen explosionsartigen Anstieg der Automatisierung durch eine wachsende Gruppe versierter Netzwerkingenieure erfährt, die wir als NetOps bezeichnen, in Anlehnung an die DevOps-Bewegung, die die Tools, Techniken und Methoden zur Automatisierung „des Netzwerks“ beeinflusst hat (und weiterhin beeinflusst).

Wir sehen, dass in den letzten drei Jahren hinsichtlich der Nutzung und Bedeutung der Automatisierung im Netzwerkbetrieb enorme Fortschritte erzielt wurden. Das Bereitstellungssegment der Application ist auf dem Weg, zu einer „Software, die die Software bereitstellt“-Unternehmung zu werden.

Lieferung

Das Bereitstellungssegment der Application wird voraussichtlich das störendste von allen sein. Das liegt teilweise daran, dass unser wichtigster Anlaufpunkt im Netzwerk seit zwanzig Jahren eine glänzende Eisenkiste ist. Sie sind skalierbar, verfügen über die Kapazität und sind insgesamt schneller als Software. Doch mit der Unvermeidlichkeit von Multi-Cloud-Organisationen und der Akzeptanz der öffentlichen Cloud als Option selbst für die kritischsten Applications haben sich die Spielregeln geändert.

Hardware wird nicht in die Cloud migriert. Hardware ist nicht wirklich die richtige Plattform, um die Pro-App-Architekturen zu unterstützen, die für die Umsetzung von Immutable-Infrastructure-as-Code-Ansätzen bei der Bereitstellung erforderlich sind. Software migriert in die Cloud. Die Software unterstützt Pro-App-Unterstützung, Unveränderlichkeit und Infrastruktur als Code.

Die Frage ist nicht wirklich, ob es sich um Hardware oder Software handelt (bei den Pro-App-Cloud-Architekturen ist die Antwort offensichtlich Software), sondern ob es sich um Container oder virtuelle Software handelt. Da Container zunehmend Rechenzentren und Clouds gleichermaßen beanspruchen, hat sich die Nachfrage nach in Containern bereitgestellten Application verdoppelt. Fairerweise muss man sagen, dass sich diese Zahl von etwa 4 % im Jahr 2017 auf 9 % im Jahr 2018 verdoppelt hat. Trotzdem handelt es sich um einen beträchtlichen Sprung, egal, ob die Akzeptanz einstellig ist oder nicht.

Auch die Nachfrage nach virtueller Software ist deutlich gestiegen, während die Präferenzen für Hardware im Jahresvergleich zurückgingen. Wenn Sie nun glauben, dass dieser Wert jemals auf Null sinken wird, dann verstehen Sie nicht wirklich, warum wir überhaupt von Software auf Hardware umgestiegen sind (ja, diesen Weg sind wir schon einmal gegangen) und warum ein Teil des Bereitstellungssegments (das zentrale, gemeinsam genutzte Netzwerk) in Unternehmen wahrscheinlich immer größtenteils aus Hardware bestehen wird.

Den größten Anteil am Liefersegment wird allerdings Software haben. Ist es bereits. Ist schon seit einiger Zeit so. Nur so können Sie die Reibungsverluste bei der Migration in die und aus der öffentlichen Cloud verringern und die zunehmenden Probleme herkömmlicher Bereitstellungspläne durch nachfragegesteuerte App-Bereitstellungspläne lösen. Container und virtuelle Software werden mindestens zwei Drittel des Application ausmachen – sowohl vor Ort als auch in der öffentlichen Cloud.

Das Bereitstellungssegment entwickelt sich zu einem Unterfangen, bei dem „Software die Software bereitstellt, die Software bereitstellt und sichert“.

Das liegt daran, dass die Software noch immer die IT auffrisst und dies auch in absehbarer Zukunft tun wird.

*Wenn in Ihrem Haushalt hauptsächlich Entwickler tätig sind (was bei mir der Fall ist), ist CI/CD ein allgemein bekannter Begriff. Ihre Anfrage kann abweichen.