Wieso JAMStack-Hosting auch keine Lösung ist

Das Interesse am JAMstack wächst und viele Entwickler sind der Meinung, dass der JAMstack-Ansatz für die Webentwicklung, der in vielerlei Hinsicht schneller, sicherer und stabiler ist als der traditionelle Stack, die Zukunft des Webs darstellt. Aber er hat auch viele Nachteile und Probleme.

Im folgenden Artikel erkläre ich was ein JAMstack ist, wieso dieser entstanden ist und welche Vor- und Nachteile der Betrieb, insbesondere in Zusammenarbeit mit einem klassischen CMS wie WordPress mit sich bringt.

Definition: Was bedeutet JAMstack überhaupt?

Der Begriff JAMstack wurde von Mathias Biilmann Christensen, dem Mitbegründer von Netlify, geprägt, um “modernere” Ansätze der Webentwicklung im Gegensatz zum altbekannten LAMP-Stack zu beschreiben. JAMstack bezieht sich auf den serverlosen, datenbanklosen Stack, der aus Javascript, APIs und Markup besteht.

Der früher als statisch bekannte Stack wurde von Matt Biilmann als JAMStack rebranded, weil der Begriff statisch nicht mehr wirklich das beschreibt, was eine moderne statische Website tun kann, die dank moderner Javascript- und CSS-Funktionen eben auch sehr dynamisch sein kann.

Wie kam es dazu, dass eine Alternative zum LAMP-Stack gesucht wurde?

Bis etwa im Jahr 1999 bestanden die meisten Websites aus einfachem HTML, ein paar Bildern und CSS. Alles ziemlich einfach und überschaubar, die sogenannten statischen Websites. Diese waren schnell ausgeliefert und auch sehr sicher, denn auf dem Server wurde kein dynamischer Code ausgeführt, der Webserver hat dem Browser einfach die fertige HTML-Datei, die auf dem Server lag gesendet und das wars.
Allerdings waren Änderungen an statischen Seiten dafür relativ unkomfortabel. Die meisten Webentwickler haben den HTML-Quelltext in einem Texteditor verändert und die geänderte Datei per FTP auf den Webserver übertragen. Einem Kunden ohne technisches Verständnis war es quasi unmöglich eine Webseite zu pflegen, an die gleichzeitige Arbeit mehrerer Personen an ein und der selben Seite war überhaupt nicht zu denken!

Die ersten dynamischen Funktionen wurden über das sogenannte Common-Gateway-Inferface, kurz CGI im Apache Webserver ermöglicht, der bereits seit 1993 in Arbeit war. So verschickten meine ersten Webseiten damals ausgefüllte Kontaktformulare noch über ein kleines PERL-Script via sendmail. Mit dem Erscheinen von PHP verbreitete sich diese Art der dynamischen Webseiten und schnell wurden Web-Content-Management-Systeme erschaffen, die bis heute noch auf dem LAMP-Stack, also Linux, Apache, MySQL und PHP laufen. Statt Apache kommt mittlerweile häufig der modernere NGINX zum Einsatz und anstelle MySQL darf es auch gerne mal eine MariaDB sein.

Ohne entsprechende Vorkehrungen löst in dieser Art von Setup jedoch jeder Seitenaufruf eine Kaskade von Datei- und Datenbankzugriffen sowie PHP-Funktionen aus, die die Generierung der Webseite immer langsamer machten. Um dieses Problem in den Griff zu bekommen, wurden auf den unterschiedlichsten Stufen des Stacks Caches implementiert, von Festplattencaches über Datenbank-Cache, Object Caches und FullPage Caches bis hin zu CDNs und dem lokalen Browser Cache wird so viel wie möglich abgelegt, damit erneute Auslieferung der selben Information beschleunigt erfolgen kann. Modernes WordPress-Hosting ist durch die vielen Caches immer komplexer im Betrieb und durch die Notwendige Invalidierung der Caches in einigen Fällen auch nicht mehr so viel schneller, spart aber CPU-Zeit auf dem Host-System.

Das größere Problem des aktuellen LAMP-Stacks ist aus meiner Sicht die Software-Sicherheit: Nahezu täglich erscheinen Sicherheitspatches, Updates oder 0-Day Exploits zu WordPress Plugins, Themes oder auch dem Core. Eine permanente Aktualisierung wird immer aufwändiger und kann bei kritischer Infrastruktur nur selten automatisiert und ohne anschließende Funktionskontrolle ablaufen.

