Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Rob WhiteleyGeschäftsführer der NGINX-Produktgruppe

Wie die Zeit vergeht, wenn man Spaß hat. Daher ist es kaum zu glauben, dass NGINX inzwischen 18 Jahre alt ist. Rückblickend haben die Community und das Unternehmen gemeinsam viel erreicht. Vor Kurzem haben wir einen bedeutenden Meilenstein erreicht – zum Zeitpunkt der Erstellung dieses Artikels werden 55,6 % aller Websites mit NGINX betrieben (entweder mit unserer eigenen Software oder mit Produkten, die auf NGINX basieren). Außerdem sind wir gemessen am Marktanteil der Webserver Nummer eins. Darauf sind wir sehr stolz, und wir sind Ihnen, der NGINX-Community, dankbar, dass Sie uns dieses überwältigende Vertrauen entgegenbringen.

Wir erkennen auch immer deutlicher, dass Open-Source-Software die Welt weiterhin verändert. Ein immer größerer Anteil der Anwendungen wird mithilfe von Open-Source-Code entwickelt. Von Bloomberg-Terminals und -Nachrichten über die Washington Post und Slack bis hin zu Airbnb, Instagram und Spotify verlassen sich Tausende der bekanntesten Marken und Angebote der Welt beim Betrieb ihrer Websites auf NGINX Open Source. In meinem eigenen Alltag – zwischen Zoom für berufliche Besprechungen und Netflix am Abend – verbringe ich wahrscheinlich 80 % meines Tages mit Anwendungen, die auf NGINX basieren.

NGINX ist nur ein Teil der Erfolgsgeschichte von Open Source. Ohne all die großartigen Open-Source-Projekte – von Kubernetes und Containern über Python und PyTorch bis hin zu WordPress, Postgres und Node.js – könnten wir weder die digitale Welt aufbauen noch, in zunehmendem Maße, die physische Welt steuern und verwalten. Open Source hat unsere Arbeitsweise verändert. Auf GitHub gibt es mehr als 73 Millionen Entwickler, die gemeinsam über 170 Millionen Pull Requests (PRs) zusammengeführt haben. Ein großer Anteil dieser PRs entfiel auf Code-Repositorys mit Open-Source-Lizenzen.

Wir freuen uns sehr, dass NGINX eine so grundlegende Rolle beim Aufstieg und Erfolg von Open Source gespielt hat – und wir wollen diese Entwicklung nicht nur fortsetzen, sondern auch etwas zurückgeben. Gleichzeitig müssen wir unsere Open-Source-Arbeit reflektieren und an die kontinuierliche Weiterentwicklung der Bewegung anpassen. Die Geschäftsmodelle von Unternehmen, die von Open Source profitieren, waren mitunter umstritten. Deshalb war NGINX stets bemüht, ganz klar zwischen Open Source und kommerziellen Angeboten zu unterscheiden. Vor allem bedeutete dies, niemals Gebühren für Funktionen oder Leistungsmerkmale zu verlangen, die bereits in den Open-Source-Versionen unserer Software enthalten waren.

Open Source entwickelt sich rasant weiter. NGINX entwickelt sich ebenfalls weiter.

Wir erkennen inzwischen, dass wir unser Engagement für Open Source gründlich überdenken, mit unseren Open-Source-Produkten mehr Mehrwert und Funktionen bieten und uns – ja – auch im kommerziellen Bereich stärker ins Zeug legen müssen. Wir können nicht einfach weiterhin für dieselben Dinge wie bisher Geld verlangen, denn die Welt hat sich verändert: Einige Funktionen, die bislang nur in unseren kommerziellen Produkten enthalten waren, gehören für Open-Source-Entwickler heute zur Grundausstattung. Wir wissen auch, dass die Sicherheit von Open Source für Entwickler höchste Priorität hat. Deshalb müssen unsere Open-Source-Projekte genauso sicher sein wie unsere kommerziellen Produkte.

