5 Gründe für die Umstellung auf Software Load Balancing

Dieser Beitrag basiert auf einem Webinar von Floyd Smith und Faisal Memon von NGINX, Inc. Unser neues Ebook zum Thema steht zum Download bereit.

Inhaltsverzeichnis

0:00 Einführung

Floyd Smith: Hallo und willkommen zu unserer Präsentation. Wir sind hier bei NGINX und sprechen heute über mein E-Book „ 5 Gründe für die Umstellung auf Software zur Lastverteilung“ .

Wir sind heute zu zweit und präsentieren hier. Ich bin Floyd Smith, technischer Marketingautor für NGINX. Ich war zuvor leitender technischer Autor bei Apple und habe zahlreiche Bücher über verschiedene Aspekte der Technologie verfasst.

Faisal Memon: Hallo, ich bin Faisal Memon und mache hier bei NGINX das Produktmarketing. Ich bin seit ungefähr einem Jahr hier. Bevor ich hier zu NGINX kam, habe ich als Technical Marketing Engineer bei Riverbed und Cisco gearbeitet. Ich habe meine Karriere mit der Entwicklung in C begonnen. Als Softwareentwickler bei Cisco habe ich diese Funktion etwa acht Jahre lang ausgeübt.

1:38 Wer bist du?

Floyd: Wir erhalten Anmeldungen für unsere Webinare, bevor wir sie durchführen, und wir können die Berufsbezeichnungen, Organisationen und Gründe für die Teilnahme sehen, die jeder von Ihnen angegeben hat.

Es war wirklich interessant, sich die Titel der Teilnehmer anzusehen. Wir haben Solutions Architects – mehrere verschiedene Arten von Architekten. Linux-Administratoren, Leiter der technischen Abteilung, CEO, Senior Agile Delivery Manager, mehrere Personen mit DevOps-Titeln, Full-Stack-Softwareentwickler, Ingenieur, Wissenschaftler, Entwickler, Marketing Operations Manager.

Wir haben eine wirklich gute Auswahl an Leuten mit technischer Neigung. Ich habe den Eindruck, dass die Teilnehmer dieses Webinars sehr viel Erfahrung mit der Technologie haben und direkt mit den Problemen konfrontiert werden, über die wir heute hier sprechen.

Außerdem ist ein wirklich schönes und breites Spektrum an Organisationen vertreten. Einige von Ihnen sehen sich dies möglicherweise an, um Ihren Kunden bei der Entscheidungsfindung zu helfen, aber die Mehrheit von Ihnen scheint sich direkt im Unternehmen damit zu befassen.

3:53 Von der Hardware zur Software

Finanzberichten zufolge ist der Markt für Hardware-ADCs rückläufig. Daher versuchen die Verkäufer von Hardware-ADCs, ihren Umsatz pro Kunde zu steigern, auch wenn ihre Kundenbasis zurückgeht. Viele Hardware-ADC-Kunden stellen allmählich fest, dass sie nicht zu dem immer kleiner werdenden Pool von Leuten gehören möchten, die immer mehr Geld für diese von Hardware-ADCs bereitgestellten Dienste bezahlen. Sie erkennen allmählich, dass sie mit Software dieselben Aufgaben besser erledigen können und dabei noch mehr Flexibilität gewinnen. Diejenigen unter Ihnen, deren Berufsbezeichnung „DevOps“ enthält, wissen wahrscheinlich, was ich meine.

Was wir hier bei NGINX häufig beobachten, ist, dass die Leute das Datum für die Vertragsverlängerung ihres Hardware-ADC erreichen oder dass es zu einem plötzlichen Anstieg des Datenverkehrs und der Gebühren kommt und sie dann verzweifelt versuchen, aus dem Vertrag herauszukommen. Dann müssen sie versuchen, die Dinge sehr schnell zu erledigen. Normalerweise gelingt ihnen das, aber es ist stressig und geschieht ungeplant und ohne Budget. Mithilfe dieser Präsentation können Sie einen planvolleren Prozess starten.

Die Budgetfrage ist nicht so kritisch, weil Sie durch die Umstellung auf Software viel Geld sparen, aber der betriebliche Aufwand ist enorm. Sie können diese erheblich reduzieren, indem Sie früh anfangen.

NGINX ist eine wirklich solide Alternative zu einem Hardware-ADC. Es wurde ursprünglich entwickelt, um das C10K-Problem zu lösen. Das ist ein Webserver, der auf einem Computer ausgeführt wird und 10.000 oder mehr gleichzeitige Verbindungen bereitstellt. Vor NGINX war das unmöglich. Die Leute erstellten eine Website, sie wurde populär und dann brach sie zusammen. Dies zu verhindern war sehr, sehr, sehr schwierig, aber mit NGINX wurde es viel einfacher.

Unsere erste Open-Source-Version erschien 2004 in Russland, wo NGINX [die Software] ursprünglich entwickelt wurde [Anm. d. Red.: Floyd sagt hier „gegründet“; NGINX, Inc. wurde 2011 gegründet] . NGINX Plus, die kommerzielle Version mit Support, wurde 2013 veröffentlicht.

Das Unternehmen NGINX hat seinen Sitz im Silicon Valley (San Francisco) und unsere Entwicklungsbüros befinden sich in Moskau. Wir haben auch Büros in Großbritannien. Das Unternehmen wird von führenden Risikokapitalgebern der Branche finanziert. Wir haben mehr als 800 Kunden und haben vor kurzem die Marke von 100 Mitarbeitern erreicht.

