Dienstag, 9 Oktober 2023

Warum NGINX in der Cloud nicht effizient ist

Christoph Ebeling

Founder & Managing Director

Nach einigen Monaten stellen die meisten Unternehmen jedoch enttäuscht fest, dass viele der Probleme die sie on-premise hatten, auch weiterhin in der Cloud bestehen. Oftmals werden diese Probleme durch den Einsatz von virtuellen Maschinen verschärft, die weiterhin von Ops-Teams gewartet werden müssen und auch dann Kosten verursachen, wenn sie nicht genutzt werden. Dass diese sogenannten "Lift-and-Shift"-Migrationen solche Probleme mit sich bringen können, ist allgemein bekannt, wird jedoch im Einzelfall oft übersehen oder schlicht ignoriert.

Das klassische Webframwork in der Cloud

Ein typisches Szenario, bei dem nach einer "Lift-and-Shift"-Migration zu viel Geld ausgegeben wird und die Cloud-Vorteile nicht voll ausgeschöpft werden, ist das Hosting von statischen Dateien, wie z.B. HTML-Seiten, Bildern, JavaScript und CSS-Dateien – den sogenannten Assets. Diese Assets werden häufig weiterhin über Webserver wie NGINX oder Apache2 gehostet, die in Containern oder virtuellen Maschinen betrieben werden. Da es mittlerweile allgemein bekannt ist, dass das Ausliefern solcher statischen Assets über die klassischen Webserver weniger performant ist, greifen viele zum Einsatz von Content Delivery Networks (CDNs). Diese cachen die Assets auf speziellen CDN-Servern in der Nähe des Endbenutzers, um einen zeitaufwendigen und kostenintensiven Zugriff auf den ursprünglichen Webserver zu vermeiden.

Bei herkömmlichen, serverseitig gerenderten Anwendungen, die in der Regel über einen Webserver verfügen, der das Rendering von HTML, das Bereitstellen von Assets und Backend-Funktionalitäten wie das Speichern von Benutzerdaten in der Datenbank oder Sessionverwaltung übernimmt, ergibt sich eine vergleichsweise solide und kostengünstige Architektur. Beispiele hierfür sind Deployments von Django, Ruby on Rails oder Spring Boot auf Plattformen wie Elastic Beanstalk oder Heroku.

Architektur im Wandel

Mit dem Aufkommen von sogenannten Single Page Applications (SPAs) wurden diese Frameworks in den letzten Jahren jedoch durch Tools wie React und Next.js ergänzt. Das Deployment eines einzelnen Webservers, der sich um alle Aspekte einer Webanwendung kümmert, ist zunehmend unpraktisch geworden. Anstelle eines umfangreichen Frameworks wie Spring Boot oder Django, oft mit NGINX als Reverse Proxy, ziehen es viele vor, einen oder mehrere schlanke API-Server, wie z.B. Node.js oder Flask, in leichten Containern zu deployen. Dies reduziert nicht nur den Overhead und die Serverlast auf der Backend-Seite, sondern ermöglicht auch den Übergang zu einer Micro- oder zumindest Makroservice-Architektur. Diese kann schnell und dynamisch skaliert werden, wodurch die bekannten Vorteile der Cloud effizient genutzt werden können.

Cloud-Native Frontend-Deployment

Mit dem allmählichen Rückgang der monolithischen Webframeworks und dem Aufstieg kompakter, skalierbarer Backend-Services stehen viele Teams vor der Herausforderung, ihre Frontends effizient in der Cloud zu deployen. Da sich das Deployment auf der Backend-Seite über spezialisierte Container bereits bewährt hat erscheint es naheliegend, das Frontend ebenfalls über einen Container zu deployen. Dies ist in der Regel jedoch nicht notwendig, da es mittlerweile bessere Alternativen für das Hosting von statischen Ressourcen gibt.

