Die nächste NGINX Experience – entwickelt für die Anforderungen moderner Anwendungen

Eric Braun

Als VP of Product bei NGINX spreche ich regelmäßig mit Kunden und Anwendern. Ganz gleich, ob Sie Teil eines Platform-Ops-Teams, Kubernetes-Architekt, Anwendungsentwickler, CISO, CIO oder CTO sind – ich habe bereits mit jemandem wie Ihnen gesprochen. In unseren Gesprächen haben Sie mir offen Ihre Meinung zu NGINX mitgeteilt, unter anderem zu unseren Produkten, Preisen und Lizenzmodellen, und dabei sowohl unsere Stärken als auch unsere Schwächen hervorgehoben.

Unsere wichtigste Erkenntnis war, dass unser Ansatz „NGINX ist der Mittelpunkt des Universums“ den Anforderungen unserer Nutzer nicht gerecht wird. Wir hatten Produkte entwickelt, die NGINX zur „Plattform“ machen sollten – zur zentralen Verwaltungsebene für alles rund um die Anwendungsbereitstellung. Uns war bewusst, dass einige unserer früheren, auf dieses Ziel ausgerichteten Produkte nur wenig genutzt und angenommen wurden. Sie haben uns erklärt, dass NGINX zwar eine geschäftskritische Komponente Ihrer bestehenden Plattform ist – unabhängig davon, ob diese selbst entwickelt wurde oder nicht –, NGINX aber nicht die Plattform selbst darstellt. Daher mussten wir NGINX besser in Ihre übrigen Komponenten integrieren, um die Bereitstellung, Verwaltung und Absicherung unserer Produkte zu vereinfachen – mit transparenten Preis- und Nutzungsmodellen, und das ist wichtig. Und natürlich sollte all dies über eine API möglich sein.

Die zugrunde liegende Botschaft war eindeutig: Wir müssen es Ihnen erleichtern, NGINX ohne starre Vorgaben in Ihre Arbeitsabläufe, bestehenden Toolchains und Prozesse zu integrieren. Wir haben Ihnen zugehört. Im Jahr 2024 werden wir bei der Konfiguration und Verwaltung von Anwendungsfällen für die Datenebene und Sicherheit einen deutlich flexibleren, einfacheren, reproduzierbaren und skalierbareren Ansatz verfolgen.

Ihr Wunsch ist absolut nachvollziehbar. Ihre Welt hat sich verändert und verändert sich weiterhin! Sie haben verschiedene Phasen durchlaufen – von der Cloud über Hybrid- und Multi-Cloud-Umgebungen bis hin zu hybriden Multi-Cloud-Konfigurationen. Auch der Wechsel von VMs zu Kubernetes sowie von APIs zu Microservices und Serverless hat Veränderungen mit sich gebracht. Viele von Ihnen haben ihre Prozesse nach links verlagert, was zu mehr Komplexität geführt hat. Mehr Teams verfügen über mehr Tools, die einen höheren Verwaltungsaufwand, bessere Beobachtbarkeit und robuste Sicherheitsmaßnahmen erfordern – und all das für Anwendungen, die innerhalb von Minuten statt Stunden, Tagen oder Wochen skalierbar sein müssen. Der jüngste Beschleunigungsfaktor, künstliche Intelligenz (KI), setzt zudem herkömmliche Anwendungs- und Infrastrukturarchitekturen erheblich unter Druck.

Was wir in kommenden NGINX-Produktversionen angehen wollen

Obwohl das Fundament der NGINX-Produkte schon immer äußerst solide, praxiserprobt und leistungsfähig war, waren die Möglichkeiten, die unseren Benutzern zur Nutzung, Verwaltung und Überwachung sämtlicher Aspekte von NGINX zur Verfügung standen, nicht mehr zeitgemäß. Mit der Einführung eines neuen Produkts und zahlreichen neuen Funktionen arbeiten wir mit Hochdruck daran, dies zu ändern. Weitere Einzelheiten dazu werden wir auf der F5-Konferenz AppWorld 2024 bekannt geben, die vom 6. bis 8. Februar stattfindet. Im Folgenden finden Sie konkrete Herausforderungen, die wir in kommenden Produktversionen angehen möchten.

