5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Floyd SmithLeiter Content-Marketing

Dieser Beitrag basiert auf einem Webinar von Floyd Smith und Faisal Memon von NGINX, Inc. Unser neues E-Book zu diesem Thema steht zum Download bereit.

Inhaltsverzeichnis

0:00 Einführung

Floyd Smith: Hallo und herzlich willkommen zu unserer Präsentation. Wir sind hier bei NGINX und sprechen heute über mein E-Book 5 Gründe für den Umstieg auf softwarebasiertes Load Balancing.

Heute halten wir diese Präsentation zu zweit. Ich bin Floyd Smith, Technical Marketing Writer bei NGINX. Zuvor war ich als Senior Technical Writer bei Apple tätig und habe mehrere Bücher über verschiedene Aspekte der Technologie verfasst.

Faisal Memon: Hallo, ich bin Faisal Memon und arbeite hier bei NGINX im Produktmarketing. Ich bin seit etwa einem Jahr hier. Bevor ich zu NGINX kam, war ich als Technical Marketing Engineer bei Riverbed und Cisco tätig. Meine berufliche Laufbahn begann ich als Entwickler in C. Anschließend arbeitete ich etwa acht Jahre lang als Software Engineer bei Cisco.

1:38 Wer sind Sie?

Floyd: Wir erhalten bereits vor der Durchführung unserer Webinare Anmeldungen und können die Berufsbezeichnungen, Organisationen und Gründe für die Teilnahme sehen, die Sie jeweils angegeben haben.

Es war wirklich interessant, sich die Berufsbezeichnungen der Teilnehmenden anzusehen. Mit dabei sind Solution Architects – verschiedene Arten von Architekten –, Linux-Administratoren, technische Leiter, ein CEO, ein Senior Agile Delivery Manager, mehrere Personen mit DevOps-Berufsbezeichnungen, ein Full-Stack-Softwareentwickler, ein Ingenieur, ein Wissenschaftler, ein Entwickler und ein Marketing Operations Manager.

Wir haben eine wirklich gute Mischung aus technisch versierten Teilnehmenden. Ich habe den Eindruck, dass die Teilnehmenden dieses Webinars sehr praxisnah mit der Technologie arbeiten und unmittelbar mit den Herausforderungen konfrontiert sind, über die wir heute hier sprechen.

Außerdem ist eine erfreulich große Bandbreite an Organisationen vertreten. Einige von Ihnen befassen sich möglicherweise damit, um Ihre Kunden bei fundierten Entscheidungen beraten zu können, doch die meisten von Ihnen scheinen sich direkt und intern damit auseinanderzusetzen.

3:53 Von Hardware zu Software

Der Markt für Hardware-ADCs schrumpft laut Finanzberichten. Daher versuchen die Anbieter von Hardware-ADCs, ihren Umsatz pro Kunde zu steigern, während ihr Kundenstamm zurückgeht. Viele Kunden von Hardware-ADCs stellen allmählich fest, dass sie nicht zu einem immer kleiner werdenden Kreis von Kunden gehören möchten, die für die von diesen Hardware-ADCs bereitgestellten Dienste immer mehr bezahlen. Sie erkennen zunehmend, dass sie dasselbe mit Software sogar besser umsetzen können und dabei noch mehr Flexibilität gewinnen. Wer von Ihnen DevOps in seiner Berufsbezeichnung trägt, weiß vermutlich, was ich meine.

Wir bei NGINX erleben häufig, dass Kunden den Termin für die Vertragsverlängerung ihres Hardware-ADCs erreichen oder dass der Datenverkehr und damit auch die Kosten plötzlich stark ansteigen. Dann versuchen sie fieberhaft, aus dem Vertrag herauszukommen, und müssen alles sehr schnell erledigen. Meist gelingt ihnen das zwar, doch es ist stressig, ungeplant und nicht im Budget vorgesehen. Mithilfe dieser Präsentation können Sie stattdessen einen besser geplanten Prozess einleiten.

Die Budgetfrage ist nicht ganz so kritisch, da Sie durch den Umstieg auf Software sehr viel Geld sparen. Der betriebliche Aufwand ist jedoch enorm. Sie können ihn deutlich reduzieren, indem Sie frühzeitig mit der Umstellung beginnen.

NGINX ist eine wirklich solide Alternative zu einem hardwarebasierten ADC. Ursprünglich wurde es entwickelt, um das C10K-Problem zu lösen. Dabei geht es darum, dass ein Webserver auf einem einzigen Computer 10.000 oder mehr gleichzeitige Verbindungen bedient. Vor NGINX war das unmöglich. Die Leute stellten eine Website online, sie wurde beliebt und brach dann zusammen. Das zu verhindern, war sehr, sehr, sehr schwierig, doch mit NGINX wurde es deutlich einfacher.

Unsere erste Open-Source-Version wurde 2004 in Russland veröffentlicht, wo NGINX [die Software] ursprünglich entwickelt wurde [Redaktion – 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), unsere Entwicklungsbüros befinden sich in Moskau. Darüber hinaus haben wir Niederlassungen im Vereinigten Königreich. Das Unternehmen wird von führenden Risikokapitalgebern der Branche unterstützt. Wir haben mehr als 800 Kunden und erst kürzlich die Marke von 100 Mitarbeitern erreicht.

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

Insgesamt laufen 160 Millionen Websites auf NGINX.