Moderne Cloud-Anbieter bieten mittlerweile die Möglichkeit, über sogenannte Object Storages nicht nur Dateien hochverfügbar zu speichern, sondern diese auch über HTTPS bereitzustellen. Bei AWS kann man beispielsweise über S3 Website Hosting statische Dateien vollständig gemanagt und hochverfügbar im Internet bereitstellen. Die Vorteile sind offensichtlich: Man kann auf das teure Hosting über einen eigenen Webserver verzichten und spart sich die Wartungskosten. Ein NGINX-Server muss regelmäßig aktualisiert werden und verursacht potenzielle Sicherheitsrisiken und Kosten, selbst wenn er nicht genutzt wird (was bei Einsatz eines CDNs selbst bei hohem Traffic oft der Fall sein sollte). All diese Probleme entfallen bei einem "serverlosen" Deployment. Selbst wenn die Cloud-Kosten eines solchen containerbasierten Frontend Deplyoments regelmäßig nur im Bereich von EUR 80- 120 liegen dürften, ergibt sich durch das Wegfallen von Wartungs- und Betriebskosten dennoch eine erhebliche Ersparnis.

Wenn es doch einmal dynamisch sein soll

Hätte ich diesen Beitrag vor 2-3 Jahren geschrieben, wäre die Geschichte hier zu Ende. Doch auch moderne Single Page Applications entwickeln sich weiter. Der massive Anstieg des mobilen Traffics und die damit verbundenen Metriken, wie der sogenannte First Contentful Paint, erfordern in einigen Fällen, dass die eigentlich clientseitig gerenderten SPAs serverseitig "prerendert" werden. Das bedeutet, dass Operationen, wie das Generieren von HTML-Inhalten, die in Frameworks wie React eigentlich auf dem Client stattfinden sollten, bereits serverseitig durchgeführt werden. Während dieses Rendering für komplett statische Webseiten bereits im Build-Prozess erfolgen kann, gibt es Szenarien, in denen dies nicht möglich ist. Eine Webseite, die beispielsweise aktuelle Nachrichten veröffentlicht oder ein Content Management System (CMS) verwendet, wird häufiger aktualisiert, als ihr Deployment-Intervall vorgibt.

Doch auch für dieses sogenannte partielle Server-Side-Rendering gibt es mittlerweile Lösungen. Die meisten Cloud-Anbieter bieten programmierbare CDNs an. AWS CloudFront bietet beispielsweise die Möglichkeit, Inhalte mittels Lambda@Edge bereits auf CDN-Ebene zu rendern. Hier kommt sogenanntes Edge Computing zum Einsatz, das bisher hauptsächlich im Zusammenhang mit Use Cases wie autonomem Fahren und 5G bekannt war. Dies mag für den einen oder anderen nach einem komplexen Use-Case für ein einfaches Problem klingen. In der Realität kann es jedoch für Unternehmen mit hohem Traffic bedeuten, dass sie Petabyte an Traffic einsparen, was sich letztlich nicht nur in erheblichen wirtschaftlichen Einsparungen, sondern auch in einem reduzierten Energieverbrauch und somit in einer erhöhten Nachhaltigkeit niederschlägt.

Die Zukunft ist serverless

Die zuvor beschriebenen Hosting-Methoden sind keine technologischen Neuerungen, sondern sind in Tools wie dem Serverless Framework, Vercel (betrieben von den Next.js-Entwicklern) oder AWS Amplify bereits seit Jahren Best Practice. Um solche Innovationen jedoch außerhalb von Start-up-Greenfield-Projekten zu etablieren, bedarf es nicht nur eines tiefen Verständnisses für moderne Cloud-Technologien, sondern auch des Mutes und der Ambition, etablierte Technologien wie NGINX durch disruptive, neue Ansätze zu ersetzen. Nachdem wir bei Nexode in den letzten Jahren zahlreiche Deployments, wie z.B. das THG Portal des ADAC, auf einem entsprechenden Technologiestack durchgeführt haben, möchte ich mit diesem Artikel andere ermutigen, diesen Schritt ebenfalls zu gehen. Für alle, die dabei auf unser Wissen und unsere Erfahrung zurückgreifen möchten, werden wir in Kürze ein Terraform-Modul vorstellen, mit dem sich das JavaScript-Framework Next.js serverlos auf AWS deployen lässt. Hierzu in Kürze mehr.

Share this article!

NEXODE CONSULTING GmbH

OBERWALLSTRAßE 6

10117 BERLIN