Скарга Зеда Шоу, людини, яка написала оригінальну версію сервера додатків Ruby Mongrel, змусила мене замислитися про досвід DreamHost у хостингу вебсайтів на базі Ruby on Rails протягом останніх кількох років. Сама скарга була доволі довгою, але цікавою (хоча й самолюбною) для читання, якщо ви або розробник Ruby on Rails, або нерд, якому це просто цікаво, або зацікавлені в закуліссі високопублічного проекту з відкритим кодом.
У мене немає чого додати до коментарів Зеда Шоу щодо того, як працює команда розробників Rails, оскільки я не маю особистих знань про це. Те, що я дійсно знаю з особистого досвіду, це наскільки важко може бути запустити та підтримувати у робочому стані додаток на Rails. DreamHost має понад 10 років досвіду у керуванні додатками у більшості популярних веб-програмних фреймворків, і Rails завжди був і залишається одним із найбільш проблемних.
Деяка історія
Коли ми вперше почали впроваджувати підтримку Ruby on Rails, ми хотіли зробити все можливе, щоб підтримати його. Це була захоплююча і нова веб-платформа, яка оживляла розробку веб-додатків. Ruby on Rails, здавалося, дуже добре вписувався в філософію нашої компанії, і ми думали, що наша існуюча клієнтська база полюбить його. Ми впровадили чимало нових функцій, лише для підтримки Ruby on Rails, зокрема підтримку FastCGI. Сам Rails виявився занадто повільним для використання без деякого роду прискорення (на відміну від будь-якого іншого веб-програмного середовища, яке ми підтримуємо), і FastCGI є найбільш підходящим для середовища спільного веб-хостингу. На жаль, Rails і FastCGI просто не дуже ладнають! Незалежно від того, що ми робили, користувачі Ruby on Rails постійно стикалися зі звичайними внутрішніми помилками сервера. Найкраще, що я можу припустити, це те, що динамічний менеджер процесів FastCGI ввічливо просив процес Rails завершитися, а замість цього вони просто виходили і залишали додаток наодинці. Звичайно, це пояснення для неспеціалістів!
Ці проблеми згодом були здебільшого пом’якшені одним користувачем Ruby on Rails, який хотів, щоб воно краще функціонувало на наших серверах, але саме рішення від спільноти Rails, чесно кажучи, було дурним. Вони сказали перестати використовувати Apache та FastCGI (комбінація, яка успішно працює на безлічі веб-сайтів, але не на Ruby on Rails) і замість цього повністю переоснастити наші сервери за допомогою Lighttpd та SCGI (протокол, схожий на FastCGI, який технічно може бути кращим, але майже ніхто його не використовує). Така пропозиція свідчить або про повну відсутність розуміння того, як працює хостинг, або про повне нехтування реальним світом. Це добре і правильно рекомендувати користувачам використовувати хостинг на виділених серверах вищого класу для їхніх комерційних застосунків, але ви просто не можете ігнорувати той факт, що майже всі захочуть використовувати дешевший спільний хостинг для початку роботи. Це просто економічна необхідність. Крім того, люди, які використовують системи на кшталт Ruby on Rails, хочуть проводити час за програмуванням, а не за налаштуванням серверів. Рекомендація технологій, які не широко використовуються або не підтримуються жодною великою хостинговою компанією, ставить на користувачів, людей, яких ви хочете зробити щасливими, занадто велике навантаження! Добре, що ми навіть не намагалися перейти на підтримку Lighttpd та SCGI, адже через 6 місяців ‘актуальна річ’ у спільноті Rails змінилася на Mongrel замість цього. Вже пора визначитися!
Як це можна покращити
Зед Шоу згадує у своєму виступі, що навіть додаток Ruby on Rails, який керує DHH (той самий, хто написав Rails!), має регулярні проблеми і потребує перезапусків кілька разів на день. Спільнота Rails складається з дуже розумних програмістів, і вони створили чудову систему, яка працює відмінно, коли за нею не потрібно стежити. Це одна з найбільш мінливих систем веб-додатків, з якими я коли-небудь мав справу, і це слова людини, яка мала досвід роботи як з приреченим веб-сервером Netscape, так і з багатьма ітераціями PHP (у PHP багато своїх проблем, тож не хваліться занадто, люди PHP).
Ruby on Rails має великий потенціал, але ось деякі речі, які просто мають бути виправлені, перш ніж вона буде використовуватися так широко, як менш рекламовані веб-додаткові середовища, такі як PHP…
- Ruby on Rails потребує значно більшої швидкості. З належним акселератором він зручний у використанні, але без нього це болісно. Сам Ruby є значною частиною проблеми, тому це може звестися лише до спрощення управління технологіями акселерації, на жаль. Mongrel здається великим кроком у правильному напрямку, хоча і не специфічний для Rails. Я сподіваюсь, що основні розробники Rails будуть тісніше співпрацювати з розробниками Mongrel у майбутньому.
- Ruby on Rails має працювати в будь-якому середовищі. Ви не можете просто очікувати, що користувачі налаштують свої сервери будь-яким способом. Існує мільйони встановлених систем, які не можуть просто інтегрувати будь-яку передову технологію, яку ви вважаєте кращою цього тижня. Якщо ви продовжите дотримуватися цієї позиції, ви, безумовно, стріляєте собі в обидві ноги.
- Вам потрібно краще підтримувати зворотну сумісність. Потрібно визнати, що в цій сфері PHP історично має дуже погані показники, але це не причина не покращувати їх. Також, Rails, безумовно, дуже молода платформа розробки і ви здобули БАГАТО уваги дуже рано. Проте, з великим хайпом приходить велика відповідальність. Вам потрібно підтримувати імпульс зараз.
- Офіційно підтримувати середовища спільного хостингу. Відчуття, яке я маю від спільноти Rails, полягає в тому, що Rails просувається як деяка система додатків вищого класу, і це робить нормальним ігнорування великої більшості користувацьких веб-середовищ. Ви просто не можете ігнорувати користувачів спільного хостингу. На мою думку, одна річ, яку зробили люди з PHP, що допомогла їм досягти сьогодення, полягає в тому, що вони прийняли спільний хостинг і наполегливо працювали, щоб їх програмне забезпечення добре функціонувало в ньому. Це означає, що воно має бути дуже легким (можливо, для Rails вже пізно!), і воно має “підключатися” до широкого спектру операційних середовищ із мінімальними труднощами та зусиллями. Робота з сумісністю, як ця, не є гламурною, захоплюючою або веселою, але її потрібно виконати.
Що далі?
DreamHost дуже прагне продовжувати повноцінну підтримку Ruby on Rails. Ruby on Rails дійсно має великі перспективи, і я думаю, що з часом він зможе виправдати той галас, який навколо нього створюється. Я просто сподіваюся, що спільнота не зазнає високомерства до того, як це станеться!
Думки, висловлені тут, повністю базуються на поглядах ззовні з деяким досвідом у вебі. Я знаю, що Ruby on Rails використовується на деяких дуже популярних вебсайтах, і цілком можливо зробити його добре працюючим. Те, що я кажу, це те, що це дійсно має бути набагато легше. Вам потрібно бути обережним, щоб не сплутати ентузіазм користувачів з легкістю використання. Ентузіазм користувачів заповнить багато прогалин у зручності користування (DreamHost процвітає на цьому факті!), але ви не можете покладатися на це в довгостроковій перспективі.