6:33 Der führende Webserver für die meistgenutzten Websites der Welt

Insgesamt laufen 160 Millionen Websites auf NGINX.

Es wird in zwei verschiedenen Modi verwendet. Einige Sites führen NGINX als Webserver aus, was auch sein ursprünglicher Zweck war. Viele Sites betreiben NGINX jedoch als Reverse‑Proxyserver . Das ist der Punkt, an dem Sie NGINX vor Ihre aktuelle Architektur setzen und NGINX zur Abwicklung des Datenverkehrs und zur Weiterleitung des Datenverkehrs an Ihre Anwendungsserver verwenden. Sobald Sie das tun, sind Sie auf dem Weg zum Lastenausgleich , worüber wir heute sprechen werden.

51 Prozent der 10.000 meistbesuchten Websites sind zu NGINX gewechselt. Warum ist das so? Warum ist unsere Nutzung bei den stark frequentierten Websites sogar höher als bei allen Websites insgesamt?

Der Grund dafür ist, dass NGINX die beste Lösung für wirklich stark frequentierte Websites ist. Eine stark frequentierte Website mit Problemen lässt sich schnell retten, indem Sie NGINX als Reverse-Proxy-Server einsetzen und darauf dann einen Lastenausgleich ausführen .

Mit der Zeit können Sie entweder Ihre vorhandenen Apps auf NGINX umstellen oder, falls Sie neue entwickeln, NGINX auch für diese als Webserver ausführen. Und so haben wir diese Nutzung bei diesen sehr beschäftigten Leuten erreicht, die den Webserver nicht aus einer Laune heraus wechseln. Sie haben Erfahrung mit anderen Webservern und wissen, wie man sie verwendet, aber sie nehmen diesen Wechsel vor, weil NGINX so viel für sie leistet.

36 Prozent aller Websites bei Amazon Web Services verwenden NGINX. Es entwickelt sich mehr und mehr zum Standardtool. Heutzutage beginnen die Leute oft mit NGINX und bleiben während des gesamten Projekts dabei.

Hier sind einige der Websites, die uns nutzen. Natürlich können wir nicht alle 160 Millionen Websites auf einer Folie darstellen, die NGINX verwenden. Aber zu unseren Partnern und Freunden zählen beispielsweise Netflix, Airbnb, Uber und, wie bereits erwähnt, Amazon Web Services sowie Box, Pinterest und WordPress.

Alle diese Unternehmen, deren Lebensunterhalt mit der Bereitstellung von Webdiensten verdient ist und die dort funktionieren müssen, sind zu NGINX gewechselt.

8:48 Wo NGINX passt

Schauen wir uns an, wo NGINX passt.

Auf der rechten Seite sehen Sie NGINX, das als Webserver ausgeführt wird. Und als Webserver verwendet es ein Anwendungsgateway, um die Ausführung verschiedener Arten von App-Servern zu ermöglichen. NGINX kann als Webserver je nach Ihrer Tätigkeit mehr oder weniger als 10.000 gleichzeitige Verbindungen verarbeiten.

Aber NGINX ist auch als Reverse-Proxy-Server nützlich und bietet Ihnen dort Caching, Lastausgleich und eine Reihe anderer Funktionen.

9:32 Moderne Webarchitektur

NGINX unterstützt Sie auch beim Wechsel zu einer modernen Webarchitektur. Das könnte eine Migration von dreistufigen Architekturen im J2EE-Stil zu Microservices sein. Es könnte sich um eine Verschiebung komplexer HTML- und SOAP-Protokolle zu einfacheren Protokollen wie REST und Messaging handeln, die einen großen Teil der Microservices ausmachen. Oder wechseln Sie von persistenten Bereitstellungen zu veränderbaren Bereitstellungen, auf denen Container oder VMs ausgeführt werden.

Anstelle einer festen, statischen Infrastruktur verfügen Sie dabei meist über einen Dienst, dessen Eigentümer Sie selbst sind. Wir haben Dinge wie SDN und NFV und die Cloud, insbesondere die Cloud. Anstelle von Big-Bang-Releases alle paar Monate gibt es eine kontinuierliche Bereitstellung alle paar Stunden. Und statt isolierter Teams, bei denen eine Entwicklungsgruppe, eine Testgruppe und eine Betriebsgruppe mit jeweils eigenen Managern arbeiten, herrscht eine DevOps-Kultur der geteilten Verantwortung, in der jeder die Ärmel hochkrempelt und sich um einige Aspekte jedes Problems kümmert.

10:42 DevOps funktioniert hervorragend mit NGINX

DevOps-Methodik, Cloud-Bereitstellungen und automatisierte Serviceerkennung“ size-full wp-image-46723″ style=“border:2px solid #666666; padding:2px; margin:2px;“ />

Die DevOps-Geschichte ist eng mit NGINX verknüpft. Viele DevOps-Leute haben NGINX in der Hinterhand, und wenn sie auf eine Bereitstellung stoßen, bei der Probleme auftreten, holen sie NGINX ins Spiel.

Bei bestimmten Bereitstellungen können Sie sich die Mühe machen, die App-Einstellungen überhaupt nicht zu ändern. Wenn Sie NGINX davor platzieren, leiten Sie den Datenverkehr auf eine Weise zu den App-Servern, die diese verarbeiten können. Sie haben den Code nicht geändert und Ihre Kernfunktionalität nicht riskiert, als Sie es eilig hatten, ein Leistungsproblem zu lösen.

