Erstellen Sie das nächste NGINX-Erlebnis, konzipiert für die Realität moderner Apps

Als VP of Product bei NGINX spreche ich häufig mit Kunden und Benutzern. Egal, ob Sie ein Platform-Ops-Team, Kubernetes-Architekt, Anwendungsentwickler, CISO, CIO oder CTO sind – ich habe mit jemandem wie Ihnen gesprochen. In unseren Gesprächen haben Sie mir ehrlich Ihre Meinung zu NGINX mitgeteilt, einschließlich unserer Produkte, Preis- und Lizenzmodelle, und dabei sowohl unsere Stärken als auch unsere Schwächen hervorgehoben.

Unsere wichtigste Erkenntnis ist, dass unser Ansatz „NGINX ist der Mittelpunkt des Universums“ unseren Benutzern nicht dient. Wir hatten Produkte entwickelt, die darauf abzielten, NGINX zur „Plattform“ zu machen – der einheitlichen Verwaltungsebene für alles, was mit der Anwendungsbereitstellung zusammenhängt. Wir wussten, dass einige unserer früheren, auf dieses Ziel ausgerichteten Produkte nur wenig genutzt und übernommen wurden. Sie sagten uns, dass NGINX eine unternehmenskritische Komponente Ihrer vorhandenen Plattform sei (selbst entwickelt oder nicht), dass NGINX jedoch nicht die Plattform sei. Daher mussten wir eine bessere Integration mit den übrigen Komponenten vornehmen, um die Bereitstellung, Verwaltung und Sicherung unserer Produkte mit (und das ist wichtig) transparenten Preis- und Verbrauchsmodellen zu vereinfachen. Und natürlich alles über eine API möglich zu machen.

Die zugrunde liegende Botschaft war unkompliziert: Erleichtern Sie Ihnen die unvoreingenommene Integration von NGINX in Ihre Arbeitsabläufe, vorhandenen Toolchains und Prozesse. Wir haben Sie gehört. Im Jahr 2024 werden wir einen viel flexibleren, einfacheren, wiederholbareren und skalierbareren Ansatz für die Anwendungsfallkonfiguration und -verwaltung für Datenebene und Sicherheit verfolgen.

Ihr Wunsch ist durchaus verständlich. Ihre Welt hat sich verändert und verändert sich weiterhin! Sie haben verschiedene Phasen durchlaufen und sind von der Cloud über Hybrid- zu Multi-Cloud- und Multi-Cloud-Hybrid-Setups gewechselt. Darüber hinaus gab es Änderungen von VMs zu Kubernetes und von APIs zu Microservices und Serverless. Viele von Ihnen sind nach links gerückt und das hat zu Komplexität geführt. Mehr Teams verfügen über mehr Tools, die mehr Verwaltung, Beobachtbarkeit und robuste Sicherheit erfordern – all dies treibt Apps an, die innerhalb von Minuten skalierbar sein müssen – und nicht erst nach Stunden, Tagen oder Wochen. Und der neueste Beschleuniger, die künstliche Intelligenz (KI), übt erheblichen Druck auf veraltete Anwendungs- und Infrastrukturarchitekturen aus.

Was wir in den kommenden NGINX-Produktversionen ansprechen möchten

Während das Grundgerüst der NGINX-Produkte schon immer grundsolide, praxiserprobt und leistungsstark war, konnte die Art und Weise, wie unsere Benutzer alle Aspekte von NGINX nutzen, verwalten und beobachten konnten, nicht mit der Zeit Schritt halten. Mit der Einführung eines neuen Produkts und einer Reihe neuer Funktionen versuchen wir rasch Abhilfe zu schaffen. Weitere Informationen hierzu werden wir auf der F5-Konferenz AppWorld 2024 bekannt geben, die vom 6. bis 8. Februar stattfindet. Hier sind spezifische Schwachstellen, die wir in zukünftigen Produktversionen beheben möchten.

Schmerzpunkt Nr. 1: Moderne Apps sind aufgrund der Vielfalt der Bereitstellungsumgebungen eine Herausforderung bei der Verwaltung

Heute können CIOs und CTOs aus einer großen Vielfalt an Modalitäten für die Anwendungsbereitstellung wählen. Dies ist ein Segen, da es hinsichtlich Leistung, Fähigkeiten und Belastbarkeit eine viel größere Auswahl ermöglicht. Gleichzeitig ist es ein Fluch, denn Vielfalt führt zu Komplexität und Zersiedelung. Beispielsweise erfordert die Verwaltung von Anwendungen, die in AWS ausgeführt werden, andere Konfigurationen, Tools und Fachkenntnisse als die Verwaltung von Anwendungen in der Azure Cloud.

Während Container große Teile der Anwendungsbereitstellung standardisiert haben, bleibt alles unterhalb von Containern (oder was in Container hinein- und aus ihnen herausgeht) differenziert. Als De-facto-Container-Orchestrierungsplattform sollte Kubernetes diesen Prozess bereinigen. Aber jeder, der bereits Bereitstellungen auf Amazon EKS, Azure Kubernetes Service (AKS) und Google Kubernetes Engine (GKE) durchgeführt hat, kann Ihnen sagen, dass sie sich überhaupt nicht ähneln.

Sie haben uns mitgeteilt, dass die Verwaltung von NGINX-Produkten in dieser enormen Vielfalt von Umgebungen erhebliche Betriebsressourcen erfordert und zu Verschwendung führt. Und ehrlich gesagt brechen Preismodelle, die auf jährlichen Lizenzen basieren, in dynamischen Umgebungen zusammen, in denen Sie möglicherweise eine App in einer serverlosen Umgebung starten, sie in einer Kubernetes-Umgebung hochskalieren und eine kleine interne Bereitstellung in der Cloud für Entwicklungszwecke ausführen.