NGINX wird auf zwei verschiedene Arten eingesetzt. Einige Websites nutzen NGINX als Webserver, was auch der ursprüngliche Zweck war. Viele Websites setzen NGINX jedoch als Reverse-Proxy-Server ein. Dabei wird NGINX vor die bestehende Architektur geschaltet, um den Datenverkehr zu verarbeiten und an die Anwendungsserver weiterzuleiten. Damit ist der erste Schritt zum Lastausgleich getan, um den es heute gehen wird.

51 Prozent der 10.000 meistbesuchten Websites sind zu NGINX gewechselt. Doch woran liegt das? Warum wird NGINX unter den meistbesuchten Websites noch häufiger eingesetzt als unter allen Websites insgesamt?

Der Grund dafür ist, dass NGINX die beste Lösung für stark frequentierte Websites ist. Eine schnelle Möglichkeit, eine stark frequentierte Website zu retten, bei der Probleme auftreten, besteht darin, NGINX als Reverse-Proxy-Server vorzuschalten und anschließend darauf Load-Balancing auszuführen.

Im Laufe der Zeit können Sie entweder Ihre bestehenden Anwendungen auf NGINX umstellen oder NGINX bei der Entwicklung neuer Anwendungen auch für diese als Webserver einsetzen. Auf diese Weise haben wir diese Verbreitung bei stark ausgelasteten Anwendern erreicht, die ihren Webserver nicht aus einer Laune heraus wechseln. Sie haben Erfahrung mit anderen Webservern und wissen, wie man sie einsetzt, entscheiden sich aber dennoch für diesen Wechsel, weil NGINX ihnen so viele Vorteile bietet.

36 Prozent aller Websites auf Amazon Web Services verwenden NGINX. Es entwickelt sich gewissermaßen zu einem Standardtool. Viele beginnen heute mit NGINX und bleiben während des gesamten Projekts dabei.

Hier sind einige der Websites, die uns nutzen. Bei 160 Millionen Websites, die NGINX verwenden, können wir natürlich nicht alle auf einer einzigen Folie unterbringen. Zu unseren Partnern und Freunden zählen jedoch Netflix, Airbnb, Uber, die bereits erwähnten Amazon Web Services, Box, Pinterest und WordPress.

Alle diese Unternehmen, deren Kerngeschäft die Bereitstellung von Webinhalten ist und bei denen alles zuverlässig funktionieren muss, sind zu NGINX gewechselt.

8:48 Wo NGINX ins Spiel kommt

Sehen wir uns an, wo NGINX ins Spiel kommt.

Auf der rechten Seite sehen Sie NGINX als Webserver. In dieser Funktion nutzt NGINX ein Anwendungs-Gateway, über das verschiedene Arten von Anwendungsservern gemeinsam mit NGINX betrieben werden können. Als Webserver kann NGINX – je nach Anwendungsfall – etwa 10.000 gleichzeitige Verbindungen verarbeiten.

NGINX eignet sich aber auch als Reverse-Proxy-Server und bietet in dieser Funktion Caching, Lastverteilung und eine Reihe weiterer Möglichkeiten.

9:32 Moderne Webarchitektur

NGINX unterstützt Sie auch bei der Umstellung auf eine moderne Webarchitektur. Dabei kann es sich um die Migration von dreistufigen Architekturen im J2EE-Stil zu Microservices handeln. Ebenso können komplexe HTML- und SOAP-Protokolle durch schlankere Protokolle wie REST und Messaging ersetzt werden, die einen wesentlichen Bestandteil von Microservices bilden. Oder Sie wechseln von persistenten Bereitstellungen zu veränderbaren Bereitstellungen, die in Containern oder virtuellen Maschinen ausgeführt werden.

Anstelle einer festen, statischen Infrastruktur verfügen Sie in der Regel über einen Dienst, den Sie selbst betreiben. Dazu gehören Technologien wie SDN und NFV sowie die Cloud – insbesondere die Cloud. Statt umfangreicher Releases im Abstand von einigen Monaten gibt es alle paar Stunden eine kontinuierliche Bereitstellung. Und statt isolierter Teams, bei denen Entwicklung, Qualitätssicherung und Betrieb jeweils ihren eigenen Vorgesetzten unterstellt sind, herrscht eine DevOps-Kultur der gemeinsamen Verantwortung, in der alle mit anpacken und sich um bestimmte Aspekte jedes Problems kümmern.

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 Geschichte von DevOps ist eng mit NGINX verknüpft. Viele DevOps-Fachleute haben NGINX stets griffbereit und setzen es ein, wenn bei einer Bereitstellung Probleme auftreten.

Bei bestimmten Bereitstellungen müssen Sie die Anwendungskonfiguration überhaupt nicht ändern. Sie schalten einfach NGINX davor und leiten den Datenverkehr so an die Anwendungsserver weiter, dass diese ihn bewältigen können. Sie haben den Code nicht verändert und auch nicht die Kernfunktionalität gefährdet, wenn Sie unter Zeitdruck ein Leistungsproblem beheben müssen.

Ein Bereich, in dem DevOps und NGINX in der Regel gut zusammenspielen, ist der softwarebasierte Lastenausgleich, auf den wir noch eingehen werden. Er eignet sich hervorragend für Cloud-Bereitstellungen, aber auch für Ihre eigenen Server. Dabei stehen verschiedene Methoden zur Lastverteilung zur Verfügung. Hier gibt es einen Unterschied zwischen NGINX und NGINX Plus, auf den ich gleich näher eingehen werde.