Letztendlich ist auch noch die Skalierung von dynamischen Seiten eine große Herausforderung: Wenn Sie eine Website betreiben und es Lastspitzen oder gar einen Ddos-Angriff gibt, ist es definitiv eine Herausforderung, die Website schnell bzw. überhaupt am Laufen zu halten. Eigentlich sollte man sich doch über große Traffic-Zuwächse freuen und keine Angst haben, dass die Website dadurch zum Erliegen kommt.

Schauen wir uns also den JAMstack genauer an. Löst dieser die Probleme des LAMP-Stacks?

Statische Seitengeneratoren lösen in der Tat viele dieser Probleme, schaffen jedoch einige neue Probleme! JAMstack ist im Grunde nichts anderes als die Kombination von Javascript, APIs und Markup wie HTML und CSS. Damit entfällt die Notwendigkeit einer dynamischen serverseitigen Programmiersprache wie PHP, Perl, Python oder Ruby. Damit braucht man eigentlich auch keinen (klassischen) Server mehr. Natürlich müssen die Dateien irgendwo für die Nutzer bereit gestellt werden, das geschieht im JAMStack jedoch einfach auf einem PushCDN und damit weltweit verteilt und sehr nach an jedem potentiellen Besucher.

Geschwindigkeit: Jede Seite liegt also bereits vorgerendert im CDN, was die Auslieferung wirklich schnell macht! Das PHP muss nichts verarbeiten, keine Datenbank abgefragt werden, keine CPU muss etwas Rechnen und kein RAM kann überlaufen!

Sicherheit: Ohne seitengenerierenden Verarbeitungsserver entsteht automatisch auch mehr Sicherheit! Denn es entfallen etliche anfällige Anwendungen der LAMP-Architektur. Wo normalerweise alles laufend gepatcht werden muss, von Datenbank und Betriebssystem des Servers über PHP und CMS bis hin zu Plugins und Themes. Diese Patches gibt es in der Welt von JAMstack einfach nicht, da JAMstack 100% datenbankfrei ist.

Skalierbarkeit: Wenn Sie nur statische Assets bereitstellen müssen, die keine serverseitige Verarbeitung erfordern, können Sie sie über ein weltweites CDN fast unendlich skalieren. Da dies viel weniger Ressourcen wie Rechenzeit, Strom und Kühlung verbraucht ist serverless Hosting noch dazu besser für die Umwelt.

Günstiger: Es gibt viele kostenlose oder kostengünstige Dienste für das Hosting statischer Websites. Diese Kosten können sich natürlich summieren, wenn man sehr viel Traffic hat, unter dem Strich sind die Kosten aber viel geringer als bei herkömmlichem Hosting!

Das klingt zu gut um wahr zu sein! Gibt es denn auch Nachteile?

Oh ja, die gibt es. Statische Site-Generatoren erfordern häufig die Benutzung der Kommandozeile oder müssen über umständliche APIs ohne GUI bedient werden. Es gibt zwar mittlerweile einige CMS, die du mit einem statischen Website-Generator verbinden kannst, aber sie sind viel eingeschränkter als das, was beispielsweise ein WordPress zu bieten hat.

Nach jeder Änderung auf der Webseite muss die gesamte Webseite neu generiert und auf das CDN gepusht werden. Das kann bei komplexen Webseiten sogar einige Stunden dauern, was häufige Veröffentlichungen oder schnelle Änderungen unmöglich macht. Das heißt: Wenn du eine Änderung auf einer Seite vornimmst, musst du deine gesamte Seite neu veröffentlichen und warten, bis sie fertig ist, bevor du eine weitere Änderung vornehmen kannst! Dadurch sind auch keine parallelen Arbeiten mehrere Autoren möglich.

Wer den LAMP-Stack für kompliziert hält, sollte sich erst garnicht am JAMStack versuchen. Die Kombination aus Headless CMS, Static-Site-Generator und Front-End mit clientseitiger Dynamisierung über APIs ist extrem komplex zu entwickeln. Es ist sehr schwierig Entwickler mit den notwendigen Fähigkeiten zu finden. Noch dazu exisiert aktuell noch ein sehr begrenztes Plugin- und Theme-Ökosystem. Im Gegensatz zu WordPress, wo es mehr als 50.000 Plugins und Millionen von Themes und fantastische Theme-Buildern wie Elementor gibt.

Damit Du einen Eindruck von der Komplexität bekommst, die der JAMStack mit sich bringt, schau Dir einfach mal das Tutorial Migrate Your WordPress Site to the Jamstack bei Netlify an 😀