Wir müssen auch die Realität anerkennen. Intern hatten wir die Angewohnheit zu behaupten, Open Source sei nicht wirklich produktionsreif, da es an Funktionen oder Skalierbarkeit mangele. Doch die Realität widerlegt uns in diesem Punkt schon seit geraumer Zeit: Viele Tausend Organisationen setzen NGINX Open-Source-Software in Produktionsumgebungen ein. Und das ist gut so, denn es zeigt, wie sehr sie unseren Open-Source-Versionen vertrauen. Darauf können wir aufbauen.

Tatsächlich tun wir das bei unseren Kernprodukten fortlaufend. Denjenigen, die behaupten, die ursprüngliche NGINX-Produktfamilie sei in die Jahre gekommen, sage ich: Sie haben uns nicht genau genug beobachtet:

• Für die Kernsoftware NGINX Open Source fügen wir weiterhin neue Features und Funktionen hinzu und unterstützen zusätzliche Betriebssystemplattformen. Zwei entscheidende Technologien für die Sicherheit und Skalierbarkeit von Webanwendungen und Datenverkehr, HTTP3 und QUIC, werden in der nächsten von uns veröffentlichten Version verfügbar sein.
• Ein eher stiller, aber unglaublich innovativer Bereich des NGINX-Universums ist NGINX JavaScript (njs). Damit können Entwickler JavaScript-Code in das Ereignisverarbeitungsmodell der NGINX-Module für HTTP und TCP/UDP (Stream) integrieren und die NGINX-Konfigurationssyntax erweitern, um anspruchsvolle Funktionen zu implementieren. Unsere Benutzer haben damit einige wirklich beeindruckende Dinge umgesetzt – von innovativer Cache-Bereinigung und Header-Manipulation bis hin zur Unterstützung fortschrittlicherer Protokolle wie MQTTv5.
• Unser universeller Webanwendungsserver NGINX Unit wurde vom ursprünglichen Autor von NGINX Open Source, konzipiert Igor Sysoev, und wird kontinuierlich weiterentwickelt. Unit nimmt in unserer Vision moderner Anwendungen und eines modernen Anwendungs-Stacks, die weit über unseren primären Fokus auf Datenebene und Sicherheit hinausgeht, einen wichtigen Platz ein. Bei der Weiterentwicklung von Unit überdenken wir, wie Anwendungen für das Web im Wandel konzipiert werden sollten – mit mehr cloudnativen Funktionen, die auf verteilte und hochdynamische Anwendungen ausgelegt sind.

Die Referenzarchitektur für moderne Anwendungen

Wir möchten weiterhin experimentieren und neue Ansätze vorantreiben, um unserer zentralen Entwickler-Community die effizientere und einfachere Bereitstellung moderner Anwendungen zu ermöglichen. Letztes Jahr haben wir auf der Sprint 2.0 die NGINX Modern Apps Reference Architecture (MARA) angekündigt, und ich freue mich, dass sie vor Kurzem mit Version 1.0.0 allgemein verfügbar wurde. MARA ist ein sorgfältig zusammengestellter Stack aus bewährten Tools, darunter Kubernetes, die wir so miteinander verknüpft haben, dass sich Infrastruktur und Anwendungsarchitektur problemlos als Code bereitstellen lassen. Mit nur wenigen Klicks können Sie eine MARA-Referenzarchitektur konfigurieren und bereitstellen, die alles umfasst, was Sie zum Aufbau einer produktionsreifen, cloudnativen Umgebung benötigen – Sicherheit, Protokollierung, Netzwerk, Anwendungsserver, Konfigurations- und YAML-Verwaltung und vieles mehr.

MARA ist ganz bewusst als modulare Architektur konzipiert. Sie können Ihren eigenen Weg wählen und aus den vorhandenen Modulen eine individuelle Referenzarchitektur zusammenstellen, auf der sich tatsächlich Anwendungen ausführen lassen. Die Community hat unsere Idee unterstützt, und wir haben für MARA Partnerschaften mit mehreren innovativen Technologieunternehmen geschlossen. Sumo Logic hat seine Protokollierungskompetenz in MARA eingebracht, während Pulumi Module für die Automatisierung und Workflow-Orchestrierung beigesteuert hat. Wir hoffen, dass mit MARA jeder Entwickler innerhalb weniger Minuten eine vollständige Kubernetes-Umgebung in Betrieb nehmen kann – einschließlich aller unterstützenden Komponenten, sicher und bereit für die Bereitstellung von Anwendungen. Dies ist nur ein Beispiel dafür, wie wir meiner Meinung nach unsere gemeinsame Energie darauf verwenden können, eine große Initiative in der Branche voranzubringen.