Die Möglichkeit, NGINX im laufenden Betrieb neu zu konfigurieren, unterstützt die Serviceerkennung und gewährleistet eine hohe Verfügbarkeit. Die Serviceerkennung ist für Microservices und die Automatisierung unerlässlich. Dank der Neukonfiguration im laufenden Betrieb müssen Sie Benutzer nicht von einem Server trennen, um ihn zu konfigurieren – ein enormer Vorteil, wenn es darum geht, Ihre Kunden online zu halten.

Anwendungszustandsprüfungen warnen frühzeitig vor Problemen bei der Anwendungsbereitstellung, sodass Sie einen fehlerhaften Server kontrolliert herunterfahren können, anstatt zu riskieren, dass er einfach ausfällt und Benutzer abrupt getrennt werden. Hinzu kommt eine leistungsstarke, individuell anpassbare Überwachung. Auch sie macht Sie auf Probleme aufmerksam, sobald sie auftreten, damit Sie sie beheben können, bevor Ihre Kunden davon betroffen sind.

12:30 Funktionen von NGINX Plus

Was steckt in NGINX Plus?

Open Source NGINX ist also das ursprüngliche Produkt, und NGINX Plus ist das darauf aufbauende kommerzielle Produkt. Wir bei NGINX investieren mindestens 70 Prozent unserer Zeit in die Open-Source-Variante, die zugleich die Grundlage für die erweiterten Funktionen von NGINX Plus bildet.

Das Open-Source-Produkt umfasst das Routing von Anfragen, das die Kernfunktion eines Webservers darstellt, sowie Komprimierung, da diese die Auslastung eines Webservers und zugleich den Datenverkehr über das Netzwerk reduziert, was sehr wertvoll sein kann. Zur Gewährleistung der Sicherheit wird außerdem SSL unterstützt. Darüber hinaus bieten wir zwei eingebettete Skriptsprachen an: zum einen unser eigenes NGINX-JavaScript-Modul [früher nginScript genannt] und zum anderen Lua.

Es gibt einige Funktionen, die teilweise bereits in der Open-Source-Version von NGINX enthalten sind, in NGINX Plus jedoch erweitert wurden. Mit der Open-Source-Version von NGINX lässt sich der Lastenausgleich bereits recht gut umsetzen, NGINX Plus bietet jedoch einige zusätzliche, fortschrittlichere Funktionen. Ebenso können Sie die Open-Source-Version von NGINX als Edge-Cache und für Medienstreaming verwenden – mit NGINX Plus funktioniert dies sogar noch besser.

NGINX Plus bietet darüber hinaus mehrere eigene Funktionen. Dazu gehören die Überwachung des Anwendungszustands, eine grafische Benutzeroberfläche zur Visualisierung der Überwachungsdaten, Monitoring und Analysen, die RESTful-Konfigurations-API sowie einige fortschrittlichere Lastverteilungsverfahren.

Mit NGINX Plus erhalten Sie Zugang zu NGINX-Ingenieuren, die Sie bei Ihrer Arbeit unterstützen. Wenn Sie derzeit F5, Citrix oder ein ähnliches System verwenden, sind Sie diese Art von Support wahrscheinlich gewohnt. Für größere und stärker frequentierte Websites, bei denen selbst eine kurze Ausfallzeit hohe Kosten verursacht, kann dies entscheidend sein – und sich leicht bezahlt machen, wenn Sie dadurch auch nur einmal im Jahr einen kurzen Ausfall vermeiden.

14:41 Kundenfallstudie – WordPress.com

Sehen wir uns einige Fallstudien von Kunden an, die den Wechsel vollzogen haben.

WordPress.com nutzte F5 BIG‑IP, wechselte jedoch zu NGINX, da ein Lastausgleich mit mehr als 10.000 Anfragen pro Sekunde und Server erforderlich war. Dabei handelt es sich um das bereits erwähnte C10k-Problem, das NGINX seit mehr als zehn Jahren löst. Zu diesem Zeitpunkt war WordPress.com auf 1.000 Anfragen pro Sekunde und Server beschränkt. Sie können sich vorstellen, wie belastend das im Vergleich zu 10.000 oder mehr Anfragen war.

Wordpress.com verfügte über mehrere F5 BIG‑IP-Systeme und plante eine Erweiterung auf zehn Rechenzentren. Um eine hohe Verfügbarkeit zu gewährleisten, also im Grunde für jedes Rechenzentrum ein aktives Backup bereitzuhalten, wurden zehn Paare von BIG‑IP-Servern benötigt. Das war sehr teuer. Außerdem war eine Neukonfiguration im laufenden Betrieb erforderlich, damit Benutzer bei Konfigurationsänderungen nicht getrennt wurden.

Sie begannen mit der Umstellung auf NGINX, indem sie es zunächst auf Gravatar testeten, einer App, die Avatare für Benutzer bereitstellt. So konnten sie sich mit NGINX vertraut machen. Anschließend wechselten sie von ihren F5-Servern zu NGINX und profitierten dadurch von einem geringen und vorhersehbaren Arbeitsspeicher- sowie CPU-Bedarf.