Wie wir noch besprechen werden, ist die Software-Lastverteilung einer der Bereiche, in denen DevOps und NGINX in der Regel gut zusammenarbeiten. Es funktioniert wirklich gut mit Cloud-Bereitstellungen, aber auch mit Ihren eigenen Servern. Es verfügt über verschiedene Methoden zum Lastausgleich. Hier gibt es einen Unterschied zwischen NGINX und NGINX Plus, auf den ich gleich eingehen werde.

Die Funktion zur sofortigen Neukonfiguration von NGINX unterstützt die Diensterkennung und Betriebszeit. Die Diensterkennung ist für Mikrodienste und Automatisierung von entscheidender Bedeutung. Dank der Neukonfiguration im laufenden Betrieb müssen Sie für die Konfiguration keine Mitarbeiter von einem Server trennen. Dies ist ein großer Vorteil, wenn es darum geht, Ihre Kunden online zu halten.

Durch Integritätsprüfungen von Anwendungen werden Sie frühzeitig auf Probleme bei der Anwendungsbereitstellung hingewiesen, sodass Sie einen Problemserver ordnungsgemäß herunterfahren können, statt ihn einfach blockieren und die Benutzer aus dem System werfen zu lassen. Und dann gibt es noch eine robuste, anpassbare Überwachung. Auch hierdurch werden Sie über auftretende Probleme informiert, sodass Sie diese lösen können, bevor sie sich auf die Kunden auswirken.

12:30 NGINX Plus-Funktionen

Was ist in NGINX Plus enthalten?

Daher ist NGINX das Open Source-Produkt und NGINX Plus das kommerzielle Produkt darauf. Wir hier bei NGINX verbringen mindestens 70 Prozent unserer Zeit mit der Open-Source-Seite, aber das ist auch die Grundlage für die erweiterten Funktionen in NGINX Plus.

Das Open-Source-Produkt umfasst die Anforderungsweiterleitung, die die Kernfunktion eines Webservers bildet, sowie Komprimierung, da diese die Belastung eines Webservers und den Datenverkehr über die Leitung minimiert, was sehr wertvoll sein kann. Aus Sicherheitsgründen unterstützt es SSL. Wir haben auch eine eingebettete Skriptsprache, eigentlich zwei. Eines ist unser eigenes, das NGINX-JavaScript-Modul [früher nginScript genannt], und eines ist Lua.

Es gibt einige Funktionen, die teilweise auf der Open Source-NGINX-Plattform basieren, in NGINX Plus jedoch erweitert wurden. Mit dem Open Source-Programm NGINX erreichen Sie ein recht gutes Lastenausgleichsergebnis, mit NGINX Plus erhalten Sie jedoch noch ein paar erweiterte Funktionen. Ebenso können Sie Open Source NGINX als Edge-Cache und für Medienstreaming verwenden, und das funktioniert in NGINX Plus sogar noch besser.

NGINX Plus verfügt außerdem über mehrere eigene Funktionen. Es gibt eine Überwachung der Anwendungsintegrität, eine GUI-Visualisierung für Ihr Monitoring, Ihre Überwachung und Analyse, die RESTful-Konfigurations-API und einige der fortgeschritteneren Techniken zum Lastenausgleich.

Mit NGINX Plus erhalten Sie Zugriff auf NGINX-Ingenieure, die Sie bei Ihrer Arbeit unterstützen. Wenn Sie derzeit F5, Citrix oder ein ähnliches System verwenden, sind Sie wahrscheinlich an diese Art der Unterstützung gewöhnt. Bei größeren und stark genutzten Websites, bei denen selbst kurze Ausfallzeiten viel Geld kosten, kann dies von entscheidender Bedeutung sein – und sich leicht amortisieren, wenn Sie auch nur einmal im Jahr einen kurzen Ausfall vermeiden.

14:41 Kundenfallstudie – WordPress.com

Sehen wir uns einige Fallstudien von Kunden an, die umgestiegen sind.

WordPress.com verwendete BIG-IP von F5 und wechselte davon zu NGINX, weil ein Lastenausgleich mit mehr als 10.000 Anfragen pro Sekunde und Server durchgeführt werden musste – das ist das C10k-Problem, über das wir gesprochen haben und das NGINX seit mehr als zehn Jahren löst. Damals waren sie auf 1.000 Anfragen pro Sekunde und Server beschränkt. Sie können sich vorstellen, was für ein Aufwand das im Vergleich zu 10.000 oder mehr war.

Wordpress.com verfügte über mehrere F5-BIG-IP-Systeme und wollte auf zehn Rechenzentren anwachsen. Um eine hohe Verfügbarkeit zu unterstützen und im Wesentlichen für jedes Rechenzentrum ein Live-Backup zu haben, prüften sie zehn Paare von BIG-IP-Servern. Sehr teuer. Sie mussten außerdem eine sofortige Neukonfiguration durchführen, um Benutzer beim Ändern der Konfiguration nicht auszuloggen.

Sie begannen mit der Umstellung auf NGINX, indem sie es auf Gravatar testeten, einer App, die Benutzern einen Avatar anzeigt. Dadurch wurden sie mit NGINX vertraut. Dann wechselten sie von ihren F5-Servern zu NGINX, was ihnen einen kleinen und vorhersehbaren Speicherbedarf sowie einen kleinen und vorhersehbaren CPU-Bedarf bescherte.