Die Zukunft von NGINX: modernisieren, optimieren, erweitern

Jedes Jahr gehen wir auf der NGINX Sprint, unserer virtuellen Anwenderkonferenz, neue Verpflichtungen für das kommende Jahr ein. Dieses Jahr ist da keine Ausnahme. Unsere Versprechen für die nächsten zwölf Monate lassen sich in drei Worten zusammenfassen: modernisieren, optimieren und erweitern. Wir wollen sicherstellen, dass dies nicht nur Schlagworte aus der Geschäftswelt sind. Für jedes dieser Ziele haben wir umfangreiche Programme aufgelegt, und wir möchten, dass Sie uns an unseren Versprechen messen.

Versprechen Nr. 1: Unseren Ansatz, unsere Präsenz und unser Community-Management modernisieren

Natürlich modernisieren wir unseren Code zügig und führen neue Produkte und Projekte ein. Doch bei der Modernisierung geht es nicht nur um Code – sie umfasst auch die Codeverwaltung, transparente Entscheidungsprozesse und die Art und Weise, wie wir in der Community auftreten. Die Codebasis von NGINX Open Source wurde bisher zwar mit dem Versionskontrollsystem Mercurial verwaltet, doch wir wissen, dass die Open-Source-Welt heute auf GitHub zu Hause ist. Künftig werden alle NGINX-Projekte auf GitHub ins Leben gerufen und gehostet, denn dort arbeiten die Entwickler- und Open-Source-Communitys.

Wir werden auch die Governance und Verwaltung der NGINX-Projekte modernisieren. Wir verpflichten uns, offener für Beiträge zu sein, unsere Verantwortung transparenter wahrzunehmen und der Community zugänglicher gegenüberzutreten. Wir werden alle gängigen Konventionen moderner Open-Source-Arbeit befolgen, unseren GitHub-Auftritt neu gestalten, Verhaltenskodizes für alle unsere Projekte einführen und dem Feedback der Community große Aufmerksamkeit schenken. Im Rahmen dieses Modernisierungsversprechens richten wir einen NGINX-Community-Kanal auf Slack ein. Dort stehen unsere eigenen Fachleute bereit, um Ihre Fragen zu beantworten. Und auch Sie als Community können sich dort gegenseitig unterstützen – in dem Messaging-Tool, das Sie bereits in Ihrem Arbeitsalltag nutzen.

Versprechen Nr. 2: Optimierung der Entwicklererfahrung

Entwickler sind unsere wichtigsten Nutzer. Sie entwickeln und erstellen die Anwendungen, die uns zu dem gemacht haben, was wir heute sind. Einer unserer Grundsätze war schon immer, dass NGINX einfach zu bedienen ist. Und das stimmt im Wesentlichen auch – die Installation, Inbetriebnahme und Konfiguration von NGINX dauert keine Tage. Dennoch können wir es noch besser machen. Wir können die Zeit bis zur Wertschöpfung für Entwickler bei der Nutzung unserer Produkte verkürzen, indem wir die Lernkurve abflachen und die Konfiguration vereinfachen. Mit „Wertschöpfung“ meine ich ganz konkret, Code in der Produktionsumgebung bereitzustellen, der einen echten Mehrwert bietet. Wir werden unsere Developer Experience grundlegend überarbeiten, indem wir die Installation optimieren, unsere Dokumentation verbessern und unsere Community-Foren inhaltlich ausbauen und stärken.

Außerdem werden wir ein neues SaaS-Angebot veröffentlichen, das sich nativ in NGINX Open Source integrieren lässt und Ihnen dabei hilft, es innerhalb von Sekunden sinnvoll und gewinnbringend einzusetzen. Es wird weder eine Registrierung noch Zugangsbeschränkungen oder eine Bezahlschranke geben. Dieses SaaS-Angebot wird dauerhaft kostenlos nutzbar sein.