Jetzt verarbeiten sie auf 36 NGINX-Servern mehr als 70.000 Anfragen pro Sekunde und 15 Gigabit pro Sekunde [Gbit/s]. In Spitzenzeiten können sie 20.000 Anfragen pro Sekunde und Server bewältigen. Außerdem können sie die Konfiguration im laufenden Betrieb ändern und Aktualisierungen durchführen.

Wenn Sie sich das Angebot ansehen, geht es lediglich um den Kostenunterschied bei einer kleinen Implementierung, bei der Sie mit NGINX erheblich sparen können. Bei zehn Serverpaaren ist der Unterschied jedoch gewaltig.

16:42 Kundenfallstudie – Montana Interactive

Montana Interactive entscheidet sich für NGINX Plus für hochverfügbaren Lastenausgleich. Tatsächlich ist es bei vielen Behördendienstleistungen einfacher, kostengünstiger und besser, sie online anzubieten. Wenn Sie schon einmal einen Termin bei der Kfz-Zulassungsstelle oder einer ähnlichen Behörde gebucht haben, wissen Sie, was ich meine. Über solche Websites können beispielsweise Wahlen und Steuerzahlungen abgewickelt werden.

Es gibt eine enorme Zahl solcher unverzichtbaren Behördendienstleistungen, und Montana ist ein sehr großer Bundesstaat mit einer relativ kleinen, über das gesamte Gebiet verstreuten Bevölkerung. Daher ist es sehr wichtig, diese Dienstleistungen online anzubieten, damit die Einwohner nicht sechs oder acht Stunden fahren müssen, um eine Behörde zu erreichen.

Montana stellte seine Dienstleistungen zunächst sehr konsequent auf Online-Angebote um, doch mit zunehmender Nutzung kam es immer häufiger zu Sitzungsabbrüchen. Aufgrund einer umfangreichen Anwendung für Steuerzahlungen traten vierteljährlich starke Spitzen im Transaktionsaufkommen auf. Mitten beim Ausfüllen eines umfangreichen Formulars wurde die Sitzung plötzlich unterbrochen und die gesamte Arbeit ging verloren. Wenn man gerade seine Steuererklärung erledigt oder einen anderen aufwendigen Vorgang bearbeitet, ist das ziemlich belastend.

Die Lösung bestand darin, von Servern mit Pound auf NGINX Plus umzusteigen, NGINX Plus auf verschiedenen Hypervisoren und in verschiedenen Rechenzentren einzusetzen und als dynamischen Reverse-Proxy zu betreiben, der Anfragen in Echtzeit weiterleitet und so ein besseres Traffic-Management ermöglicht. Durch den Umstieg auf NGINX Plus erzielten sie enorme Verbesserungen bei Geschwindigkeit, Flexibilität und Benutzerfreundlichkeit. Sie profitierten von der Neukonfiguration im laufenden Betrieb, lagerten die SSL-Verarbeitung auf NGINX-Server aus und verbesserten mithilfe einer rollenbasierten Verwaltung die Betriebsabläufe und die Sicherheit.

James Ridle von Montana Interactive war von der Leistungsfähigkeit von NGINX begeistert. Die Benchmark-Ergebnisse überwältigten ihn, und er konnte kaum glauben, wie viel mehr er mit NGINX über dieselben Server bewältigen konnte.

18:43 Kundenfallstudie – BuyDig.com

Dies ist eine weitere Fallstudie, die dem Kunden enorme Vorteile gebracht hat: BuyDig.com, eine E-Commerce-Website, die mit NGINX Skalierbarkeit und Sicherheit erreicht hat.

BuyDig.com verfügte über eine ältere .NET-Anwendung. Das Unternehmen wollte sie nicht ändern – und musste es auch nicht. Nach einem groß angelegten DDoS-Angriff wurde ihm klar, dass es ein schnelles, ausfallsicheres und einfach zu konfigurierendes Frontend mit besserer Leistung, Sicherheit und Skalierbarkeit benötigte.

Sie setzten NGINX Plus in der auf Amazon Web Services gehosteten Frontend-Anwendungsschicht ein. An ihren auf .NET basierenden Backend-Diensten mussten sie keinerlei Änderungen vornehmen. Und genau das ist der entscheidende Punkt: keine Änderungen – weder kleine Anpassungen noch geringfügige Umstände oder Risiken, sondern überhaupt keine.

Jetzt profitieren sie von hervorragender Performance und Sicherheit. Zur Anpassung von NGINX verwendeten sie Konfigurationssprachen. Mit TLS SNI und anpassbaren Protokollen sorgen sie für ein hohes Maß an Sicherheit. Seitdem gab es weder Leistungseinbußen noch Ausfallzeiten der Website, und sie sind mit der Performance äußerst zufrieden.

Das sind also nur einige Beispiele dafür, was NGINX Plus leisten kann.

20:10 E-Book – 5 Gründe für den Umstieg auf Software für den Lastenausgleich

Lassen Sie mich nun näher auf das E-Book eingehen. Ich gebe Ihnen einen kurzen Überblick über die Inhalte des E-Books. Anschließend erläutert Ihnen Faisal die ersten beiden, eher technischen Gründe für einen Wechsel, bevor ich danach wieder übernehme. Es gibt auch Links. Nach Abschluss des Webinars werden Ihnen diese Präsentation und die Aufzeichnung des Webinars zur Verfügung gestellt. Ich glaube, es dauert etwa einen Tag, bis die entsprechende E-Mail versendet wird.