Jetzt verarbeiten sie mehr als 70.000 Anfragen pro Sekunde und 15 Gigabit pro Sekunde [Gbps] auf 36 NGINX-Servern. In Spitzenzeiten können es 20.000 Anfragen pro Sekunde und Server sein. Und sie können im laufenden Betrieb neu konfiguriert und aktualisiert werden.

Wenn Sie sich das Zitat ansehen, geht es lediglich um den Kostenunterschied zwischen einer kleinen Implementierung und der, bei der Sie mit NGINX eine beträchtliche Summe Geld sparen, Aber bei zehn Serverpaaren ist der Unterschied riesengroß.

16:42 Kundenfallstudie – Montana Interactive

Montana Interactive wählt NGINX Plus für hochverfügbaren Lastausgleich. Tatsächlich ist es einfacher, günstiger und besser, viele staatliche Dienstleistungen online bereitzustellen. Wenn Sie schon einmal einen Termin bei Ihrer Kfz-Zulassungsstelle o. Ä. gebucht haben, wissen Sie, was ich meine. Diese Websites können Sie bei der Stimmabgabe, der Zahlung Ihrer Steuern usw. unterstützen.

Diese unverzichtbaren staatlichen Dienstleistungen gibt es in enormer Menge und Montana ist ein sehr großer Staat mit einer verhältnismäßig kleinen, über das ganze Land verstreuten Bevölkerung. Daher ist es sehr wichtig, dass Dienstleistungen online verfügbar sind, anstatt dass die Bürger sechs oder acht Stunden fahren müssen, um zu einer Behörde zu gelangen.

Montana war zunächst ziemlich entschlossen, auf Online-Dienste umzusteigen, doch mit zunehmendem Wachstum kam es zu Sitzungsabbrüchen. Sie hatten aufgrund einer großen Zahlungs-App für Steuern große vierteljährliche Spitzen im Transaktionsverkehr. Während des Ausfüllens eines umfangreichen Formulars wurde plötzlich jemand aus der Liste genommen und seine gesamte Arbeit ging verloren. Wenn Sie Ihre Steuern oder andere aufwändige Prozesse erledigen, ist das ziemlich stressig.

Die Lösung für sie bestand darin, von Servern, auf denen Pound lief, auf NGINX Plus umzusteigen, NGINX Plus auf verschiedenen Hypervisoren und Rechenzentren zu installieren und es als dynamischer Reverse-Proxy zu betreiben, der Anfragen in Echtzeit weiterleitet und ihnen so ein besseres Verkehrsmanagement ermöglicht. Durch die Umstellung auf NGINX Plus konnten sie enorme Verbesserungen bei Geschwindigkeit, Flexibilität und Benutzerfreundlichkeit erzielen. Sie profitierten von einer Neukonfiguration im laufenden Betrieb, verlagerten ihre SSL-Verarbeitung auf NGINX-Server und nutzten eine rollenbasierte Verwaltung, um Betrieb und Sicherheit zu verbessern.

James Ridle von Montana Interactive war von der Leistungsfähigkeit von NGINX begeistert. Die Benchmarks haben ihn umgehauen und er konnte den Unterschied, den er mit NGINX über dieselben Server bewältigen konnte, kaum glauben.

18:43 Kundenfallstudie – BuyDig.com

Dies ist eine weitere Fallstudie mit enormen Vorteilen für den Kunden – BuyDig.com, eine E-Commerce-Site, die mit NGINX Skalierbarkeit und Sicherheit erreichte.

BuyDig.com hatte eine ältere .NET-App. Sie wollten diese nicht ändern und mussten es auch nicht. Nachdem sie Opfer eines groß angelegten DDoS- Angriffs geworden waren, wurde ihnen klar, dass sie ein schnelles, fehlertolerantes und einfach zu konfigurierendes Frontend mit besserer Leistung, Sicherheit und Skalierbarkeit benötigten.

Sie haben NGINX Plus in die Front-End-Anwendungsschicht integriert, die auf Amazon Web Services gehostet wird. Sie haben keine Änderungen an ihren auf .NET laufenden Backend-Diensten vorgenommen. Und das ist so groß – keine Änderungen – keine kleinen Änderungen, keine geringfügigen Unannehmlichkeiten, keine geringfügigen Risiken, sondern keine.

Jetzt erhalten sie fantastische Leistung und Sicherheit. Sie verwendeten Konfigurationssprachen für NGINX, um es anzupassen. Sie verwenden TLS SNI und anpassbare Protokolle, um ihre Sicherheit zu gewährleisten. Es kam zu keiner einzigen Verlangsamung oder Ausfallzeit der Site und sie sind mit der Leistung wirklich zufrieden.

Dies sind nur einige Beispiele dafür, was NGINX Plus kann.

20:10 E-Book – 5 Gründe für die Umstellung auf Software zum Lastenausgleich

Lassen Sie mich jetzt tiefer in das E-Book eintauchen. Ich gebe Ihnen eine kurze Zusammenfassung des Inhalts des E-Books. Anschließend erläutert Ihnen Faisal die ersten beiden, eher technischen Gründe für einen Wechsel. Danach mache ich weiter. Es gibt Verknüpfungen. Diese Präsentation und die Aufzeichnung des Webinars werden Ihnen nach Abschluss zur Verfügung gestellt. Ich glaube, es dauert ungefähr einen Tag, bis diese E-Mail rauskommt.