Darüber hinaus ist uns bewusst, dass viele wichtige Funktionen, die Entwickler heute als selbstverständlich ansehen, für NGINX Open Source und NGINX Plus nur hinter einer Bezahlschranke verfügbar sind. Beispielsweise ist die DNS-Diensterkennung für moderne Anwendungen unverzichtbar. Wir versprechen, diese wichtigen Funktionen kostenlos bereitzustellen, indem wir sie in NGINX Open Source integrieren. Wir haben noch nicht entschieden, welche Funktionen wir alle übernehmen werden, und wir möchten Ihre Meinung hören. Sagen Sie uns, wie wir Ihre Erfahrung als Entwickler optimieren können. Wir hören Ihnen zu.

Versprechen Nr. 3: Die Leistungsfähigkeit und Funktionen von NGINX erweitern

So beliebt NGINX heute auch ist, wissen wir, dass wir uns kontinuierlich weiterentwickeln müssen, wenn wir auch in zehn Jahren noch genauso relevant sein wollen. Unser ehrgeiziges Ziel lautet: Wir möchten einen vollständigen Stack aus NGINX-Anwendungen und unterstützenden Funktionen schaffen, mit denen sich moderne Anwendungen in großem Maßstab verwalten und betreiben lassen.

Bislang wurde NGINX hauptsächlich als Layer-7-Datenebene eingesetzt. Damit NGINX funktioniert, müssen Entwickler jedoch eine umfangreiche Infrastruktur darum herum aufbauen. Sie müssen Automatisierungs- und CI/CD-Funktionen anbinden, eine ordnungsgemäße Protokollierung einrichten, Authentifizierung und Zertifikatsverwaltung hinzufügen und vieles mehr. Wir möchten NGINX deutlich besser erweitern, sodass jede wesentliche Anforderung für das Testen und Bereitstellen einer Anwendung durch eine oder mehrere hochwertige Open-Source-Komponenten erfüllt wird, die sich nahtlos in NGINX integrieren lassen. Kurz gesagt: Wir möchten auf jeder Ebene des Stacks einen Mehrwert bieten – und das kostenlos. Wenn Sie beispielsweise NGINX Open Source oder NGINX Plus als API-Gateway verwenden, möchten wir sicherstellen, dass Ihnen alles zur Verfügung steht, was Sie zum Verwalten und Skalieren dieses Anwendungsfalls benötigen: API-Import, Service Discovery, Firewall, Richtlinienregeln und Sicherheit – alles als hochwertige Open-Source-Optionen verfügbar.

Zusammenfassend lässt sich sagen, dass wir davon träumen, rund um NGINX ein Ökosystem aufzubauen, das alle Aspekte der Anwendungsverwaltung und -bereitstellung abdeckt. MARA ist der erste Schritt beim Aufbau dieses Ökosystems, und wir möchten auch weiterhin Partner gewinnen. Mein Ziel ist es, dass bis Ende 2022 eine vollständig vorkonfigurierte Anwendung innerhalb weniger Minuten in einer NGINX-Umgebung gestartet und ausgeführt werden kann – ausgestattet mit einem umfassenden Funktionsumfang aus verteiltem Tracing, Protokollierung, automatischer Skalierung, Sicherheit und CI/CD-Hooks, die allesamt sofort einsatzbereit sind.

Wir stellen vor: Kubernetes API Gateway, ein brandneues Amplify und NGINX Agent

Wir stehen zu all dem. Und hier sind drei erste konkrete Schritte zur Einlösung meiner drei Versprechen.