Schmerzpunkt Nr. 2: Apps, die in vielen Umgebungen und mit unterschiedlichen Lizenztypen ausgeführt werden, sind schwer zu sichern

Aufgrund der Komplexität unterschiedlicher Umgebungen ist es möglicherweise schwierig, zu ermitteln und zu überwachen, wo moderne Apps bereitgestellt werden, und anschließend die richtigen Sicherheitsmaßnahmen anzuwenden. Vielleicht haben Sie NGINX Plus als Ihren globalen Load Balancer und NGINX Open Source für verschiedene Microservices bereitgestellt, die jeweils in unterschiedlichen Clouds oder auf unterschiedlichen Anwendungstypen ausgeführt werden. Darüber hinaus können die Anforderungen hinsichtlich Privatsphäre, Datenschutz und Verkehrsmanagement unterschiedlich sein.
Jede Permutation fügt eine neue Sicherheitskomponente hinzu. Es gibt keine standardmäßige, umfassende Lösung, was die Betriebsabläufe komplexer macht und zu möglichen Konfigurationsfehlern führt. Zugegebenermaßen haben wir die Komplexität noch erhöht, indem wir Verwirrung darüber gestiftet haben, welche Arten von Sicherheit auf welche NGINX-Lösungen angewendet werden können.

Wir verstehen. Kunden benötigen eine einheitliche Lösung, um alle Anwendungen zu sichern, die NGINX nutzen. Diese einheitliche Sicherheitslösung muss die überwiegende Mehrheit der Anwendungsfälle abdecken und in allen Cloud-, On-Premise-, Serverless- und anderen Umgebungen dieselben Tools, Dashboards und Betriebsprozesse bereitstellen. Wir sind uns auch bewusst, wie wichtig es ist, zu einem intelligenteren Sicherheitsansatz überzugehen, indem wir die kollektive Intelligenz der NGINX-Community und den beispiellosen Überblick über den globalen Datenverkehr nutzen, über den wir glücklicherweise verfügen.

Schmerzpunkt Nr. 3: Die Kostenverwaltung für moderne Apps ist komplex und führt zu Verschwendung

In einer Shift-Left-Welt möchte jede Organisation Entwickler und Praktiker befähigen, ihre Arbeit besser zu erledigen, ohne ein Ticket einzureichen oder eine Slack-Nachricht zu senden. Die Realität sah anders aus. Eine gewisse marginale Abstraktion der Komplexität wurde durch Kubernetes, Serverless und andere Mechanismen zur Verwaltung verteilter Anwendungen und Anwendungen in lokalen, Cloud- und Multi-Cloud-Umgebungen erreicht. Dieser Fortschritt blieb jedoch größtenteils auf den Container und die Anwendung beschränkt. Die Übertragung auf die Anwendungsebenen wie Netzwerk, Sicherheit und Beobachtbarkeit sowie auf CI/CD funktionierte nicht gut.

Ich habe diese Probleme in den vorherigen Problempunkten bereits angedeutet, aber unter dem Strich lässt sich sagen: Komplexität hat einen hohen Preis, was Stunden und Mühe, beeinträchtigte Sicherheit und Belastbarkeit betrifft. Die Wartung zunehmend komplexer Systeme ist grundsätzlich anspruchsvoll und ressourcenintensiv. Ein weiterer unerfreulicher Aspekt ist die Komplexität von Preisen und Lizenzen. NGINX war nie ein „True-up“-Unternehmen, das seinen Benutzern die Schuld gibt, wenn sie versehentlich zu viel konsumieren.

Doch in einer Welt aus SaaS, APIs und Mikroservices möchten Sie nutzungsbasiert zahlen und nicht pro Jahr oder pro Arbeitsplatz oder Standortlizenz. Sie möchten ein leicht verständliches, verbrauchsbasiertes Preismodell für alle NGINX-Produkte und -Dienste über Ihre gesamte Technologieinfrastruktur und Ihr Anwendungsportfolio hinweg. Sie möchten außerdem Support und Sicherheit für alle von Ihren Teams ausgeführten Open Source-Module integrieren und dabei nur für die Teile bezahlen, die Sie benötigen.

Dies erfordert einige Änderungen bei der Verpackung und Preisgestaltung von Produkten durch NGINX. Die ultimative Lösung muss Einfachheit, Transparenz und ein Bezahlen nur für das sein, was Sie verbrauchen, genau wie bei jedem anderen SaaS. Wir hören Ihnen zu. Und wir haben etwas Großartiges auf Lager, das alle drei oben genannten Schwachstellen angeht.

Besuchen Sie uns auf der App World 2024

Wir werden auf der AppWorld 2024 über diese spannenden Updates sprechen und im Laufe der nächsten zwölf Monate Teile der Lösung als Teil unseres längerfristigen Plans und Fahrplans einführen.

Begleiten Sie mich auf dieser Reise und schalten Sie AppWorld ein, um eine vollständige Übersicht über das zu erhalten, was Sie erwartet. Frühbucherpreise sind bis zum 21. Januar verfügbar. Weitere Einzelheiten finden Sie auf der Registrierungsseite von AppWorld 2024 . Sie sind außerdem eingeladen, sich am Abend des 6. Februar den Leitern von NGINX und anderen Mitgliedern der Community im F5-Büro in San Jose anzuschließen und gemeinsam einen Blick auf die Zukunft von NGINX zu werfen, Community-Verbindungen aufzubauen und sich den Klassikern hinzugeben: Pizza und Swag! Informationen zur Registrierung und weitere Einzelheiten finden Sie auf der Veranstaltungsseite .

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