Und über diesen Link hier gelangen Sie zur Downloadseite für dieses kostenlose E-Book. Um die Gründe vorab kurz zu nennen: Kosten senken, DevOps besser unterstützen, überall bereitstellen (auf Ihren eigenen lokalen Servern, in der Cloud, in einer Private Cloud – ganz wie Sie möchten), sich schnell anpassen können und keine merkwürdigen vertraglichen Einschränkungen – darauf werde ich noch näher eingehen. Doch nun übergebe ich an Faisal, der über Kostensenkungen sprechen wird.

21:22 Grund Nr. 1 – Kosten drastisch senken

Faisal: Danke, Floyd. Der erste der fünf Gründe ist, dass Sie Ihre Kosten drastisch senken können, wenn Sie für die Bereitstellung von Softwareanwendungen auf NGINX Plus umsteigen.

Mitte der 1990er-Jahre bestand die einzige Möglichkeit, eine Website zu skalieren, darin, einen größeren Server zu kaufen. Das war nicht nur unglaublich teuer, sondern auch unzuverlässig, da dieser einzelne Server zugleich einen Single Point of Failure darstellte.

Etwa zu dieser Zeit brachte F5 erstmals BIG‑IP auf den Markt und bot Websitebetreibern damit eine andere Architektur: Statt einen größeren Server zu kaufen, konnten sie BIG‑IP nutzen, um die Last auf mehrere kostengünstige Server zu verteilen. Das senkte die Kosten, da BIG‑IP und die kostengünstigen Server zusammen günstiger waren als ein einziger riesiger Server. Gleichzeitig erhöhte sich die Ausfallsicherheit, weil der zentrale Ausfallpunkt beseitigt wurde.

Das war eine großartige Architektur – revolutionär und damals praktisch die einzige Lösung auf dem Markt –, doch in den vergangenen 20 Jahren hat sich vieles verändert. Eine wesentliche Veränderung besteht darin, dass die Kosten für Server drastisch gesunken sind. Heutzutage kann man einen ziemlich leistungsstarken Server für weniger kaufen, als hier in der San Francisco Bay Area eine Monatsmiete kostet.

Die zweite große Veränderung besteht darin, dass es inzwischen Open-Source-Software wie NGINX gibt, die dieselben Funktionen bietet wie F5 BIG‑IP oder Citrix NetScaler. Mit Open Source erhalten Sie vergleichbare Funktionen wie bei diesen großen, teuren Appliances – und das kostenlos. Floyd hat bereits darauf hingewiesen, dass über 160 Millionen Websites NGINX verwenden. Und von den 10.000 meistbesuchten Websites läuft mehr als die Hälfte mit NGINX.

Damit verfügen wir nun über diese Open-Source-Software, die im Vergleich zu F5 nicht nur alle benötigten Funktionen bietet, sondern auch genauso skalierbar und zuverlässig ist wie jedes andere kommerzielle Produkt.

23:19 NGINX Plus im Vergleich zu F5 BIG‑IP

Anfang dieses Jahres habe ich einige Benchmark-Tests und Kostenanalysen durchgeführt. Hier ist ein Auszug daraus. Dabei wird die NGINX Plus-Software, die auf handelsüblicher Standardhardware ausgeführt wird – in diesem Fall von Dell –, mit verschiedenen Modellen des F5 BIG‑IP verglichen.

In diesem konkreten Beispiel geht es um den 2000S, das Einstiegsmodell des F5 BIG‑IP. Ich habe ihn mit zwei unterschiedlich dimensionierten NGINX Plus-Konfigurationen auf Dell-Servern verglichen: Eine bietet eine etwas geringere Leistung als der F5 BIG‑IP (die Leistungskennzahlen sehen Sie dort unten), während die andere nahezu die doppelte Leistung erzielt.

Wenn Sie sich nur die rechte Spalte ansehen, in der NGINX Plus die doppelte Leistung des 2000S bietet, erzielen Sie im ersten Jahr Einsparungen von 78 % – einschließlich der Hardwarekosten und des Wartungssupports für ein Jahr. Diese Kosteneinsparungen setzen sich bis zum fünften Jahr fort. Selbst nach fünf Jahren sind die Gesamtbetriebskosten von NGINX Plus mit dem Dell-Server um 58 % niedriger als beim F5.

24:37 NGINX Plus im Vergleich zu Citrix NetScaler

Ich habe denselben Kostenvergleich mit Citrix NetScaler durchgeführt. Hier vergleichen wir das NetScaler-Einstiegsmodell MPX‑5550 Enterprise Edition.

Beim Lizenzmodell von Citrix müssen Sie auf die Enterprise Edition-Lizenz upgraden, wenn Sie grundlegende Funktionen wie Caching und Inhaltskomprimierung nutzen möchten. Bei NGINX sind Inhalts-Caching und -Komprimierung sowohl in der Open-Source-Version als auch in NGINX Plus ohne Aufpreis enthalten. Daher vergleichen wir hier die Enterprise Edition von Citrix NetScaler, da deren Funktionsumfang besser mit dem von NGINX Plus vergleichbar ist. Wenn Sie Citrix NetScaler durch NGINX Plus ersetzen, erzielen Sie hier die gleichen Kosteneinsparungen wie bei F5.