1. Anfang dieses Jahres haben wir NGINX Kubernetes Gateway<.htmla> auf Grundlage der Referenzarchitektur der Kubernetes API Gateway SIG eingeführt. Damit modernisieren wir unsere Produktfamilie und halten mit der kontinuierlichen Weiterentwicklung cloudnativer Technologien Schritt. Mit dem NGINX Kubernetes Gateway reichen wir der Community gewissermaßen auch die Hand. Uns ist bewusst, dass wir die Situation verkompliziert haben, als wir sowohl einen kommerziellen als auch einen quelloffenen Ingress-Controller für Kubernetes entwickelten, die sich beide von der Ingress-Lösung der Community unterschieden (die ebenfalls auf NGINX basiert). Diese Vielzahl an Optionen sorgte in der Community für Verwirrung und brachte uns in eine ungünstige Lage. Es ist ziemlich klar, dass die Gateway API den Ingress-Controller in der Kubernetes-Architektur ablösen wird. Deshalb ändern wir unseren Ansatz und machen das NGINX Kubernetes Gateway – das ausschließlich als Open-Source-Produkt angeboten wird – zum Mittelpunkt unserer Bemühungen im Bereich Kubernetes-Netzwerke (im Gleichschritt mit dem sich weiterentwickelnden Standard). Es wird sich sowohl in andere NGINX-Produkte integrieren als auch deren Funktionsumfang erweitern und die Entwicklererfahrung auf Kubernetes optimieren.
2. Vor einigen Jahren haben wir NGINX Amplify eingeführt, ein SaaS-Angebot zur Überwachung und Telemetrie von NGINX-Flotten. Wir haben es nicht wirklich groß beworben. Dennoch haben Tausende von Entwicklern es entdeckt und nutzen es bis heute. Amplify war und ist weiterhin kostenlos. Im Rahmen unseres Modernisierungsversprechens erweitern wir Amplify um zahlreiche neue Funktionen. Unser Ziel ist es, Amplify zu Ihrem zuverlässigen Co-Piloten für die Einrichtung, Überwachung und Verwaltung von NGINX-Produkten in großem Maßstab und in Echtzeit zu machen. Amplify wird Ihre NGINX-Instanzen nicht nur überwachen, sondern Sie auch dabei unterstützen, NGINX-Bereitstellungen zu konfigurieren, Skripte darauf anzuwenden und Fehler zu beheben.
3. Wir führen NGINX Agent ein, eine schlanke Anwendung, die Sie zusammen mit NGINX Open Source-Instanzen bereitstellen. Sie wird Funktionen enthalten, die bisher nur in kommerziellen Produkten verfügbar waren, beispielsweise die API für dynamische Konfiguration. Mit NGINX Agent können Sie NGINX Open Source in deutlich mehr Anwendungsfällen und wesentlich flexibler einsetzen. Darüber hinaus bietet die Anwendung wesentlich detailliertere Steuerungsmöglichkeiten, mit denen Sie Ihre Anwendungen und Infrastruktur erweitern können. Agent hilft Ihnen, fundiertere Entscheidungen über die Verwaltung, Bereitstellung und Konfiguration von NGINX zu treffen. Wir arbeiten mit Hochdruck an NGINX Agent – halten Sie in den nächsten Monaten Ausschau nach einem Blogbeitrag, in dem wir die Verfügbarkeit ankündigen!

Ausblick

Ich hoffe, dass Sie mich in einem Jahr auf diese Versprechen ansprechen. Wenn ich bei keinem der drei echte Fortschritte vorweisen kann, nehmen Sie mich bitte beim Wort. Und bitte seien Sie sich darüber im Klaren: Wir bringen uns aktiv ein und sind bereit, mit Ihnen allen ins Gespräch zu kommen. Sie liefern uns die besten Impulse für unsere Produkt-Roadmap. Bitte nehmen Sie an unserer jährlichen Umfrage teil. Treten Sie dem NGINX Community Slack bei und teilen Sie uns Ihre Meinung mit. Kommentieren Sie die Projekte in unserem GitHub-Repository und reichen Sie dort Pull Requests ein.

Es wird ein großartiges Jahr – das beste aller Zeiten. Wir freuen uns darauf, mehr von Ihnen zu hören, und Sie können sich darauf verlassen, dass auch wir uns häufiger bei Ihnen melden werden. Helfen Sie uns, Ihnen zu helfen. Es wird ein großartiges Jahr – das beste aller Zeiten. Wir freuen uns darauf, mehr von Ihnen zu hören, und Sie können sich darauf verlassen, dass auch wir uns häufiger bei Ihnen melden werden.

Über den Autor

Rob WhiteleyGeschäftsführer der NGINX-Produktgruppe

Weitere Blogbeiträge von Rob Whiteley