Wywód Zeda Shawa, człowieka, który napisał oryginalną wersję serwera aplikacji Ruby Mongrel, skłonił mnie do przemyśleń na temat doświadczeń, jakie DreamHost zdobył, hostując strony internetowe napędzane przez Ruby on Rails przez ostatnie kilka lat. Sam wywód był dość długi, ale interesujący (choć nieco egocentryczny) do przeczytania, jeśli jesteś albo programistą Ruby on Rails, albo nerdem, który interesuje się takimi rzeczami, albo interesujesz się kuluarowymi historiami z wysoko profilowanego projektu open-source.
Nie mam nic do dodania do komentarzy Zeda Shawa na temat funkcjonowania zespołu programistów Rails, ponieważ nie mam osobistej wiedzy na ten temat. Co jednak wiem z własnego doświadczenia, to jak trudne może być uruchomienie aplikacji Rails i jej utrzymanie. DreamHost posiada ponad 10 lat doświadczenia w prowadzeniu aplikacji w większości najpopularniejszych frameworków programistycznych, a Rails były i nadal są jednymi z najbardziej frustrujących.
Trochę historii
Gdy zaczęliśmy implementować wsparcie dla Ruby on Rails, chcieliśmy zrobić wszystko, co w naszej mocy, by to wspierać. Była to ekscytująca, nowa platforma internetowa, która ożywiła rozwój aplikacji webowych. Ruby on Rails wydawało się doskonale wpasować w filozofię naszej firmy i myśleliśmy, że nasza istniejąca baza klientów pokocha to rozwiązanie. Wdrożyliśmy całkiem wiele nowych funkcji tylko po to, aby wspierać Ruby on Rails, w tym wsparcie dla FastCGI. Sam Rails okazał się zbyt wolny do użytku bez pewnego rodzaju przyspieszenia (w przeciwieństwie do innych środowisk programowania webowego, które wspieramy), a FastCGI jest zdecydowanie najlepiej przystosowane do środowiska współdzielonego hostingu. Niestety, Rails i FastCGI po prostu nie bardzo się dogadują! Bez względu na to, co robiliśmy, użytkownicy Ruby on Rails ciągle napotykali regularne błędy wewnętrzne serwera. Moim najlepszym przypuszczeniem jest, że menedżer dynamicznych procesów FastCGI grzecznie prosił proces Rails o zakończenie, a one po prostu się zamykały, zostawiając aplikację na lodzie. Oczywiście mówię to prostym językiem!
Te problemy zostały później w dużej mierze złagodzone przez pojedynczego użytkownika Ruby on Rails, który chciał, aby działało to lepiej na naszych serwerach, ale rozwiązanie ze strony społeczności Rails było szczerze mówiąc, głupie. Powiedzieli, aby przestać używać Apache i FastCGI (kombinację, która skutecznie napędza bazyliony stron internetowych, tylko nie Ruby on Rails) i zamiast tego całkowicie przeprojektować nasze serwery na Lighttpd i SCGI (protokół podobny do FastCGI, który może być technicznie lepszy, ale prawie nikt go nie używa). Ta sugestia pokazuje albo kompletny brak zrozumienia, jak działa hosting internetowy, albo całkowite lekceważenie rzeczywistości. Wszystko jest dobrze i pięknie, gdy poleca się użytkownikom korzystanie z droższego hostingu serwerów dedykowanych dla ich komercyjnych aplikacji, ale po prostu nie można ignorować faktu, że prawie każdy będzie chciał używać tańszego Shared Hosting na początek. To po prostu prosta ekonomia. Ponadto, ludzie korzystający z systemów takich jak Ruby on Rails chcą spędzać czas na programowaniu, a nie na konfigurowaniu serwerów. Rekomendowanie technologii, które nie są szeroko używane ani wspierane przez żadną dużą firmę hostingową, jest zbyt dużym obciążeniem dla użytkowników, ludzi, których chcesz zadowolić! Dobrze się stało, że nigdy nawet nie próbowaliśmy przełączyć naszego systemu na Lighttpd i SCGI, też dlatego, że 6 miesięcy później ‘modne’ w społeczności Rails zmieniło się na Mongrel, zamiast tego. Zdecydujcie się wreszcie!
Jak to mogłoby być lepsze
Zed Shaw wspomina w swojej tyradzie, że nawet aplikacja Ruby on Rails prowadzona przez DHH (gościa, który napisał Rails!) ma regularne problemy i potrzebuje restartów kilka razy dziennie. Społeczność Rails jest pełna bardzo inteligentnych programistów i stworzyli świetny system, który działa znakomicie, kiedy nie wymaga opieki. To jeden z najbardziej kapryśnych systemów aplikacji internetowych, z jakimi miałem do czynienia, a mówi to ktoś, kto doświadczył zarówno niefortunnego serwera internetowego Netscape, jak i wielu iteracji PHP (PHP ma wiele własnych problemów, więc nie zadowalaj się PHP).
Ruby on Rails ma niesamowity potencjał, ale oto kilka rzeczy, które po prostu muszą zostać naprawione, zanim będzie ono tak szeroko stosowane jak mniej rozreklamowane środowiska aplikacji internetowych takie jak PHP…
- Ruby on Rails musi być znacznie szybszy. Z odpowiednim akceleratorem jest całkiem użyteczny, ale bez niego jest bolesny. Ruby sam w sobie jest dużą częścią problemu, więc może to się sprowadzić tylko do uproszczenia zarządzania technologiami akceleracji, niestety. Mongrel wydaje się być dużym krokiem w dobrym kierunku, mimo że nie jest specyficzny dla Rails. Mam nadzieję, że główni programiści Rails będą w przyszłości współpracować znacznie bliżej z programistami Mongrel.
- Ruby on Rails musi działać mniej więcej w KAŻDYM środowisku. Nie możesz po prostu oczekiwać, że użytkownicy ustawią swoje serwery w dowolny sposób. Istnieją miliony ustalonych systemów, które nie mogą po prostu zintegrować każdej nowoczesnej technologii, którą uważasz za lepszą w tym tygodniu. Jeśli będziesz kontynuować to podejście, na pewno strzelisz sobie w obie nogi.
- Musisz lepiej dbać o kompatybilność wsteczną. Przyznam, że w tej dziedzinie PHP historycznie radziło sobie bardzo źle, ale to nie powód, aby nie próbować być lepszym. Rails, jako platforma programistyczna, jest również bardzo młoda i szybko zyskała dużo uwagi. Jednak z wielkim rozgłosem wiąże się duża odpowiedzialność. Musisz teraz utrzymać ten pęd.
- Oficjalnie wspieraj środowiska “Shared Hosting”. Wrażenie, które odnoszę ze społeczności Rails, to że Rails jest promowany jako rodzaj systemu aplikacji wysokiej klasy i to uzasadnia ignorowanie przeważającej większości środowisk użytkowników internetowych. Po prostu nie możesz ignorować użytkowników “Shared Hosting”. Moim zdaniem jedną z rzeczy, którą ludzie z PHP zrobili, aby dotrzeć tam, gdzie są dzisiaj, było przyjęcie “Shared Hosting” i ciężka praca nad dobrą współpracą ich oprogramowania w tym środowisku. Oznacza to, że musi być bardzo lekki (może być już za późno dla Rails!), i musi “wtykać się” do różnorodnych środowisk operacyjnych z minimalnym zamieszaniem i problemami. Prace kompatybilnościowe takie jak te nie są efektowne, ekscytujące ani zabawne, ale muszą być wykonane.
Co teraz?
DreamHost zamierza nadal w pełni wspierać Ruby on Rails. Ruby on Rails ma wielkie możliwości, i myślę, że z czasem może sprostać otaczającemu go szumowi. Mam tylko nadzieję, że społeczność nie urośnie w siłę zanim to nastąpi!
Opinie przedstawione tutaj są całkowicie z perspektywy osoby z zewnątrz, posiadającej pewne doświadczenie w sieci. Wiem, że Ruby on Rails jest używany na niektórych stronach o bardzo dużym ruchu i z pewnością jest możliwe, aby działało to dobrze. To, co mówię, to że naprawdę musi być o wiele łatwiejsze. Musisz uważać, aby nie pomylić entuzjazmu użytkowników z łatwością użytkowania. Entuzjastyczni użytkownicy wypełnią wiele luk w użyteczności (DreamHost czerpie z tego faktu!), ale nie można na tym polegać w długoterminowej perspektywie.
