Bereits 2015 stellte ich fest: Software verschlang die IT. Diese Feststellung basierte auf Daten aus verschiedenen Branchenquellen, darunter RightScale, HBR, PWC und weitere. Von der Entwicklung über die Bereitstellung bis hin zur Auslieferung übernahm Software überall das Ruder.
Doch selbst damals war die Durchdringung des Netzwerks mit Software – auf der Produktionsseite – noch minimal. Die Anzeichen waren durchaus vorhanden, ebenso wie viele der benötigten Tools und APIs. Aber wenn die gesamte Pipeline ein Festmahl war, dann war die Entwicklung der Hauptgang und Bereitstellung und Auslieferung lediglich der Nachtisch.
Das war damals, heute sieht es anders aus. Und wir beobachten, dass Bereitstellung und Auslieferung inzwischen eines von drei Hauptgerichten auf der Speisekarte der Anwendungspipeline sind.
Die Daten? Sie stammen aus F5-Studien der vergangenen zwei Jahre. Die digitale Transformation gilt als treibende Kraft hinter all dieser Automatisierung und Veränderung, doch sollte man auch die disruptiven Auswirkungen der Public Cloud im Allgemeinen nicht außer Acht lassen.
Unabhängig davon, wem das Verdienst zukommt (oder ist es die Schuld?), dass sich das Blatt zugunsten von Software gewendet hat, lässt sich kaum bestreiten, dass Software die IT weiterhin verschlingt.
Entwicklung
Der Entwicklungsabschnitt der Anwendungspipeline war schon immer softwaregestützt. Wir nutzten Software, um die verschiedenen Bibliotheken und ausführbaren Dateien zu erstellen. Und wir nutzten Software zur Verwaltung verschiedener Codeversionen, lange bevor es Git gab oder CI/CD zu einem allgemein bekannten* Begriff wurde.
Was jedoch nicht immer automatisiert war, war der gesamte Umfang des Entwicklungsabschnitts. Automatisierte Tests, Konfigurationsmanagement und ereignisgesteuerte Build-Systeme waren nicht so weit verbreitet wie heute.
Dank Cloud und DevOps ist die Entwicklungsphase der Anwendungspipeline weitgehend zu einem Unterfangen geworden, bei dem „Software die Software erstellt“.
Bereitstellung
Cloud und DevOps gelten erneut als treibende Kräfte hinter dem Bedarf an stärkerer Automatisierung im Deployment-Bereich. Dieser Bereich „auf der anderen Seite der Produktionsgrenze“ wird von Betriebsteams dominiert, die das Deployment der Anwendungsinfrastruktur ebenso automatisieren wie Build- und Testprozesse. Das war nie das eigentliche Problem. Problematisch war vielmehr der „Rest der Pipeline“ – jener Teil, der aus der Netzwerkinfrastruktur bestand, die die Plattformen für die Anwendungsdienste bereitstellt, die zur Skalierung, Absicherung und Beschleunigung von Anwendungen erforderlich sind.
Genau dieser Abschnitt der Anwendungspipeline erlebt derzeit ein explosionsartiges Wachstum der Automatisierung, vorangetrieben von einer wachsenden Gruppe versierter Netzwerkingenieure, die wir als NetOps bezeichnen – eine Anlehnung an die DevOps-Bewegung, die die zur Automatisierung „des Netzwerks“ eingesetzten Werkzeuge, Techniken und Methoden maßgeblich beeinflusst hat und dies auch weiterhin tut.
In den vergangenen drei Jahren konnten wir enorme Fortschritte bei der Nutzung und Bedeutung der Automatisierung im Netzwerkbetrieb beobachten. Der Bereitstellungsabschnitt der Anwendungspipeline entwickelt sich zunehmend zu einem Vorhaben nach dem Prinzip „Software, die Software bereitstellt“.
Bereitstellung
Das Bereitstellungssegment der Anwendungspipeline dürfte den größten Umbruch von allen erfahren. Das liegt zum Teil daran, dass wir im Netzwerk seit zwanzig Jahren in erster Linie auf glänzende Hardware-Appliances setzen. Sie sind skalierbar, bieten die nötige Kapazität und sind insgesamt schneller als Software. Doch angesichts der unausweichlichen Entwicklung hin zu Multi-Cloud-Organisationen und der zunehmenden Akzeptanz der Public Cloud als Option selbst für die kritischsten Unternehmensanwendungen haben sich die Spielregeln geändert.
Hardware lässt sich nicht in die Cloud migrieren. Hardware ist nicht wirklich die richtige Plattform, um die anwendungsspezifischen Architekturen zu unterstützen, die für unveränderliche Infrastructure-as-Code-Ansätze bei der Bereitstellung erforderlich sind. Software lässt sich in die Cloud migrieren. Software unterstützt anwendungsspezifische Architekturen, Unveränderlichkeit und Infrastructure as Code.
Die Frage lautet eigentlich nicht Hardware oder Software (bei anwendungsspezifischen Cloud-Architekturen ist die Antwort eindeutig Software), sondern: Container oder virtuelle Software? Da Container sowohl Rechenzentren als auch Clouds rasch erobern, hat sich die Nachfrage nach in Containern bereitgestellten Anwendungsdiensten verdoppelt. Fairerweise muss man sagen, dass dieser Anstieg von etwa 4 % im Jahr 2017 auf 9 % im Jahr 2018 erfolgte. Dennoch ist das ein beachtlicher Sprung, auch wenn die Akzeptanz weiterhin im einstelligen Prozentbereich liegt.
Auch die Nachfrage nach virtueller Software ist deutlich gestiegen, während die Präferenz für Hardware von Jahr zu Jahr abnimmt. Wenn Sie nun glauben, dass sie jemals auf null sinken wird, verstehen Sie nicht wirklich, warum wir ursprünglich von Software zu Hardware gewechselt sind (ja, diesen Weg sind wir schon einmal gegangen) und warum ein Teil des Bereitstellungssegments (das gemeinsam genutzte Kernnetzwerk) in Unternehmen wahrscheinlich immer weitgehend hardwarebasiert bleiben wird.
Der Großteil des Bereitstellungssegments wird jedoch softwarebasiert sein. Das ist bereits so. Und zwar schon seit einiger Zeit. Nur so lassen sich die Hürden bei der Migration in die und aus der Public Cloud abbauen und die zunehmenden Konflikte zwischen herkömmlichen Bereitstellungsplänen und bedarfsgesteuerten Zeitplänen für die Anwendungsbereitstellung bewältigen. Container und virtuelle Software werden mindestens zwei Drittel des Segments für die Anwendungsbereitstellung ausmachen – sowohl On-Premises als auch in der Public Cloud.
Das Bereitstellungssegment entwickelt sich zu einem Bereich, in dem „Software die Software bereitstellt, die wiederum Software bereitstellt und absichert“.
Das liegt daran, dass Software die IT nach wie vor verschlingt und dies auch in absehbarer Zukunft weiterhin tun wird.
*Wenn Ihr Haushalt hauptsächlich aus Entwicklern besteht (wie meiner), dann ist CI/CD bei Ihnen ein geläufiger Begriff. Ihre Erfahrungen können abweichen.
Über den Autor
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Ähnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...