Размышление Зеда Шоу, человека, написавшего оригинальную версию сервера приложений 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, который может быть технически лучше, но почти никто его не использует). Это предложение показывает либо полное непонимание того, как работает хостинг, либо полное пренебрежение реальным миром. Хорошо и правильно рекомендовать пользователям использовать выделенный серверный хостинг для их коммерческих приложений, но просто нельзя игнорировать тот факт, что почти каждый захочет использовать более дешевый Shared Hosting для начала работы. Это просто экономическая реальность. Кроме того, люди, которые используют системы вроде 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!), но вы не можете полагаться на это в долгосрочной перспективе.