Sie erhalten alle erwarteten Funktionen und die gewohnte Leistung, zahlen im ersten Jahr jedoch 89 % weniger. Selbst über einen Zeitraum von fünf Jahren sparen Sie noch 75 % – sowohl bei den Hardwarekosten (in diesem Fall handelsübliche Dell-Server) als auch bei den Kosten für ein Abonnement der NGINX Plus-Software.

Eine wichtige Kennzahl, über die Hardwareanbieter häufig sprechen, ist die Anzahl der SSL-Transaktionen pro Sekunde, also die Anzahl der neuen SSL-Verbindungen, die pro Sekunde hergestellt werden können. Auf diesen Plattformen wird dieser Wert in der Regel durch Hardwarebeschleunigung erhöht. Daher 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 stellen fest, dass wir selbst mit einer Softwarelösung – ohne Hardwarebeschleunigung und allein durch Nutzung der Rechenleistung der CPU – mit der Spezialhardware mithalten können. Wir ermöglichen erhebliche Kosteneinsparungen und bieten dabei die gleiche Leistung wie hardwarebeschleunigte Lösungen.

Das ist also Grund Nr. 1: Durch den Umstieg auf NGINX Plus können Sie viel Geld sparen. Aber es geht nicht nur ums 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. Grund Nr. 2 für den Wechsel zu einem softwarebasierten Load Balancer ist, dass Sie für die Anwendungsbereitstellung unbedingt Software benötigen, wenn Sie auf DevOps umsteigen.

F5 und NetScaler werden in großen Unternehmen üblicherweise als zentraler Aggregationspunkt eingesetzt. Daher läuft viel voneinander unabhängiger Datenverkehr darüber. Ein und dasselbe F5 BIG‑IP kann die Last auf Netzwerk-Firewalls, die E-Mail-Server des Unternehmens, verschiedene interne Unternehmensanwendungen und zugleich auf die öffentlich zugängliche Unternehmensanwendung verteilen. Auch APIs in einer Microservices-Architektur können damit lastverteilt werden. Es kann also für die Lastverteilung zahlreicher unterschiedlicher Systeme eingesetzt werden.

Auf den ersten Blick scheint dies eine gute Architektur zu sein, da sie recht einfach ist: Man leitet einfach alles über den F5. Lange Zeit hat das auch funktioniert, insbesondere Anfang der 2000er-Jahre, als sich alles um das private Rechenzentrum drehte und wir sämtliche Anwendungen – also alles, worauf das Unternehmen angewiesen war – in einem lokalen Rechenzentrum betrieben. Doch in den vergangenen Jahren hat sich vieles verändert, und inzwischen wird das meiste in die Cloud verlagert.

Wenn ich von der Cloud spreche, meine ich damit nicht nur das Hosting einer öffentlich zugänglichen Webanwendung bei Amazon, sondern auch die Nutzung von Diensten wie Salesforce und Office 365 anstelle lokaler CRM-Systeme und E-Mail-Server. Ein Gerät, das all diese Aufgaben übernehmen kann, ist daher für das, was heutzutage tatsächlich betrieben wird, möglicherweise überdimensioniert.

Ein zweites Problem dieser Bündelung besteht darin, dass diese Appliances dadurch sehr stark abgeschottet werden. Änderungen daran nimmt man nur sehr zögerlich vor, denn wenn man die F5-Konfiguration falsch einstellt, könnte das gesamte Unternehmensnetzwerk ausfallen. Die Appliance könnte etwa für den Lastenausgleich von E-Mail-Servern oder für Netzwerk-Firewalls zuständig sein. Dadurch wird die Konfiguration zu einer riskanten Angelegenheit, und Änderungen müssen stark eingeschränkt und streng kontrolliert werden.

Wer Änderungen daran vornehmen möchte, muss in der Regel ein IT-Ticket einreichen. Je nach Unternehmen und der Priorität, die es der gewünschten Änderung beimisst, kann die Bearbeitung Stunden, Tage oder Wochen dauern.

Diese extrem stark abgeschottete Hardware erschwert den Umstieg auf DevOps erheblich. Bei DevOps geht es um die zunehmende Automatisierung, die kontinuierliche Integration und darum, Code deutlich häufiger zu veröffentlichen. Wenn Sie jedoch jedes Mal ein IT-Ticket einreichen müssen, sobald Sie etwas ändern möchten, wird diese Initiative ausgebremst und letztlich zum Scheitern gebracht.

In vielen Unternehmen beobachten wir, dass die für die Anwendung verantwortlichen Personen, die DevOps und agile Entwicklung einführen möchten, nicht jedes Mal ein Ticket einreichen können, da dies die DevOps- und Agile-Initiativen behindert. Daher stellen sie mitunter die Open-Source-Version von NGINX bereit und lassen F5 BIG-IP darauf verweisen. Diese NGINX-Instanz wird dann vom DevOps- oder Anwendungsteam verwaltet, sodass es Prozesse automatisieren und unkompliziert Änderungen vornehmen kann. Auf diese Weise lässt sich die IT-Richtlinie des Unternehmens gewissermaßen umgehen. Sobald sie dies ausprobiert haben, wechseln natürlich viele Kunden zu NGINX Plus, um zusätzlich zum Support auch die erweiterten Funktionen zu erhalten.