Und über diesen Link hier gelangen Sie zu einem Download-Bereich für dieses kostenlose E-Book . Um die Gründe gleich vorab zu nennen: Es geht um Kostensenkungen, eine bessere DevOps-Anpassung, die Bereitstellung überall (auf Ihren eigenen Servern vor Ort, in der Cloud, in der privaten Cloud – was immer Sie möchten), die Fähigkeit zur schnellen Anpassung und keine merkwürdigen vertraglichen Einschränkungen, die ich noch genauer erläutern werde. Doch nun übergebe ich das Wort an Faisal, der über Kostensenkungen sprechen wird.

21:22 Grund Nr. 1 – Kosten drastisch senken

Faisal: Danke, Floyd. Grund Nr. 1 der fünf Gründe besteht darin, dass Sie durch die Umstellung auf NGINX Plus für die Bereitstellung von Softwareanwendungen die Kosten drastisch senken können.

Wenn wir auf die Mitte der 90er Jahre zurückblicken, bestand die einzige Möglichkeit, eine Website zu skalieren darin, einen größeren Server zu kaufen, was unglaublich teuer und außerdem unzuverlässig war, da dieser einzelne Server auch einen einzelnen Ausfallpunkt darstellte.

Etwa zu dieser Zeit veröffentlichte F5 erstmals BIG-IP und bot damit Websitebesitzern eine andere Architektur; statt einen größeren Server zu kaufen, konnten sie BIG-IP zum Lastenausgleich einer Reihe kostengünstiger Server verwenden. Dadurch werden die Kosten gesenkt, da der Kauf von BIG-IP und preiswerten Servern günstiger ist als der Kauf eines einzelnen Riesenservers. Zudem gewinnt man an Redundanz, da man den einzelnen Ausfallpunkt eliminiert hat.

Das war eine großartige Architektur – revolutionär und damals wirklich das einzig Mögliche – aber in den letzten 20 Jahren hat sich viel verändert. Eine wesentliche Änderung bestand darin, dass die Serverkosten drastisch gesunken sind. Heutzutage kann man hier in der San Francisco Bay Area einen recht leistungsstarken Server für weniger als eine Monatsmiete kaufen.

Die zweite große Veränderung ist die Existenz von Open-Source-Software wie NGINX, die dieselbe Funktionalität bietet wie F5 BIG-IP oder Citrix NetScaler. Bei Open Source erhalten Sie ähnliche Funktionen wie bei den großen, teuren Geräten kostenlos. Floyd wies zuvor darauf hin, dass über 160 Millionen Websites NGINX verwenden. Und wenn Sie sich die Top 10.000 Sites ansehen, laufen über die Hälfte davon auf NGINX.

Wir verfügen jetzt also über diese Open-Source-Software, die im Vergleich zu F5 nicht nur über alle erforderlichen Funktionen verfügt, sondern auch so skalierbar und zuverlässig ist wie jedes andere kommerzielle Produkt.

23:19 NGINX Plus vs. F5 BIG‑IP

Ich habe Anfang des Jahres einige Benchmarking- und Kostenanalysen durchgeführt. Hier ist ein Auszug daraus. Hier wird die NGINX Plus-Software verglichen, die auf handelsüblicher Standardhardware läuft. In diesem Fall wird es von Dell bereitgestellt und [wir] vergleichen es mit verschiedenen Modellen des F5 BIG‑IP.

Dieses spezielle Beispiel ist der 2000S, das F5 BIG‑IP-Einstiegsmodell. Ich habe es mit zwei unterschiedlichen Größen von NGINX Plus auf Dell-Servern verglichen. Eine, deren Leistung etwas niedriger ist als die des F5 BIG‑IP (die Leistungsmesswerte können Sie dort unten sehen) und eine, die die Leistung fast verdoppelt.

Wenn Sie sich nur die rechte Spalte ansehen, wo NGINX Plus die Leistung des 2000S verdoppelt, erzielen Sie im ersten Jahr Einsparungen von 78 %, einschließlich der Kosten für die Hardware und den Wartungssupport für ein Jahr. Und diese Kosteneinsparungen wirken sich bis ins fünfte Jahr aus. Selbst nach fünf Jahren sind die Gesamtbetriebskosten von NGINX Plus mit dem Dell-Server 58 % günstiger als beim F5.

24:37 NGINX Plus vs. Citrix NetScaler

Den gleichen Kostenvergleich habe ich mit Citrix NetScaler durchgeführt. Hier vergleichen wir den NetScaler der Einstiegsklasse, die MPX-5550 Enterprise Edition.

Bei Citrix gibt es eine Lizenzierung, bei der Sie Ihre Lizenz auf die Enterprise Edition-Lizenz upgraden müssen, wenn Sie grundlegende Funktionen wie Caching und Inhaltskomprimierung nutzen möchten. Bei NGINX sind Inhalts-Caching und Komprimierung ohne zusätzliche Kosten sowohl in Open Source als auch in NGINX Plus enthalten. Wir vergleichen hier also die Enterprise Edition von Citrix NetScaler, weil diese eine bessere Funktionsparität mit dem bietet, was in NGINX Plus bereitgestellt wird, und wir sehen hier die gleichen Kosteneinsparungen wie beim F5, wenn wir Citrix NetScaler durch NGINX Plus ersetzen.