Willst Du die Vorteile des JAMStacks einmal ausprobieren und trotzdem nicht auf den gewohnten Komfort einer WordPress Installation zu verzichten, hast Du derzeit drei Möglichkeiten:

1. WordPress als headless CMS mit Gatsby

Falls Du WordPress trotzdem unbedingt als Headless CMS nutzen willst, solltest Du Dir unbedingt mal das neue Projekt: Gatsby WordPress Themes anschauen. Damit kann man sehr viel Zeit sparen, indem man einfach ein fertiges Gatsby Theme basierend auf beliebten WordPress Themes verwendet.

Dieser Ansatz macht es sehr viel einfacher WordPress als headless CMS im JAMStack zu verwenden, um deine Seite zu verwalten und mittels Gatsby ein React-Frontend einzusetzen. Bislang gibt es zwar noch nicht viele Themes, aber das kann ich ja noch ändern.

Theoretisch kann man auch den Gatsby-Blog (eine vorgefertigte JAMstack-Website) auf Cosmic JS installieren und dann über einen Importer die vorhandenen WordPress-Beiträge importieren und die Webseite anschließend über Netlify bereitstellen. Eine Anleitung hierzu findest Du hier. Dabei verlierst Du aber eine Menge Funktionalität und es gibt keinen Weg mehr zurück zu WordPress!

2. WordPress mit einem WordPress Static Site Generator Plugin

Es gibt zwei WordPress-Plugins, die dir helfen können, eine statische Version deiner Seite zu erstellen. Besser gesagt gab, denn Simply Static und WP2Static werden beide nicht mehr weiterentwickelt. Im Falle von WP2Static gibt es aber wenigstens noch eine aktive Community und Support in einem Forum auf https://staticword.press/.

3. WordPress als a Static-Site-Generator auf einem Serverless Hosting bei strattic

Der aktuell wohl einfachste Weg, um sowohl von WordPress, als auch dem JAMstack zu profitieren, ist die Nutzung einer Plattform wie strattic, die deine WordPress-Seite in eine statische Seite verwandelt und sie auf eine serverlose Architektur stellt.

Das tolle an dieser Plattform ist, dass du deine WordPress-Seite wie gewohnt benutzt und dann auf einen Button klickst, um eine statische Version deiner Seite (HTML, CSS, Javascript) in ein CDN hochzuladen, wodurch die statische Seite vorgerendert und überall superschnell ausgeliefert wird. Dieser Ansatz macht es wirklich einfach auf den JAMStack zu switchen, aber leider bringt auch diese Variante ihre Nachteile mit sich:

Derzeit gibt es bei strattic weder Ajax-Funktionalität, noch die Möglichkeit Logins, Kommentare oder soetwas wie Mitgliedsseiten zu betreiben, von E-Commerce und Onlineshop mit WooCommerce ganz zu schweigen.

Mein Fazit

Der Ansatz von JAMstack bietet wirklich spannende neue Möglichkeiten, Webseiten ins Web zu bringen, die schnell, sicher und skalierbar sind, aber was nützt das, wenn man dafür nicht sein geliebtes CMS, WordPress einsetzen kann oder auf wichtige Funktionen verzichten muss?

Mein Fazit lautet daher: Der JAMStack ist technisch durchaus interessant, aber für derzeitige WordPress-Nutzer leider (noch) nichts für den Praxiseinsatz!

Mal sehen wie sich derzeit existierende JAMstack-Lösungen für WordPress wie stattic oder die Gatsby Themes entwickeln und wir vielleicht irgendwann sowohl die Vorteile von WordPress, als auch die des JAMstacks nutzen können.

Was meint ihr? Wird das noch was mit JAMStack und WordPress? Schreibt es mir in die Kommentare!