NGINX unterstützt eine Reihe unterschiedlicher, flexibler Bereitstellungsmodelle, darunter auch solche, bei denen Sie Ihre bestehende F5-Lösung beibehalten können. Mit NGINX Plus können Sie den Lastausgleich und die Bereitstellung öffentlich zugänglicher Webanwendungen, APIs und Microservices ergänzen und auslagern, während F5 weiterhin den Netzwerklastausgleich für die E-Mail-Server Ihres Unternehmens übernimmt. Wenn Sie keine Netzwerkdienste und keinen Netzwerklastausgleich benötigen, können Sie F5 selbstverständlich auch einfach durch NGINX Plus ersetzen und so eine einheitliche Lösung nutzen.

Wir unterstützen eine Reihe unterschiedlicher Bereitstellungsmodelle, die Unternehmen bei der Umstellung auf DevOps, Continuous Delivery und Automatisierung helfen.

Für Grund Nr. 3 übergebe ich wieder an Floyd.

31:59 Grund Nr. 3 – Mit einem einzigen ADC überall bereitstellen

Floyd:Vielen Dank, Faisal.

Mit NGINX können Sie überall dieselbe ADC-Lösung einsetzen. Was bedeutet „überall“? Es bedeutet, dass Ihre lokalen Server sowie Public, Private oder Hybrid Clouds alle mit einer einzigen Lösung funktionieren. Dabei gibt es sowohl einen praktischen als auch einen architektonischen Aspekt.

Zunächst einmal gilt alles, was wir gesagt haben, in besonderem Maße, wenn Sie unternehmenseigene Server nutzen und keine Cloud einsetzen. Viele, die zu NGINX und NGINX Plus wechseln, um mehr Flexibilität und Funktionen zu erhalten und Kosten zu sparen, befinden sich genau in dieser Situation: Sie stellen ihre Anwendungen auf unternehmenseigenen Servern bereit.

Wenn Sie künftig die Cloud nutzen oder deren Nutzung in Betracht ziehen möchten, gibt es zwischen NGINX und einem hardwarebasierten ADC schlicht keinen Vergleich. Sie können Ihren hardwarebasierten ADC nicht in die Rechenzentren von Amazon verlagern. Dort hilft Ihnen ein hardwarebasierter ADC nicht weiter.

Nun bieten die Entwickler von Hardware-ADCs zwar einige softwarebasierte Lösungen an, doch in manchen Fällen empfehlen sie deren Einsatz nur für die Entwicklung. Sie sind kein Ersatz für den Hardware-ADC. Die vermeintlichen Vorteile hinsichtlich der Einfachheit oder nach dem Motto „Was nicht kaputt ist, muss man nicht reparieren“ lösen sich in Luft auf, sobald Sie in die Cloud wechseln möchten.

Mit NGINX und NGINX Plus ist die Anwendungsarchitektur unabhängig von der Bereitstellungsplattform. Einige Cloud-Anbieter bieten zunehmend mehr Dienste an, die sich über APIs einbinden lassen. Während der Entwicklung ist das äußerst praktisch, da Sie sich keine Gedanken über die konkrete Umsetzung machen müssen. Sie verwenden einfach die APIs des Anbieters, um den Lastenausgleich, das Caching oder andere Funktionen abzuwickeln. Bei der Skalierung fällt dann jedoch für jede Transaktion ein kleiner Betrag an.

Nun, wenn Sie plötzlich Tausende, Zehntausende oder Hunderttausende von Transaktionen durchführen, summieren sich diese Beträge. Die Abrechnung ist sehr unübersichtlich und schwer vorhersehbar, insbesondere da sie vom Datenverkehr abhängt, der ständig schwankt.

Wenn Sie einen auf NGINX oder NGINX Plus basierenden Ansatz verwenden, gehen Sie im Grunde auf jeder Plattform gleich vor, und beim Wechsel zu einem anderen Cloud-Anbieter oder zurück in die eigene Infrastruktur gibt es kaum Unterschiede.

Wir haben tatsächlich Kunden, die den Lastausgleich über ihre lokalen Server und die Cloud hinweg durchführen. Wie sieht das also konkret aus? Sie halten genügend lokale Server vor, um ihren Bedarf in 80 oder 90 Prozent der Zeit zu decken. Wenn sie dann skalieren müssen, brauchen sie keine neuen Server zu kaufen oder auch nur anzuschließen, sondern erweitern ihre Kapazitäten einfach in die Cloud.

Die Cloud ist in der Regel langsamer als Ihre lokalen Server. Da die Last auf alle Systeme verteilt wird, werden nur die Sitzungen in die Cloud verlagert, die bei ausschließlicher Nutzung Ihrer lokalen Server abgebrochen würden. Sie weisen zwar eine etwas höhere Latenz auf, werden aber verarbeitet und weder in eine Warteschlange gestellt noch abgebrochen.

Finanziell ist das äußerst vorteilhaft, da Sie die Cloud nur bei Bedarf bezahlen, etwa bei einem plötzlichen Anstieg des Datenverkehrs. Dieser kann durch Medienberichte oder eine positive Bewertung Ihres Produkts ausgelöst werden. Vielleicht übertreffen Sie aber auch dauerhaft die Erwartungen Ihres Geschäftsplans und haben Ihre interne Infrastruktur noch nicht entsprechend erweitert. Oder es ist gerade Weihnachtszeit und es lohnt sich schlicht nicht, doppelt so viele Server vorzuhalten, die Sie nur wenige Wochen im Jahr benötigen, wenn Sie stattdessen in die Cloud skalieren können. Mit NGINX lässt sich all dies flexibel und sogar automatisch umsetzen.