Sie erhalten dieselben Funktionen und die gleiche Leistung, die Sie erwarten, zahlen jedoch im ersten Jahr 89 % weniger. Sogar im fünften Jahr sparen Sie noch 75 % sowohl bei den Kosten für die Hardware (in diesem Fall Standardserver von Dell) als auch bei den Kosten für ein Abonnement der NGINX Plus-Software.

Eine wichtige Kennzahl, über die Hardwareanbieter viel sprechen, sind SSL-Transaktionen pro Sekunde oder die Anzahl der neuen SSL-Verbindungen, die pro Sekunde hergestellt werden können. Innerhalb dieser Plattformen wird diese Zahl normalerweise durch Hardware beschleunigt. Deshalb verfügen NetScaler und F5 BIG‑IP über spezielle Hardware zur Beschleunigung von SSL-Transaktionen, was die Kosten dieser Plattformen in die Höhe treibt.

Wir sehen, dass wir sogar mit einer Softwarelösung – ohne Hardwarebeschleunigung, nur durch Nutzung der Rechenleistung der CPU – mit der kundenspezifischen Hardware mithalten können. Wir ermöglichen erhebliche Kosteneinsparungen mit der Leistung, die Sie auch von hardwarebeschleunigten Lösungen erwarten würden.

Das ist also Grund Nr. 1: Sie können eine Menge Geld sparen, indem Sie zu NGINX Plus wechseln. Aber es geht nicht nur um Geld.

26:52 Grund Nr. 2 – DevOps erfordert die Bereitstellung von Softwareanwendungen

Mit einer softwarebasierten Lösung erhalten Sie außerdem ein hohes Maß an Flexibilität, und Grund Nr. 2 für die Umstellung auf einen softwarebasierten Load Balancer besteht darin, dass Sie bei der Umstellung auf DevOps wirklich Software zur Anwendungsbereitstellung benötigen.

Bei F5 und NetScaler werden diese Geräte in großen Unternehmen normalerweise als Aggregationspunkt eingesetzt. Daher wird eine Menge unabhängiger Datenverkehr darüber abgewickelt. Dasselbe F5 BIG‑IP kann für den Lastenausgleich von Netzwerk-Firewalls, für den Lastenausgleich der E-Mail-Server des Unternehmens, für den Lastenausgleich mehrerer verschiedener Back-End-Unternehmensanwendungen und auch für den Lastenausgleich der nach vorne gerichteten Unternehmensanwendung sorgen. Es könnte sich um Lastausgleichs-APIs in einer Microservices-Architektur handeln. Es kann also um den Lastenausgleich vieler Dinge gehen.

Oberflächlich betrachtet scheint dies eine gute Architektur zu sein, da sie ziemlich einfach ist: Sie lassen einfach alles über F5 laufen. Dies hat lange Zeit funktioniert, insbesondere in den frühen 2000er Jahren, als sich alles um private Rechenzentren drehte und wir alle unsere Anwendungen – also alles, worauf sich das Unternehmen verließ – in einem Rechenzentrum vor Ort ausführten. Doch in den letzten Jahren hat sich einiges geändert und mittlerweile wird das meiste in die Cloud verlagert.

Wenn ich Cloud sage, meine ich nicht nur das Hosten einer nach vorne gerichteten Webanwendung innerhalb von Amazon, sondern auch die Nutzung von Dingen wie Salesforce und Office 365 im Gegensatz zu lokalen CRM-Systemen und lokalen E-Mail-Servern. Daher kann es für das, was die Leute heutzutage tatsächlich verwenden, übertrieben sein, ein Gerät zu haben, das alle diese Dinge kann.

Ein zweites Problem dieser Aggregation besteht darin, dass diese Geräte dadurch sehr gut gesperrt werden. Sie zögern dann sehr, Änderungen daran vorzunehmen, denn wenn Sie die F5-Konfiguration durcheinanderbringen, kann dies das gesamte Unternehmensnetzwerk lahmlegen. Dies können beispielsweise Lastenausgleichsserver für E-Mail-Server oder Netzwerk-Firewalls sein. Dadurch wird die Konfiguration zu einer riskanten Angelegenheit und Änderungen müssen stark eingeschränkt und gesichert werden.

Jeder, der Änderungen vornehmen möchte, muss normalerweise ein IT-Ticket einreichen. Dies kann je nach Organisation und der Priorität, die die Organisation der angeforderten Änderung beimisst, Stunden, Tage oder Wochen dauern.

Die Nutzung dieser extrem abgeriegelten Hardware erschwert die Umstellung auf DevOps enorm. Wenn Sie DevOps einsetzen und in Richtung Automatisierung und kontinuierliche Integration gehen, gehen Sie dazu über, Code deutlich häufiger zu veröffentlichen. Und wenn Sie jedes Mal, wenn Sie eine Änderung vornehmen möchten, ein IT-Ticket einreichen müssen, wird diese Initiative dadurch gehemmt und vereitelt.

In vielen Organisationen beobachten wir, dass die für die Anwendung verantwortlichen Personen, die in Richtung DevOps und Agile-Entwicklung wechseln möchten, es nicht ertragen können, jedes Mal ein Ticket einreichen zu müssen, weil das den DevOps- und Agile-Initiativen im Wege steht. Daher setzen sie manchmal Open Source NGINX ein und lassen F5 BIG‑IP darauf verweisen. Die NGINX-Instanz wird dann von DevOps oder dem Anwendungsteam verwaltet, sodass sie Automatisierungen durchführen und ohne großen Aufwand Änderungen vornehmen können. Auf diese Weise können Sie die IT-Richtlinien des Unternehmens umgehen. Wir sehen natürlich, dass viele Kunden, nachdem sie das ausprobiert haben, zu NGINX Plus wechseln, um neben dem Support auch die erweiterten Funktionen zu erhalten.

