Die Zeit vergeht wie im Flug, wenn man Spaß hat. Daher ist es kaum zu glauben, dass NGINX mittlerweile 18 Jahre alt ist. Rückblickend haben die Gemeinde und das Unternehmen gemeinsam viel erreicht. Wir haben vor Kurzem einen großen Meilenstein erreicht – zum Zeitpunkt des Schreibens dieses Artikels werden 55,6 % aller Websites von NGINX betrieben (entweder von unserer eigenen Software oder von Produkten, die auf NGINX basieren). Gemessen am Marktanteil sind wir außerdem der Webserver Nummer eins . Darauf sind wir sehr stolz und dankbar, dass Sie, die NGINX-Community, uns dieses überwältigende Vertrauensvotum ausgesprochen haben.
Wir erkennen auch zunehmend, dass Open-Source-Software die Welt weiterhin verändert. Ein immer größerer Prozentsatz der Anwendungen wird mit Open Source-Code erstellt. Von Bloomberg-Terminals und -Nachrichten über die Washington Post und Slack bis hin zu Airbnb, Instagram und Spotify verlassen sich Tausende der weltweit bekanntesten Marken und Unternehmen beim Betrieb ihrer Websites auf NGINX Open Source. In meinem eigenen Leben – zwischen Zoom für Arbeitsbesprechungen und Netflix am Abend – verbringe ich wahrscheinlich 80 % meines Tages mit auf NGINX erstellten Anwendungen.
NGINX ist nur ein Element in der Erfolgsgeschichte von Open Source. Ohne die vielen großartigen Open-Source-Projekte – von Kubernetes und Containern bis hin zu Python und PyTorch, von WordPress über Postgres bis hin zu Node.js – wären wir nicht in der Lage, die digitale Welt aufzubauen – und zunehmend auch die physische Welt zu steuern und zu verwalten. Open Source hat unsere Arbeitsweise verändert. Auf GitHub gibt es über 73 Millionen Entwickler, die zusammen mehr als 170 Millionen Pull Requests (PRs) zusammengeführt haben. Ein großer Prozentsatz dieser PRs befand sich in Code-Repositories mit Open-Source-Lizenzen.
Wir freuen uns, dass NGINX eine so grundlegende Rolle beim Aufstieg und Erfolg von Open Source gespielt hat – und wir beabsichtigen, dies fortzusetzen und weiterzugeben. Gleichzeitig müssen wir über unsere Open-Source-Arbeit nachdenken und uns an die fortlaufende Entwicklung der Bewegung anpassen. Die Geschäftsmodelle von Unternehmen, die von Open Source profitieren, sind zeitweise umstritten. Aus diesem Grund hat NGINX immer versucht, völlig klarzustellen, was Open Source und was kommerziell ist. Dies bedeutete vor allem, dass wir niemals versuchen würden, für Funktionen oder Möglichkeiten, die wir in die Open-Source-Versionen unserer Software integriert hatten, Geld zu verlangen.
Wir sind uns jetzt darüber im Klaren, dass wir unser Engagement für Open Source gründlich überdenken, den Wert und die Funktionen unserer Open-Source-Produkte steigern und, ja, auch im kommerziellen Bereich unsere Leistung steigern müssen. Wir können nicht einfach weiterhin für dieselben Dinge Geld verlangen wie in der Vergangenheit, denn die Welt hat sich verändert – einige Funktionen, die nur in unseren kommerziellen Produkten enthalten sind, sind für Open-Source-Entwickler mittlerweile selbstverständlich. Wir wissen auch, dass Open-Source-Sicherheit für Entwickler oberste Priorität hat. Aus diesem Grund müssen unsere Open-Source-Projekte genauso sicher sein wie unsere kommerziellen Produkte.
Wir müssen auch die Realität anerkennen. Intern sagten wir immer, dass Open Source nicht wirklich produktionsreif sei, weil ihm Funktionen oder Skalierbarkeit fehlten. Die Welt beweist uns seit einiger Zeit, dass wir in dieser Hinsicht Unrecht haben: Viele Tausend Organisationen nutzen die Open-Source-Software NGINX in ihren Produktionsumgebungen. Und das ist gut so, denn es zeigt, wie sehr sie an unsere Open-Source-Versionen glauben. Darauf können wir aufbauen.
Tatsächlich tun wir dies mit unseren Kernprodukten ständig. Denjenigen, die behaupten, die ursprüngliche NGINX-Produktfamilie sei in die Jahre gekommen, möchte ich entgegnen, dass sie uns nicht genau beobachtet haben:
Wir möchten weiterhin experimentieren und neue Wege finden, um unserem Kernentwicklerkreis dabei zu helfen, moderne Anwendungen effizienter und einfacher bereitzustellen. Letztes Jahr haben wir bei Sprint 2.0 die NGINX Modern Apps Reference Architecture (MARA) angekündigt und ich freue mich, mitteilen zu können, dass sie vor Kurzem als Version 1.0.0 allgemein verfügbar geworden ist. MARA ist ein kuratierter und fundierter Stapel von Tools, einschließlich Kubernetes, die wir miteinander verdrahtet haben, um die Bereitstellung von Infrastruktur und Anwendungsarchitektur als Code zu vereinfachen. Mit wenigen Klicks können Sie eine MARA-Referenzarchitektur konfigurieren und bereitstellen, die alles enthält, was Sie zum Erstellen einer produktionstauglichen, Cloud-nativen Umgebung benötigen – Sicherheit, Protokollierung, Netzwerk, Anwendungsserver, Konfigurations- und YAML-Verwaltung und mehr.
MARA ist eine modulare Architektur und von Natur aus modular. Sie können Ihr eigenes Abenteuer wählen und aus den vorhandenen Modulen eine angepasste Referenzarchitektur entwerfen, die tatsächlich Anwendungen ausführen kann. Die Community hat unsere Idee unterstützt und wir haben bei MARA mit einer Reihe innovativer Technologieunternehmen zusammengearbeitet. Sumo Logic hat MARA mit seinen Protokollierungskenntnissen ausgestattet und Pulumi hat Module für die Automatisierung und Workflow-Orchestrierung beigesteuert. Wir hoffen, dass jeder Entwickler mit MARA innerhalb weniger Minuten eine vollständige Kubernetes-Umgebung zum Laufen bringen kann, komplett mit allen unterstützenden Komponenten, sicher und bereit für die App-Bereitstellung. Dies ist nur ein Beispiel dafür, wie wir meiner Meinung nach alle unsere gemeinsame Energie einsetzen können, um eine große Initiative in der Branche voranzutreiben.
Jedes Jahr gehen wir beim NGINX Sprint, unserer virtuellen Benutzerkonferenz, neue Verpflichtungen für das kommende Jahr ein. Dieses Jahr ist nicht anders. Unsere Versprechen für die nächsten zwölf Monate lassen sich in drei Worten zusammenfassen: modernisieren , optimieren und erweitern . Wir möchten sicherstellen, dass dies nicht nur Schlagworte aus der Geschäftswelt sind. Wir verfügen über umfassende Programme für jedes dieser Schlagworte und möchten, dass Sie sich an unsere Versprechen halten.
Natürlich modernisieren wir unseren Code schnell und führen neue Produkte und Projekte ein. Bei der Modernisierung geht es aber nicht nur um Code – sie umfasst auch Codeverwaltung, Transparenz bei der Entscheidungsfindung und unsere Präsenz in der Community. Während die Open-Source-Codebasis von NGINX in der Vergangenheit auf dem Versionskontrollsystem Mercurial lief, erkennen wir an, dass die Open-Source-Welt jetzt auf GitHub lebt. Künftig werden alle NGINX-Projekte auf GitHub erstellt und gehostet, da dort die Entwickler- und Open-Source-Communitys arbeiten.
Darüber hinaus werden wir die Steuerung und Verwaltung von NGINX-Projekten modernisieren. Wir verpflichten uns, offener für Beiträge zu sein, unsere Verwaltung transparenter zu gestalten und für die Community zugänglicher zu sein. Wir werden alle erwarteten Konventionen für moderne Open-Source-Arbeit befolgen, unsere Präsenz auf GitHub neu aufbauen, allen unseren Projekten Verhaltenskodizes hinzufügen und dem Feedback der Community große Aufmerksamkeit schenken. Als Teil unserer Verpflichtung zur Modernisierung fügen wir auf Slack einen NGINX-Community-Kanal hinzu. Wir besetzen den Kanal mit eigenen Experten, die Ihre Fragen beantworten. Und auch Sie, die Community, stehen einander zur Seite – und zwar über das Messaging-Tool, das Sie bereits für Ihre tägliche Arbeit verwenden.
Entwickler sind unsere Hauptbenutzer. Sie entwickeln und erstellen die Anwendungen, die uns zu dem gemacht haben, was wir sind. Unser Grundsatz war schon immer, dass NGINX einfach zu verwenden ist. Und das stimmt grundsätzlich auch: Die Installation, Inbetriebnahme und Konfiguration von NGINX dauert nicht tagelang. Dennoch können wir es besser machen. Wir können die „Time-to-Value“, die Entwickler bei der Nutzung unserer Produkte erleben, beschleunigen, indem wir die Lernkurve verkürzen und den Konfigurationsprozess vereinfachen. Mit „Wert“ meine ich die Bereitstellung von Code, der in der Produktion etwas wirklich Wertvolles tut, Punkt. Wir werden die Erfahrung unserer Entwickler neu gestalten, indem wir das Installationserlebnis optimieren, unsere Dokumentation verbessern und die Reichweite und Bedeutung unserer Community-Foren erhöhen.
Wir werden außerdem ein neues SaaS-Angebot veröffentlichen, das sich nativ in NGINX Open Source integrieren lässt und Ihnen hilft, es in Sekundenschnelle nützlich und wertvoll zu machen. Es wird keine Registrierung, kein Gate und keine Paywall geben. Die Nutzung dieser SaaS ist für immer kostenlos.
Darüber hinaus erkennen wir, dass viele kritische Funktionen, die für Entwickler heute selbstverständlich sind, auf der falschen Seite der Paywall für NGINX Open Source und NGINX Plus liegen. Beispielsweise ist die DNS-Diensterkennung für moderne Apps von entscheidender Bedeutung. Unser Versprechen ist, diese wichtigen Funktionen kostenlos bereitzustellen, indem wir sie zu NGINX Open Source hinzufügen. Wir haben noch nicht entschieden, welche Funktionen alle verschoben werden sollen, und möchten daher Ihre Eingaben hören . Sagen Sie uns, wie wir Ihre Erfahrung als Entwickler optimieren können. Wir hören zu.
Obwohl NGINX heute beliebt ist, wissen wir, dass wir uns weiter verbessern müssen, wenn wir in zehn Jahren noch genauso relevant sein wollen. Unser ehrgeiziges Ziel ist folgendes: Wir möchten einen vollständigen Stapel von NGINX-Anwendungen und unterstützenden Funktionen für die Verwaltung und den Betrieb moderner Anwendungen im großen Maßstab erstellen.
Bisher wurde NGINX hauptsächlich als Layer-7-Datenebene verwendet. Damit NGINX funktioniert, müssen die Entwickler jedoch eine Menge Strukturmaterial um es herum aufbauen. Sie müssen Automatisierungs- und CI/CD-Funktionen verkabeln, die ordnungsgemäße Protokollierung einrichten, Authentifizierung und Zertifikatsverwaltung hinzufügen und vieles mehr. Wir möchten eine deutlich bessere Erweiterung von NGINX erstellen, bei der alle wichtigen Anforderungen zum Testen und Bereitstellen einer App durch eine oder mehrere hochwertige Open-Source-Komponenten erfüllt werden, die sich nahtlos in NGINX integrieren lassen. Kurz gesagt: Wir möchten auf jeder Ebene des Stacks Mehrwert bieten und dies kostenlos machen. Wenn Sie beispielsweise NGINX Open Source oder NGINX Plus als API-Gateway verwenden, möchten wir sicherstellen, dass Sie über alles verfügen, was Sie zum Verwalten und Skalieren dieses Anwendungsfalls benötigen – API-Import, Diensterkennung, Firewall, Richtlinienregeln und Sicherheit – und alles als hochwertige Open-Source-Optionen verfügbar.
Zusammenfassend besteht unser Traum darin, rund um NGINX ein Ökosystem aufzubauen, das sich auf jeden Aspekt der Anwendungsverwaltung und -bereitstellung erstreckt. MARA ist der erste Schritt beim Aufbau dieses Ökosystems und wir möchten weiterhin Partner gewinnen. Mein Ziel ist es, dass bis Ende 2022 eine komplette vorverdrahtete App gestartet wird und innerhalb von Minuten in einer NGINX-Umgebung ausgeführt werden kann. Sie ist mit allen Funktionen ausgestattet – verteiltes Tracing, Protokollierung, Autoscaling, Sicherheit, CI/CD-Hooks – und alle sind bereit, ihre Arbeit zu erledigen.
All dem fühlen wir uns verpflichtet. Und hier sind drei Anzahlungen auf meine drei Versprechen.
Anfang des Jahres haben wir NGINX Kubernetes Gateway<.htmla> eingeführt, basierend auf der Referenzarchitektur der Kubernetes API Gateway SIG . Dadurch modernisieren wir unsere Produktfamilie und sorgen dafür, dass wir mit der fortlaufenden Entwicklung des Cloud Native Schritt halten. Das NGINX Kubernetes Gateway ist auch so etwas wie ein Friedensangebot, das wir der Community anbieten. Wir sind uns bewusst, dass die Sache kompliziert wurde, als wir sowohl einen kommerziellen als auch einen Open-Source-Ingress-Controller für Kubernetes erstellten, die sich beide von der Community-Ingress-Lösung (ebenfalls auf NGINX basierend) unterschieden. Die Auswahlmöglichkeiten haben die Community verwirrt und uns in eine schlechte Lage gebracht.
Es ist ziemlich klar, dass die Gateway-API den Platz des Ingress-Controllers in der Kubernetes-Architektur einnehmen wird. Deshalb ändern wir unseren Ansatz und machen das NGINX Kubernetes Gateway – das nur als Open-Source-Produkt angeboten wird – zum Mittelpunkt unserer Kubernetes-Netzwerkbemühungen (im Gleichschritt mit dem sich entwickelnden Standard). Es lässt sich in andere NGINX-Produkte integrieren und erweitern und optimiert das Entwicklererlebnis auf Kubernetes.
Ich hoffe, dass Sie mich in einem Jahr nach diesen Versprechen fragen. Wenn ich in allen drei Punkten keine wirklichen Fortschritte vermelden kann, dann halten Sie mich bitte daran. Und bitte haben Sie Verständnis – wir sind engagiert und gesprächsbereit mit Ihnen allen. Sie sind unsere beste Produkt-Roadmap. Bitte nehmen Sie an unserer jährlichen Umfrage teil. Treten Sie dem NGINX Community Slack bei und sagen Sie uns, was Sie denken. Kommentieren und reichen Sie PRs zu den Projekten in unserem GitHub-Repo ein.
Es wird ein großartiges Jahr, das beste aller Zeiten. Wir freuen uns auf Ihre Kontaktaufnahme und sind gerne bereit, weiterhin von uns zu hören. Helfen Sie uns, Ihnen zu helfen. Es wird ein großartiges Jahr, das beste aller Zeiten. Wir freuen uns auf Ihre Kontaktaufnahme und sind gerne bereit, weiterhin von uns zu hören.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."