35:42 Grund Nr. 4 – Schnell auf veränderte Anforderungen reagieren

Mit NGINX können Sie sich schnell an die sich ändernden Anforderungen Ihrer Anwendungen anpassen. Wenn Sie kurzfristig Server oder Serverpaare für Hochverfügbarkeit hinzufügen müssen, können Sie nicht darauf warten, dass Hardware bestellt, geliefert, entgegengenommen und getestet wird und anschließend die erforderlichen iRules oder sonstigen Softwarekonfigurationen vorgenommen werden. Zudem ist iRules proprietär – Sie benötigen iRules nur, wenn Sie einen F5-Server einsetzen. Fachkräfte mit diesen Kenntnissen lassen sich nicht ohne Weiteres direkt von der Hochschule rekrutieren. Wenn Ihre für iRules zuständige Fachkraft das Unternehmen verlässt, wird es schwierig, Ersatz zu finden.

Bei Konfigurationsänderungen können Sie häufig nicht darauf warten, dass der Netzwerkbetrieb die Änderungen genehmigt. Schließlich möchten Sie nicht, dass Ihre Änderungen zusammen mit weniger dringenden Aufgaben in die Warteschlange gestellt werden.

Mit NGINX ist der Aufwand für die Genehmigung neuer Projekte deutlich geringer. Bei NGINX und NGINX Plus können Sie zusätzliche Hardware einfach in einem Schrank vorhalten, wenn es um Server geht, die 2.000 oder 3.000 US-Dollar kosten. Bei Hardware-ADCs, die mehrere Zehntausend US-Dollar kosten, ist das nicht möglich.

Diese Art von Flexibilität und Redundanz sowie die Möglichkeit, genau das zu tun, was Sie brauchen, und zwar dann, wenn Sie es brauchen, gehören zu den Kernmerkmalen von NGINX und sind mit ein Grund dafür, dass unsere Nutzer uns so sehr schätzen.

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

Schließlich gibt es bei NGINX keine künstlichen oder vertraglich bedingten Leistungseinschränkungen. Bei der NetScaler Enterprise Edition ist der Durchsatz dieses Servers vertraglich auf 0,5 Gbit/s begrenzt. Für den Einsatz in Unternehmen ist das schlichtweg absurd. Eine vergleichbare NGINX-Konfiguration auf branchenüblicher Hardware unterstützt 20 Gbit/s. Das entspricht dem 40-Fachen des Citrix-Limits.

Hinzu kommt, dass der Citrix-Wert eine vertraglich festgelegte Obergrenze darstellt. Wenn Sie diese überschreiten, steigen Ihre Zahlungsverpflichtungen plötzlich und drastisch an. Die 20 Gbit/s sind hingegen lediglich eine Empfehlung von uns. Das bedeutet: Wenn Sie sich diesem Bereich nähern, stellen Sie möglicherweise einen leichten Leistungsabfall fest und entscheiden sich vielleicht dafür, einen weiteren Server hinzuzunehmen und die Last darauf zu verteilen. Aber Sie bleiben flexibel und entscheiden selbst. Ihr Budget wird nicht plötzlich zusätzlich belastet.

Bei Citrix ist es, als würde man auf ein Stoppschild stoßen. In diesem Szenario kann mehr Geschäft eine schlechte Nachricht sein. Schon ein einziger zusätzlicher Kunde kann Sie viel Geld kosten, und einige weitere Kunden können Sie ebenfalls viel Geld kosten, weil Sie dadurch diese Obergrenzen überschreiten. Wenn Sie NGINX verwenden, sind mehr Aufträge hingegen eine gute Nachricht, und Ihre Kosten steigen gleichmäßig mit den wachsenden Umsätzen aus Ihrem größer werdenden Kundenstamm.

Wir erhalten häufig dringende Anrufe von Kunden, die diese Obergrenzen überschritten haben und dadurch plötzlich über ihrem Budget liegen. Ohne eine grundlegende Änderung werden sie ihr Budget nicht wieder einhalten können. Dann müssen sie in aller Eile auf NGINX umsteigen, um ihre Situation wieder in den Griff zu bekommen. Oft liegen sie anschließend sogar unter ihrem Budget, weil sie mit NGINX so viel Geld gespart haben.

Aber wer braucht schon diesen Ärger? Ganz zu schweigen von der Unsicherheit und dem unguten Gefühl, wenn man plötzlich in diesen schrecklichen Konflikt zwischen Budget und Leistung gerät. Wer frühzeitig zu NGINX wechselt, kann all das vollständig vermeiden.

40:00 Ressourcen

• Fallstudie – NGINX bei WordPress.com/Automattic
• Fallstudie – Montana Interactive verbessert mit NGINX Plus die Anwendungsleistung und den Kundenservice
• Fallstudie – Wie Buydig.com seine Microsoft-.NET-App skaliert und absichert, ohne eine einzige Codezeile zu ändern
• E-Book – 5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
• 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

Über den Autor

Floyd SmithLeiter Content-Marketing

Weitere Blogbeiträge von Floyd Smith