NGINX unterstützt eine Reihe flexibler, unterschiedlicher Bereitstellungsmodelle, darunter auch solche, bei denen Sie Ihr aktuelles F5 beibehalten können. Sie können NGINX Plus verwenden, um den Lastenausgleich und die Bereitstellung von nach vorne gerichteten Webanwendungen, APIs und Mikroservices zu ergänzen und auszulagern, sodass F5 weiterhin den Netzwerklastenausgleich der E-Mail-Server des Unternehmens durchführen kann. Wenn Sie keine Netzwerkdienste und keinen Netzwerklastenausgleich benötigen, können Sie F5 natürlich auch einfach durch NGINX Plus ersetzen und haben dann eine einzige Lösung.

Wir unterstützen eine Reihe verschiedener Bereitstellungsmodelle, um Unternehmen bei der Umstellung auf DevOps, kontinuierliche Bereitstellung und Automatisierung zu unterstützen.

Was Grund Nr. 3 betrifft, gebe ich das Wort an Floyd zurück.

31:59 Grund Nr. 3 – Überall einsetzbar mit einem ADC

Floyd: Danke, Faisal.

Mit NGINX können Sie mit einer ADC-Lösung überall bereitstellen. Was bedeutet „überall“? Das bedeutet, dass Ihre lokalen Server, Ihre öffentliche Cloud, Ihre private Cloud oder Ihre Hybrid Cloud alle mit einer Lösung arbeiten. Und das hat sowohl einen praktischen als auch einen architektonischen Aspekt.

Zunächst einmal gilt alles, was wir gesagt haben, insbesondere dann, wenn Sie interne Server verwenden und nicht die Cloud nutzen. Viele Leute, die zu NGINX und NGINX Plus wechseln, um mehr Flexibilität und Funktionen zu erhalten und Geld zu sparen, befinden sich genau in dieser Situation: Sie stellen auf internen Servern bereit.

Wenn Sie die Cloud nutzen oder dies in Zukunft in Betracht ziehen, sind NGINX und der Hardware-ADC einfach nicht vergleichbar. Sie können Ihren Hardware-ADC nicht in die Rechenzentren von Amazon verschieben. Der Hardware-ADC wird Ihnen dabei nicht helfen.

Nun verfügen die Hardware-ADC-Entwickler zwar über einige softwarebasierte Lösungen, in manchen Fällen empfehlen sie jedoch lediglich, diese für die Entwicklung zu verwenden. Es ist kein Ersatz für den Hardware-ADC. Die Vorteile, die Sie in Bezug auf Einfachheit oder „Never change a running system“ sehen, verpuffen, wenn Sie in die Cloud wechseln möchten.

Mit NGINX und NGINX Plus ist die Anwendungsarchitektur unabhängig von der Bereitstellungsplattform. Bestimmte Cloud-Anbieter fügen immer mehr Dienste hinzu, auf die Sie über APIs zugreifen können. Während der Entwicklung ist das wirklich eine tolle Sache, weil Sie sich keine Gedanken darüber machen müssen, wie Sie etwas tun; Sie verwenden einfach die APIs für den Lastenausgleich, das Caching oder andere Funktionen. Wenn Sie dann jedoch skalieren, zahlen Sie für jede Transaktion einen kleinen Betrag.

Wenn Sie Tausende, Zehntausende und Hunderttausende von Transaktionen durchführen, summieren sich diese Zahlen plötzlich. Die Abrechnung ist sehr verwirrend und schwer vorhersehbar, insbesondere da sie auf dem Datenverkehr basiert, der immer variiert.

Wenn Sie einen auf NGINX oder NGINX Plus basierenden Ansatz verwenden, machen Sie auf jeder Plattform im Grunde dasselbe, und es macht kaum einen Unterschied, wenn Sie zu einem anderen Cloud-Anbieter oder wieder intern wechseln.

Wir haben tatsächlich Kunden, die einen Lastenausgleich zwischen ihren internen Servern und der Cloud durchführen. Also, wie sieht das aus? Sie erhalten genügend interne Server, um ihren Bedarf 80 bis 90 Prozent der Zeit zu decken. Wenn sie dann die Skalierung erhöhen müssen, müssen sie keine neuen Server kaufen oder anschließen; sie skalieren einfach in die Cloud.

Die Cloud ist normalerweise langsamer als Ihre Server vor Ort und da eine Lastverteilung erfolgt, werden nur die Sitzungen in die Cloud übertragen, die abgebrochen würden, wenn Sie nur Ihre internen Server verwenden würden. Sie haben eine etwas längere Latenz, werden aber verarbeitet und nicht in eine Warteschlange gestellt oder gelöscht.

Finanziell ist das großartig, weil Sie für die Cloud nur im Notfall zahlen, beispielsweise bei einem plötzlichen Anstieg des Datenverkehrs. Dies kann aufgrund von Berichterstattung in den Nachrichten passieren, wenn Ihr Produkt eine gute Bewertung erhält, oder Sie übertreffen Ihren Geschäftsplan dauerhaft und haben Ihre interne Kapazität noch nicht entsprechend erweitert, oder es sind gerade Ferien und es lohnt sich einfach nicht, doppelt so viele Server zu haben, wenn Sie das durch eine Skalierung in die Cloud erreichen können. Mit NGINX kann dies alles flexibel und sogar automatisch erfolgen.

