Unser Verständnis von Technologie und ihrer Funktionsweise befindet sich in vielerlei Hinsicht in einem grundlegenden Wandel. Um herauszufinden, wie Unternehmen mit diesen Veränderungen umgehen, hat F5 gemeinsam mit SlashData, einem führenden, auf Technologie spezialisierten Marktforschungsunternehmen, Hunderte von Führungskräften und Fachleuten aus den Bereichen IT, Sicherheit und Softwareentwicklung in verschiedenen Branchen und Regionen weltweit befragt.
Zu den Teilnehmenden gehörten Nutzer von NGINX-Open-Source-Projekten, NGINX Open Source und kommerziellen F5-NGINX-Produkten. Unsere Erkenntnisse bestätigten die Dringlichkeit, mit der Unternehmen sofortige Veränderungen in den Bereichen Containerisierung, Sicherheit, Entwicklerplattformen und KI anstreben. Nachfolgend finden Sie die wichtigsten Ergebnisse unserer jährlichen NGINX-Umfrage 2025.
Neue Trends: Die agentenbasierte Zukunft jenseits der CPU
F5 NGINX hat sich als bevorzugter Standardzugang für KI-Infrastrukturen etabliert. Führende Anbieter von KI-Hardware und -Software setzen es als primären oder empfohlenen Reverse-Proxy und Delivery Controller für KI-Anwendungen ein. Die Umfrageergebnisse zeigen, dass sowohl NGINX-Nutzer als auch die breitere Application-Delivery-Community einer KI-gestützten Zukunft mit großer Dynamik entgegengehen.
Nutzung von KI-Agenten: Auf die Frage nach ihrem Einsatz agentenbasierter KI für bestimmte Aufgaben (siehe Abbildung 1) gaben die Befragten an, dass „Konfiguration von NGINX“ mit 25 % derzeit am häufigsten genutzt wird, dicht gefolgt von „Optimierung des Netzwerkverkehrs und Lastverteilung“ mit 24 %. „Bereitstellung und Skalierung der Infrastruktur“ sowie „Behebung von Sicherheitslücken“ werden derzeit von 23 % der Befragten genutzt.
Kombinierte Nutzung: Fasst man die Antworten der Befragten zusammen, die agentenbasierte KI derzeit einsetzen oder damit experimentieren, liegt „Protokollanalyse und proaktive Fehlerbehebung“ mit 48 % an der Spitze. „Konfiguration von NGINX“ und „Bereitstellung und Skalierung der Infrastruktur“ liegen mit jeweils 46 % gleichauf, gefolgt von „Optimierung des Netzwerkverkehrs“ mit 45 %.
Größtes zukünftiges Interesse: „Drift-Erkennung und -Korrektur“ stieß mit 33 % auf das größte zukünftige Interesse, gefolgt von „Überwachung von NGINX-Bereitstellungen“ mit 32 % und „Vorfallalarmierung und -Triage“ mit 31 %.
Spezialisierte Hardware: 25 % der Umfrageteilnehmenden führen Workloads auf GPUs, TPUs oder FPGAs aus – bemerkenswert für eine Infrastruktur, die traditionell auf allgemeine Rechenaufgaben ausgerichtet ist (siehe Abbildung 2). Wir gehen davon aus, dass dieser Anteil aufgrund mehrerer wichtiger Faktoren weiter steigen wird. Dazu zählen Fortschritte bei kleineren KI-Modellen, die einfachere Ausführung kleinerer KI-Modelle in Cloud-nativen Infrastrukturen wie Docker und bei Hyperscale-Cloud-Anbietern sowie die Auslagerung von Prozessen zur Anwendungsbereitstellung (z. B. Verschlüsselung und SSL-Offloading auf NPUs und FPGAs, KI-Inferenz auf GPUs und TPUs usw.).
Größte Hürden: Die Befragten nannten Sicherheitsbedenken (26 %) und mangelndes Vertrauen in die Genauigkeit (24 %) als die größten Hürden für die Integration von KI. Die Komplexität der Integration, Compliance- und regulatorische Einschränkungen sowie ein begrenztes Verständnis der Fähigkeiten von KI-Agenten lagen jeweils bei 17 %.
Cloud Native ist allgegenwärtig, bleibt aber ein fortlaufender Prozess
Die Cloud-Native-Revolution gewinnt auch weit über ein Jahrzehnt nach ihrem Auftakt mit Containern und Kubernetes weiter an Dynamik. Bei zentralen Cloud-Native-Elementen ist trotz nahezu flächendeckender Akzeptanz eine vollständige Durchdringung noch lange nicht erreicht (siehe Abbildung 3).
Konkret ergab unsere Umfrage Folgendes:
- Die Realität mit mehreren Umgebungen ist wirklich da: 66 % der Unternehmen nutzen mindestens eine Cloud-Option, doch bei den Bereitstellungsorten liegt die lokale Infrastruktur mit 39 % weiterhin vor der Public Cloud mit 38 % und hybriden Umgebungen mit 36 %. Dies spiegelt die komplexe, verteilte Natur moderner Infrastrukturen wider und nicht einfach nur eine Geschichte der „Cloud-Migration“.
- Bei der Einführung von Containern besteht noch viel Potenzial: Nur 42 % der Befragten führen Workloads in Containern aus, und der Anteil der Microservices-Nutzung liegt bei lediglich 31 %. Virtuelle Maschinen dominieren mit 60 %, was darauf hindeutet, dass sich viele Unternehmen noch in einer frühen Phase der Cloud-nativen Transformation befinden.
- Kubernetes-Fragmentierung: Während Kubernetes (selbstverwaltet) bei der Container-Orchestrierung mit 24 % führend ist, erreicht Red Hat OpenShift insgesamt einen Anteil von 21 % (selbst- und vollständig verwaltet). Gleichzeitig verzeichnen verwaltete Dienste von Amazon Web Services (21 %), Microsoft Azure (17 %) und Google Cloud Platform (17 %) eine erhebliche Nachfrage.
Die Lücke beim Sicherheitsmanagement von APIs und Microservices ist enorm
Im Laufe des vergangenen Jahrzehnts sind viele Technologieunternehmen dazu übergegangen, APIs als zentralen Verbindungsmechanismus für interne und externe Abläufe einzusetzen. In Cloud-nativen Architekturen ist API-First ein zentrales Designprinzip. Dementsprechend setzen 86 % der Befragten API-Gateways ein, um ihre API-Infrastrukturen zu verwalten (siehe Abbildung 4).
Trotz dieser weitverbreiteten Verlagerung hin zu APIs und der starken Verbreitung von API-Gateways sind die API-Sicherheitspraktiken in den meisten Unternehmen noch unausgereift (siehe Abbildung 5). Während 86 % der Unternehmen APIs nutzen, haben nur 34 % API-Sicherheitsmaßnahmen implementiert. Dies stellt eine massive Schwachstelle in modernen Anwendungsinfrastrukturen dar.
Weniger als die Hälfte der Befragten konzentriert sich auf die Analyse des API-Datenverkehrs (43 %) und die Observability (38 %), zwei weitere Kernelemente der API-Sicherheit. Diese Lücke deutet wahrscheinlich auf Herausforderungen bei der übergreifenden Überwachung und Verwaltung von APIs hin. Tatsächlich verwenden 23 % der Befragten in verschiedenen Teams unterschiedliche Ansätze für das API-Management. Diese Fragmentierung ist vermutlich darauf zurückzuführen, dass es schwierig ist, die gesamte Organisation auf den klassischen „Golden Path“ für das API-Management zu bringen.
Platform Engineering hat sich weiterentwickelt, ist aber noch nicht ausgereift
Platform Engineering ist als Schlagwort im Mainstream angekommen. Tatsächlich haben 65 % der Befragten damit begonnen, Kompetenzen und Verantwortlichkeiten im Bereich Platform Engineering zu etablieren (siehe Abbildung 6). Dies reicht von großen Unternehmen mit eigenen Plattformteams bis hin zu einzelnen Teammitgliedern, die als Platform-Engineering-Verantwortliche fungieren. Rund 27 % verfügen über kleine, dedizierte Platform-Engineering-Teams, und in 21 % der Unternehmen gibt es innerhalb der Entwicklungs- bzw. Betriebsteams einzelne Rollen für Platform Engineering. Weitere 13 % der Unternehmen verfügen über große, dedizierte Platform-Engineering-Teams. Das Nutzenversprechen von Platform Engineering hat sich also eindeutig verbreitet und etabliert.
Allerdings zeigen die Antworten auf Fragen zu den Herausforderungen von Plattformen bei allen Teamgrößen, dass es in der Anfangsphase Schwierigkeiten gibt. Nur 20 % der Befragten gaben an, vor keinen nennenswerten Herausforderungen zu stehen. Die übrigen Befragten berichteten von einer Vielzahl von Herausforderungen im Bereich Platform Engineering, die sich aktiv auf ihre Unternehmen auswirkten. Dazu gehörten Probleme mit Sicherheit und Compliance (18 %), die Pflege der Dokumentation (16 %), die Aktualisierung der Technologie (16 %) und Ressourcenengpässe (14 %).
Die Umfrage zeigte deutliche Unterschiede zwischen größeren und kleineren Teams hinsichtlich ihrer Prioritäten bei der Bereitstellung von Services und ihrem Nutzenversprechen. Wenig überraschend konzentrierten sich größere Teams auf anspruchsvollere Bereiche, während kleinere Teams in ihrer Ausrichtung eher dem traditionellen DevOps-Ansatz ähnelten. Große, dedizierte Plattform-Engineering-Teams bieten mit höherer Wahrscheinlichkeit anspruchsvolle Services wie Database as a Service (54 %), Observability (52 %), API-Management (51 %), die Konfiguration und Verwaltung von Firewalls (54 %) sowie Tools für CI/CD-Pipelines (50 %) an.
Mit Cloud, KI und APIs Schritt zu halten, ist nicht einfach
Unternehmen führen neue Technologien schneller ein, als sie sie verwalten können. Die Umfrage zeigt, dass Organisationen Container, APIs und Platform Engineering bereitwillig einsetzen möchten, derzeit jedoch nicht darauf vorbereitet sind, ihre entwickelten Lösungen abzusichern und zu betreiben. Das größte Versäumnis betrifft die API-Sicherheit. Fast jede Organisation nutzt APIs, doch zwei Dritteln fehlt ein grundlegender Schutz. Dies ist kein zukünftiges Risiko, sondern eine akute Schwachstelle, die bereits jetzt in Produktivsystemen besteht.
Unterdessen sind in bestimmten Bereichen echte Fortschritte zu verzeichnen. KI-Agenten stehen kurz davor, tatsächliche Infrastrukturaufgaben in großem Maßstab zu übernehmen – und nicht nur in Demos. GPUs und spezialisierte Prozessoren werden zum Standard. In den meisten Unternehmen gibt es inzwischen Platform-Engineering-Teams, auch wenn sie ihren genauen Auftrag noch definieren müssen.
Entscheidend ist jetzt eine disziplinierte Umsetzung. Unsere Empfehlungen? Führen Sie keine neuen Funktionen ein, solange Sie das Vorhandene nicht angemessen verwalten können. Standardisieren Sie Ihre Verfahren für API-Sicherheit und -Management. Schaffen Sie die nötige Observability, um Ihre Systeme zu verstehen. Übertragen Sie Plattformteams klare Verantwortlichkeiten und stellen Sie ihnen die erforderlichen Ressourcen zur Verfügung.
Die Technologie für den Aufbau einer modernen, effizienten Infrastruktur ist vorhanden. Jetzt ist es an der Zeit, die wenig glamouröse, aber notwendige Arbeit zu leisten, um sie sicher und nachhaltig zu gestalten.
Weitere Informationen zu den Produkten von F5 NGINX finden Sie auf unserer Webseite.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.