6 Gedanken zu „Wieso JAMStack-Hosting auch keine Lösung ist“

  1. P.S.
    “Dafür holt man sich aber keine zusätzliche Komplexität ins Haus.”
    Ich bin mir jetzt nicht sicher ob wir über das gleiche Reden. Jeder der HTML und JS kann, sollte auch mit einem JAMStack zurechtkommen. Ich sehe gerade beim JAMStack keinerlei zusätzliche Komplexität. Eher das Gegenteil. Man muss sich nur vom Kopf her umstellen und halt mal verstehen was der JAMStack da so bietet (schnell, sicher und skalierbar) und wie man seine freigewordene Entwicklerkapazität für den Webseitenbesucher sinnvoll nutzen kann (SPA, PWA, Lazy Loading, Grafik, Useability etc.).

    Klar, neue APIs lernen kann schwierig sein, aber wenn wir ehrlich sind: APIs sind im Regelfall meilenweit besser dokumentiert als jedes WP Plugin. Und mit APIs ist es genauso wie mit Plugins. Mal gut mal schlecht. Auf beiden Seiten also wohl der gleiche Aufwand was “gutes” zu finden.

    1. Wie editiere ich Inhalte? Wie lege ich neue Seiten an? Wie füge ich die neue Seite dann ins Menü auf allen anderen Seiten ein? Hier kommen wir ohne CMS wieder in die Probleme der Zeiten VOR den Web Content Management Systemen. Und MIT CMS gibt es aktuell, zumindest im Falle von WordPress, eben durch die fehlende Unterstützung im WP Core wenig Möglichkeiten für persistente Speicherung von Nutzerinterationen.

      Mit der Entwicklung neuer Themes und besserem Support durch die WP REST API kann sich das in Zukunft durchaus noch ändern.

  2. Ähm, ja … was bringt einem “schnell, sicher und skalierbar”? Schlüsselfaktoren für zufriedene Kunden (Webseitenbesucher und Projektgeber)? Klar, der arme Entwickler der seit 10 Jahren nur noch PHP kennt/sieht/macht ist mit soviel positivem überfordert, der hat natürlich die A*-Karte gezogen.

    Sorry, aber der Artikel ist sehr Entwickler Ego bezogen und enthält meines Erachtens nach viele Fehler.

    1. Hey Chris,
      ich sage nicht, dass schnell, sicher und skalierbar nicht richtig ist, das kannst Du mit dem klassischen LAMP-Stack aber auch alles erreichen. Mit einer WAF und einem Pull CDN wie CloudFlare, einem Managed Hosting und ordentlichem Fullpage Caching im NGINX kommt das eine gute gebaute WordPress-Seite auch super hin. Dafür holt man sich aber keine zusätzliche Komplexität ins Haus.
      Noch dazu verlagert man mit den meisten JAMStack Frameworks sehr viel Komplexität und notwendige Rechenzeit ins Frontend, also zum Nutzer, was in Sachen Rendering-Performance auch nicht immer des Weisheits letzter Schluß ist 😉

      1. Hallo Hr. Spriestersbach,

        ihr Fazit liesst sich allerdings so, als ob “schnell, sicher und skalierbar” unwichtiger sind, als wie irgendwelche CMS Funktionen.

        “…schnell, sicher und skalierbar sind, aber was nützt das, wenn man dafür nicht sein geliebtes CMS, WordPress einsetzen kann oder auf wichtige Funktionen verzichten muss”

        Das finde ich halt ein etwas fragwürdiges Fazit und ist meines Erachtens nach nur für den Entwickler etwas Positives (der Entwickler muss nicht sein CMS verlassen und er muss auch nicht selber mal “arbeiten” (ggf. mal eine Funktion selber schreiben die halt gerade fehlen könnte anstelle von Plugins nutzen.)).

        Wegen: “JAMStack Frameworks sehr viel Komplexität und notwendige Rechenzeit ins Frontend”
        Finde ich auch. Die meisten Frameworks sind total überlastet, nicht verständlich und überkompliziert. Mit einem vernünftigen Framework lässt sich dass allerdings umgehen und recht einfach auch einen +90 Page Speed erreichen (Google Analytics & Co inkl.).

        P.S. Skalierbarkeit erhält man mit LAMP nur recht schwierig.Ihre Ausführung um “schnell, sicher und skalierbar” zu sein (WAF, CDN, etc.) hört sich jetzt alles andere als einfach an, was im Jamstack (meistens) schon “Out-of-the-box” vorhanden ist.

      2. Das lesen Sie aus meinem Fazit vielleicht heraus. Ich sage damit allerdings nur, dass es für WordPress-Nutzer aus meiner Sicht derzeit einfach keine sinnvolle Möglichkeit ist den JAMStack einzusetzen.

        Ein Pull CDN wie CloudFlare ist mit der Einrichtung des DNS-Records und Anlegen eines Accounts getan. Eine WAF sollte jeder gute Hoster aus meiner Sicht anbieten und regelmäßige Updates und Backups sind für die allermeisten Sicherheitsprobleme ein ausreichender Fix.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.