Eine Tirade von Zed Shaw, dem Mann, der die ursprüngliche Version des Ruby-Anwendungsservers Mongrel schrieb, brachte mich dazu, über die Erfahrungen, die DreamHost in den letzten Jahren beim Hosting von Ruby on Rails-getriebenen Websites gemacht hat, nachzudenken. Die Tirade selbst war ziemlich lang, aber eine interessante (wenn auch selbstgefällige) Lektüre, wenn Sie entweder ein Ruby on Rails-Entwickler sind, ein Nerd, der einfach auf solche Dinge steht, oder sich für die Hintergründe eines hoch öffentlichen Open-Source-Projekts interessieren.
Ich habe nichts hinzuzufügen zu Zed Shaws Kommentaren darüber, wie das Rails-Entwicklungsteam arbeitet, da ich darüber keine persönlichen Kenntnisse habe. Was ich aus persönlicher Erfahrung weiß, ist, wie schwierig es sein kann, eine Rails-Anwendung zu starten und am Laufen zu halten. DreamHost hat über 10 Jahre Erfahrung in der Ausführung von Anwendungen in den meisten der beliebtesten Web-Programmierframeworks, und Rails war und ist eines der frustrierendsten.
Einige Geschichte
Als wir anfingen, unsere Unterstützung für Ruby on Rails zu implementieren, wollten wir alles tun, um es zu unterstützen. Es war ein aufregendes und neues Web-Framework, das die Entwicklung von Webanwendungen belebte. Ruby on Rails schien wirklich gut zu unserer Unternehmensphilosophie zu passen und wir dachten, dass unsere bestehende Kundenbasis es lieben würde. Wir haben letztendlich eine Menge neuer Funktionen implementiert, nur um Ruby on Rails zu unterstützen, nicht zuletzt die Unterstützung von FastCGI. Rails selbst stellte sich als viel zu langsam heraus, um es ohne eine Art Beschleunigung zu verwenden (anders als jede andere von uns unterstützte Webprogrammierumgebung), und FastCGI ist bei weitem am besten für eine Shared-Hosting-Umgebung geeignet. Leider verstehen sich Rails und FastCGI einfach nicht! Egal, was wir taten, die Benutzer von Ruby on Rails sahen weiterhin regelmäßige interne Serverfehler. Die beste Vermutung, die ich habe, ist, dass der dynamische Prozessmanager von FastCGI höflich darum bat, dass der Rails-Prozess beendet wird und stattdessen sind sie einfach ausgegangen und haben die Anwendung im Stich gelassen. Das ist natürlich laienhaft ausgedrückt!
Diese Probleme wurden später größtenteils durch einen einzelnen Ruby on Rails-Nutzer gemildert, der wollte, dass es auf unseren Servern besser funktioniert, aber die Lösung der Rails-Community selbst war ehrlich gesagt dumm. Sie sagten, man solle aufhören, Apache und FastCGI zu verwenden (eine Kombination, die bazillionen von Websites erfolgreich betreibt, nur nicht Ruby on Rails-Websites) und stattdessen unsere Server komplett auf Lighttpd und SCGI (ein FastCGI-ähnliches Protokoll, das technisch überlegen sein mag, aber kaum jemand verwendet) umrüsten. Dieser Vorschlag zeigt entweder ein völliges Unverständnis dafür, wie Hosting funktioniert, oder eine völlige Missachtung der realen Welt. Es ist alles gut und schön zu empfehlen, dass Benutzer hochwertiges dediziertes Serverhosting für ihre kommerziellen Anwendungen verwenden, aber man kann einfach nicht ignorieren, dass fast jeder kostengünstiges Shared Hosting zum Starten verwenden möchte. Das ist einfach nur ökonomisch. Zusätzlich möchten Menschen, die Systeme wie Ruby on Rails verwenden, Zeit mit Programmieren verbringen und nicht mit Servereinrichtung. Technologien zu empfehlen, die nicht weit verbreitet oder von irgendeinem großen Webhosting-Unternehmen unterstützt werden, ist eine zu große Belastung für Ihre Benutzer, die Menschen, die Sie glücklich machen möchten! Es ist gut, dass wir nie versucht haben, unser System umzustellen, um Lighttpd und SCGI zu unterstützen, denn 6 Monate später hatte sich das ‘in thing’ in der Rails-Community auf Mongrel verlagert. Entscheidet euch endlich!
Wie es besser sein könnte
Zed Shaw erwähnt in seiner Tirade, dass selbst die Ruby on Rails-Anwendung, die von DHH (demjenigen, der Rails geschrieben hat!) betrieben wird, regelmäßig Probleme hat und mehrmals täglich neu gestartet werden muss. Die Rails-Community besteht aus sehr klugen Programmierern und sie haben ein großartiges System implementiert, das hervorragend funktioniert, wenn es nicht gewartet werden muss. Es ist eines der launischsten Webanwendungssysteme, mit denen ich je Erfahrungen gemacht habe, und das sage ich als jemand, der sowohl den zum Scheitern verurteilten Netscape-Webserver als auch viele Iterationen von PHP (PHP hat viele eigene Probleme, also seid nicht zu selbstgefällig, PHP-Leute) erlebt hat.
Ruby on Rails hat erstaunliches Potenzial, aber hier sind einige Dinge, die unbedingt behoben werden müssen, bevor es jemals so weit verbreitet verwendet wird wie viel weniger gehypte Webanwendungsumgebungen wie PHP…
- Ruby on Rails muss deutlich schneller werden. Mit einem geeigneten Beschleuniger ist es gut nutzbar, aber ohne diesen ist es schmerzhaft. Ruby selbst ist ein großer Teil des Problems, daher könnte dies darauf hinauslaufen, einfach das Management der Beschleunigungstechnologien zu vereinfachen, leider. Mongrel scheint ein großer Schritt in die richtige Richtung zu sein, obwohl es nicht spezifisch für Rails ist. Ich hoffe, dass die Kernentwickler von Rails in Zukunft viel enger mit den Entwicklern von Mongrel zusammenarbeiten werden.
- Ruby on Rails muss mehr oder weniger in JEDEM Umfeld funktionieren. Man kann nicht einfach erwarten, dass die Benutzer ihre Server beliebig einrichten. Es gibt Millionen etablierter Systeme, die nicht einfach jede Spitzentechnologie integrieren können, von der Sie denken, dass sie diese Woche besser ist. Wenn Sie weiterhin diese Einstellung beibehalten, schießen Sie sich definitiv in beide Füße.
- Sie müssen die Abwärtskompatibilität besser pflegen. Zugegeben, auf diesem Gebiet hat PHP historisch gesehen sehr schlecht abgeschnitten, aber das ist kein Grund, sie nicht zu überbieten. Außerdem ist Rails als Entwicklungsplattform zugegebenermaßen sehr jung und Sie haben sehr früh viel Aufmerksamkeit bekommen. Dennoch kommt mit großem Hype auch große Verantwortung. Sie müssen das Momentum jetzt aufrechterhalten.
- Offiziell Shared Hosting-Umgebungen unterstützen. Das Gefühl, das ich von der Rails-Community bekomme, ist, dass Rails als eine Art High-End-Anwendungssystem vermarktet wird und dass es in Ordnung ist, die überwiegende Mehrheit der Benutzer-Webumgebungen zu ignorieren. Sie können einfach die Benutzer von Shared Hosting nicht ignorieren. Meiner Meinung nach ist das eine Sache, die die PHP-Leute gemacht haben, die sie dahin gebracht hat, wo sie heute sind, nämlich Shared Hosting zu umarmen und hart daran zu arbeiten, ihre Software gut darin funktionieren zu lassen. Das bedeutet, dass es sehr leichtgewichtig sein muss (es könnte für Rails bereits zu spät sein!), und es muss sich mit minimalen Problemen und Aufwand in eine Vielzahl von Betriebsumgebungen einfügen. Kompatibilitätsarbeit wie diese ist nicht glamourös, aufregend oder spaßig, aber sie muss gemacht werden.
Was nun?
DreamHost beabsichtigt sehr wohl, Ruby on Rails weiterhin vollständig zu unterstützen. Ruby on Rails hat großes Potenzial, und ich denke, dass es mit der Zeit in der Lage sein könnte, den Hype, der es umgibt, zu erfüllen. Ich hoffe nur, dass die Community nicht zu überheblich wird, bevor das passiert!
Die hier präsentierten Meinungen stammen ausschließlich aus der Perspektive eines Außenstehenden mit einiger Web-Erfahrung. Ich weiß, dass Ruby on Rails auf einigen sehr stark frequentierten Websites verwendet wird und es ist sicherlich möglich, es gut funktionieren zu lassen. Was ich sage, ist, dass es wirklich viel einfacher sein muss. Man muss vorsichtig sein, um nicht Benutzerbegeisterung mit Benutzerfreundlichkeit zu verwechseln. Begeisterte Benutzer werden viele Lücken in der Benutzerfreundlichkeit füllen (DreamHost profitiert von dieser Tatsache!), aber man kann sich langfristig nicht darauf verlassen.