Problem Nr. 1: Moderne Anwendungen sind aufgrund der Vielfalt der Bereitstellungsumgebungen schwer zu verwalten

Heutzutage können CIOs und CTOs aus einer Vielzahl von Bereitstellungsmodellen für Anwendungen wählen. Das ist ein Segen, denn dadurch haben sie deutlich mehr Auswahl hinsichtlich Leistung, Funktionen und Ausfallsicherheit. Gleichzeitig ist es auch ein Fluch, da diese Vielfalt zu Komplexität und Wildwuchs führt. So erfordert beispielsweise die Verwaltung von Anwendungen, die in AWS ausgeführt werden, andere Konfigurationen, Tools und anderes internes Erfahrungswissen als die Verwaltung von Anwendungen in Azure Cloud.

Während Container große Teile der Anwendungsbereitstellung standardisiert haben, bestehen bei allem unterhalb der Container-Ebene (oder bei allem, was in Container hinein- oder aus ihnen herausgelangt) weiterhin Unterschiede. Als De-facto-Plattform für die Container-Orchestrierung sollte Kubernetes diesen Prozess vereinheitlichen. Doch jeder, der bereits Anwendungen auf Amazon EKS, Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE) bereitgestellt hat, kann bestätigen: Sie sind keineswegs gleich.

Sie haben uns mitgeteilt, dass die Verwaltung von NGINX-Produkten in dieser enormen Vielfalt an Umgebungen erhebliche betriebliche Ressourcen erfordert und zu Verschwendung führt. Und offen gesagt stoßen Preismodelle auf Basis von Jahreslizenzen in dynamischen Umgebungen an ihre Grenzen, wenn Sie beispielsweise eine Anwendung in einer serverlosen Umgebung starten, sie in einer Kubernetes-Umgebung skalieren und für Entwicklungszwecke eine kleine interne Bereitstellung in der Cloud betreiben.

Problem Nr. 2: Anwendungen, die in vielen Umgebungen ausgeführt werden und verschiedene Lizenztypen umfassen, sind schwer abzusichern

Die Komplexität heterogener Umgebungen kann es erschweren, zu ermitteln und zu überwachen, wo moderne Anwendungen bereitgestellt werden, und anschließend die richtigen Sicherheitsmaßnahmen anzuwenden. Vielleicht haben Sie NGINX Plus als globalen Load Balancer und NGINX Open Source für verschiedene Microservices bereitgestellt, die jeweils in unterschiedlichen Clouds oder auf verschiedenen Anwendungstypen ausgeführt werden. Darüber hinaus können für sie unterschiedliche Anforderungen an Privatsphäre, Datenschutz und Traffic-Management gelten.
Jede Konstellation bringt neue sicherheitsrelevante Aspekte mit sich. Es gibt keine umfassende Standardlösung, was die betriebliche Komplexität erhöht und potenzielle Konfigurationsfehler begünstigt. Zugegebenermaßen haben wir selbst zu dieser Komplexität beigetragen, da nicht klar ersichtlich ist, welche Sicherheitsarten auf welche NGINX-Lösungen angewendet werden können.

Wir verstehen das. Kunden benötigen eine einheitliche Möglichkeit, alle Anwendungen abzusichern, die NGINX nutzen. Diese einheitliche Sicherheitslösung muss die überwiegende Mehrheit der Anwendungsfälle abdecken und in allen Cloud-, On-Premises-, Serverless- und sonstigen Umgebungen dieselben Tools, Dashboards und Betriebsprozesse bereitstellen. Wir wissen auch, wie wichtig es ist, einen intelligenteren Sicherheitsansatz zu verfolgen, der die kollektive Intelligenz der NGINX-Community und den beispiellosen Einblick in den globalen Datenverkehr nutzt, über den wir glücklicherweise verfügen.