35:42 Grund Nr. 4 – Passen Sie sich schnell an veränderte Anforderungen an

Mit NGINX können Sie sich schnell an die wechselnden Anforderungen Ihrer Anwendungen anpassen. Wenn Sie schnell Server oder Serverpaare für eine hohe Verfügbarkeit hinzufügen müssen, können Sie nicht warten, bis die Hardware bestellt, geliefert, empfangen und getestet wurde und Sie Ihre iRules oder welche Softwarekonfiguration auch immer dafür erforderlich ist, ausführen können. iRules ist außerdem proprietär – Sie benötigen iRules nur, wenn Sie einen F5-Server haben. Dies sind keine Fähigkeiten, die man direkt nach der Uni so einfach bei einer Anstellung finden kann. Wenn Ihr iRules-Mitarbeiter das Unternehmen verlässt, wird es schwierig sein, einen neuen zu finden.

Wenn es zu Konfigurationsänderungen kommt, können Sie oft nicht warten, bis die Änderungen vom Netzwerkbetrieb genehmigt werden. Sie möchten nicht, dass Ihre Änderungen mit weniger dringenden Dingen in die Warteschlange gestellt werden.

Mit NGINX ist der Aufwand für die Genehmigung neuer Projekte deutlich geringer. Mit NGINX und NGINX Plus können Sie zusätzliche Hardware im Schrank aufbewahren, wenn es sich um Server handelt, die 2.000 oder 3.000 $ kosten. Das ist nicht möglich, wenn es um mehrere Zehntausend Dollar für Hardware-ADCs geht.

Diese Art von Flexibilität, Redundanz und die Fähigkeit, das zu tun, was Sie tun müssen, wenn Sie es tun müssen, ist ein Kernmerkmal von NGINX und einer der Gründe, warum die Menschen, die uns nutzen, uns so sehr lieben.

37:08 Grund Nr. 5 – Keine künstlichen Leistungseinschränkungen

Schließlich gibt es mit NGINX keine künstlichen oder kontaktbedingten Leistungseinschränkungen. Für die NetScaler Enterprise Edition beträgt die vertraglich vereinbarte Durchsatzgrenze für diesen Server 0,5 Gbit/s. Nun, das ist in einer Unternehmenssituation lächerlich. Das vergleichbare NGINX-Setup, das auf Industriestandardhardware läuft, wird 20 Gbit/s unterstützen. Das ist das 40-fache des Citrix-Limits.

Der andere Punkt ist, dass die Citrix-Nummer eine vertragliche Einschränkung darstellt. Wenn Sie diesen Betrag überschreiten, erhöhen sich Ihre Zahlungsbedingungen plötzlich und drastisch. Die 20 Gbit/s sind eine Empfehlung unsererseits. Das bedeutet also, dass Sie, wenn Sie in diesen Bereich gelangen, möglicherweise bemerken, dass Ihre Leistung etwas nachlässt, und Sie denken möglicherweise, dass es eine gute Idee wäre, einen weiteren Server anzuschaffen und die Last darauf auszugleichen. Aber Sie haben die Flexibilität; Sie entscheiden. Ihr Budget wird nicht plötzlich gekürzt.

Mit Citrix ist es, als ob Sie gegen ein Stoppschild fahren. In diesem Szenario können mehr Geschäfte schlechte Nachrichten sein. Ein zusätzlicher Kunde kann Sie eine Menge Geld kosten, ein paar zusätzliche Kunden können Sie eine Menge Geld kosten, weil Sie dadurch diese Obergrenzen überschreiten. Wenn Sie NGINX verwenden, ist ein Anstieg Ihres Geschäfts eine gute Nachricht und Ihre Kosten steigen stetig mit Ihren erhöhten Einnahmen aus Ihrem größeren Kundenstamm.

Wir erhalten häufig dringende Anrufe von Personen, die diese Obergrenzen überschritten haben und plötzlich ihr Budget überschreiten. Und ohne große Veränderungen werden sie ihr Budget nicht wieder einhalten können. Dann müssen sie sich beeilen, auf NGINX zu kommen und wieder in eine gute Situation zu gelangen. Dann bleiben sie tatsächlich oft unter ihrem Budget, weil sie bei NGINX so viel Geld gespart haben.

Aber wer braucht diesen Ärger? Und die Ungewissheit und das Gefühl der Angst, wenn Sie plötzlich mit diesem schrecklichen Budget-/Leistungskonflikt konfrontiert werden? Wenn Sie frühzeitig auf NGINX umsteigen, können Sie davon völlig verschont bleiben.

40:00 Ressourcen

• Fallstudie – NGINX bei WordPress.com/Automattic
• Fallstudie – Montana Interactive verbessert App-Leistung und Kundenservice mit NGINX Plus
• Fallstudie – Wie Buydig.com seine Microsoft .NET-App skaliert und sichert, ohne eine einzige Codezeile zu ändern
• E-Book – 5 Gründe für die Umstellung auf Software zum Lastenausgleich
• Blog – NGINX Plus vs. F5 BIG-IP: Ein Preis-Leistungs-Vergleich
• Blog – NGINX Plus vs. Citrix NetScaler: Ein Preis-Leistungs-Vergleich
• Kostenlose Testversion von NGINX Plus