Problem Nr. 3: Das Kostenmanagement moderner Anwendungen ist komplex und führt zu Verschwendung

In einer Shift-Left-Welt möchte jedes Unternehmen Entwickler und Fachkräfte dazu befähigen, ihre Arbeit besser zu erledigen, ohne ein Ticket zu erstellen oder eine Slack-Nachricht zu senden. Die Realität sieht jedoch anders aus. Mit Kubernetes, Serverless und anderen Mechanismen zur Verwaltung verteilter Anwendungen sowie von Anwendungen, die sich über On-Premises-, Cloud- und Multi-Cloud-Umgebungen erstrecken, konnte die Komplexität in begrenztem Umfang abstrahiert werden. Diese Fortschritte beschränken sich jedoch weitgehend auf Container und Anwendungen. Auf die umliegenden Anwendungsebenen wie Netzwerk, Sicherheit und Observability sowie auf CI/CD ließen sie sich bislang kaum übertragen.

Ich habe diese Probleme bei den vorherigen Schwachstellen bereits angedeutet, doch unterm Strich gilt: Komplexität verursacht hohe Kosten in Form von Zeitaufwand und mühsamer Arbeit, beeinträchtigter Sicherheit und mangelnder Ausfallsicherheit. Die Wartung immer komplexerer Systeme ist grundsätzlich anspruchsvoll und ressourcenintensiv. Komplexe Preis- und Lizenzmodelle sorgen für zusätzlichen Unmut. NGINX war noch nie ein Unternehmen, das nachträgliche Lizenzabgleiche durchführt und Nutzer zur Kasse bittet, wenn sie versehentlich mehr als vereinbart nutzen.

Doch in einer Welt von SaaS, APIs und Microservices möchten Sie nutzungsabhängig bezahlen – nicht jährlich und auch nicht pro Benutzer oder Standortlizenz. Sie wünschen sich ein leicht verständliches, verbrauchsbasiertes Preismodell für alle NGINX-Produkte und -Services, das Ihre gesamte Technologieinfrastruktur und Ihr gesamtes Anwendungsportfolio abdeckt. Außerdem möchten Sie Support und Sicherheit für alle von Ihren Teams eingesetzten Open-Source-Module einbinden können und dabei nur für die Komponenten bezahlen, die Sie tatsächlich benötigen.

Dafür sind einige Änderungen an der Art und Weise erforderlich, wie NGINX seine Produkte bündelt und bepreist. Die optimale Lösung muss einfach und transparent sein und eine verbrauchsabhängige Abrechnung bieten – genau wie jede andere SaaS-Lösung. Wir haben Sie verstanden. Und wir haben etwas Großartiges in Vorbereitung, das alle drei oben genannten Probleme lösen wird.

Besuchen Sie uns auf der App World 2024

Wir werden auf der AppWorld 2024 über diese spannenden Neuerungen sprechen und in den kommenden zwölf Monaten im Rahmen unseres langfristigen Plans und unserer Roadmap schrittweise Teile der Lösung einführen.

Begleiten Sie mich auf dieser Reise und schalten Sie bei der AppWorld ein, um einen umfassenden Überblick über die kommenden Neuerungen zu erhalten. Frühbucherpreise sind bis zum 21. Januar verfügbar. Weitere Informationen finden Sie auf der Registrierungsseite für die AppWorld 2024. Außerdem sind Sie herzlich eingeladen, am Abend des 6. Februar gemeinsam mit Führungskräften von NGINX und anderen Mitgliedern der Community im F5-Büro in San Jose einen Blick in die Zukunft von NGINX zu werfen, Kontakte innerhalb der Community zu knüpfen und die Klassiker zu genießen: Pizza und Werbegeschenke! Informationen zur Anmeldung und weitere Einzelheiten finden Sie auf der Veranstaltungsseite.

Wir hoffen, Sie nächsten Monat in San Jose zu sehen!

Über den Autor

Eric Braun

Weitere Blogbeiträge von Eric Braun