Готов ли Ruby On Rails для предприятия? [закрыто]

Мой приятель только что закончил работать в RecycleBank, и они использовали Rails для всей своей системы интрасети. Я думаю, что Rails определенно готов для предприятия, хотя это не то, что больше всего подвергалось сомнению. Большинство людей задаются вопросом, может ли он обрабатывать смешное количество трафика из-за требований к памяти. Это еще предстоит увидеть, но я думаю, что фреймворк полностью способен обрабатывать корпоративные приложения.

YellowPages.com и Penny Arcade - самые большие, о которых я слышал. Конечно, многие предприятия используют его для внутренних приложений. Что касается масштабирования, либеральное кэширование является секретом, независимо от того, какой у вас язык / рамки.

Если вы разговариваете почти со всеми, кто работает с корпоративным сайтом с большим трафиком, большинство из них скажут вам то же самое, язык, который вы выберете при правильной обработке, никогда не будет вашей проблемой, он всегда будет сводиться к IO.

Если вы посмотрите на такие сайты, как твиттер, убедитесь, что у них есть проблемы. Но они уже признали, что это было потому, что вещи не были должным образом масштабированы. С тех пор как они внедрили изменения, которые они сделали, вещи путешествовали вместе.

Единственное, что останавливает нас здесь, где я работаю, это то, что никто не знает рубина, и у него не так много времени, чтобы учиться.

Я все еще не продан. У Twitter были массовые отключения ( 3 дня на один эпизод !). До некоторой степени это было связано с трудностями при масштабировании RoR: читайте здесь .

/ тр

Я очень удивлен тем, насколько положительным было большинство ответов. Я большой поклонник Ruby и Rails и согласен со всем, что было сказано, но я чувствую, что в сообществе существует общее предположение, что «Rails просто еще не готов к прайм-тайм». (при условии, что сообщество, как правило, менее информировано, чем я полагаю, пользователи этого сайта)

Я думаю, что с технической точки зрения примеры, приведенные другими, показывают, что вы на самом деле можете получить время безотказной работы и производительность от Rails, которые вы ожидаете от стека Java или .Net. Проблема в том, что вы не можете создавать такие высокопроизводительные и надежные приложения в Rails с 30 $ / ч программистами. Кажется, что Ruby и другие динамические языки позволяют великим программистам становиться удивительно эффективными и продуктивными, но в то же время они просто калечат так себе программистов. И, учитывая, что подавляющее большинство крупных ИТ-магазинов выбрали более дешевые обезьяны кода, которые они могут найти, я думаю, что для них было бы очень болезненным переходом на внедрение Rails вместо Java или .Net.

Я думаю, что парни из 37Signals создали все свои приложения, используя Ruby on Rails

Я могу вообразить, они - те, кто изобрел это в конце концов.

В List Apart используется RoR, хотя и не очень.

Я работаю консультантом в IBM и в прошлом году создал несколько сайтов для клиентов, использующих Ruby on Rails. Rails, без сомнения, «готов для предприятия». Ключ заключается в том, чтобы использовать rails для того, в чем он превосходен, и использовать J2EE или другие «корпоративные инструменты» там, где они превосходны. Rails отлично подходит для презентации любого приложения. Вы можете использовать веб-сервисы RESTful без приблизительно 0 работы, и это является отличной точкой интеграции с остальными вашими «корпоративными» инструментами.

Может быть, я бы не использовал рельсы для сборки yahoo.com, но это нормально. Есть сотни и тысячи идеальных ниш, где вы можете использовать рельсы, от Enterprise до самых маленьких IT-магазинов.

Чтобы понять, готов ли Ruby on Rails для предприятия, нужно подумать о том, что означает термин «предприятие». По моему опыту, предприятие означает «безопасный». Компании, которые ищут корпоративное решение, обычно выбирают технологический стек, который поддерживается крупными поставщиками. Таким образом, они знают, что могут получить поддержку и, возможно, консультацию в обмен на большие суммы денег. Это целый подход «никто никогда не был уволен за покупку IBM».

Другой фактор, который следует учитывать, - это повсеместность. Нет сомнений в том, что сейчас Ruby по-прежнему считается несколько экзотическим языком, и наличие опытных программистов на Ruby отражает это. Технически, Ruby являетсяболее сложный, чем Java или C #, ближе к Smalltalk с точки зрения чистоты ОО и ближе к LISP с точки зрения возможностей метапрограммирования. Достаточно сказать, что компаниям будет проще найти программистов на Java или .NET по более низким ценам, чем программистов на Ruby. Это не оскорбляет программистов на Java или .NET, а отражает тот факт, что многие работодатели все еще считают разработку программного обеспечения чем-то, что должно быть сделано самым дешевым покупателем, а не тем, что должно быть сделано правильно. Программисты на Java и .NET стали в значительной степени товаром, поэтому могут быть предложены с меньшими затратами.

Технически Ruby on Rails может масштабироваться так же хорошо, как и Java, .NET или PHP и т. Д. Те же основные принципы применяются для измерения узких мест, настройки запросов SQL, минимизации операций ввода-вывода, возможной денормализации схемы базы данных, если это необходимо, и создания разумное использование кеширования и т. д. Если вам необходимо создать следующий eBay или Amazon, то вам нужно будет вручную прокрутить и настроить собственное решение, как это сделали eBay и Amazon. J2EE имеет преимущество в унаследованной интеграции, но это не тот случай использования, для которого Rails все равно оптимизирован - Rails - это все о создании новых приложений CRUD.

Нет сомнений в том, что в настоящее время Ruby является одним из самых медленных языков; В эту область вкладываются большие средства, поэтому ожидайте, что ситуация улучшится в ближайшие несколько лет, так же, как это произошло с Java с момента ее появления. Есть много интересных разработок, происходящих в области виртуальных машин Ruby и альтернатив MRI (Matz Ruby Interpreter). Лично я думаю, что JRuby - это тот, за кем нужно следить. Он поддерживается Sun (см. Рисунок), и поскольку это Java-реализация Ruby, это отличный троян, который вы можете использовать, чтобы внедрить Ruby в свое предприятие через существующую инфраструктуру JVM.

Я не думаю, что Rails вполне подходит для предприятия, и во многих отношениях я надеюсь, что это никогда не произойдет. Я не особенно хочу, чтобы моя любимая среда была погублена посредственностью или путаницей выбора нескольких поставщиков, которая была очевидна для меня в мире J2EE. К счастью, DHH, похоже, полон решимости, чтобы Rails продолжал быть самоуверенным программным обеспечением для того, чтобы избавиться от собственного зуда, а не пытаться быть всем для всех компаний.

История Твиттера, кажется, распространила слово, что "Rails не масштабируется". Тем временем LinkedIn создал приложение для Facebook с использованием Rails, которое обрабатывает 1B просмотров страниц в месяц .

Я покупаю аргумент, который они приводят, а именно то, что проблемы масштабируемости - это не столько результат того, какой язык / платформа вы используете, а больше то, как вы реализуете вещи на этой платформе.

IBM, Oracle, Sun и JPMorgan Chase - лишь некоторые из компаний, которые используют Ruby on Rails. Это, вероятно, не становится более предприимчивым, чем это.

Я думаю, что многие люди путаются с тем, что на самом деле означает слово «предприятие». YelloPages.com и Penny Arcade не являются корпоративными приложениями. Конечно, они могут иметь большое количество пользователей и хитов в минуту, но это относительно простые приложения.

Корпоративное приложение - это приложение, которое используется для управления предприятием - обычно это крупная многопрофильная, многопрофильная компания. SAP - это корпоративная система, а BaseCamp - нет.

Вот некоторые характеристики, которые вы обычно видите в корпоративных приложениях:

• Они большие и сложные. Типичная система ERP должна иметь дело с сотнями типов объектов.
• Они часто должны интегрироваться с другими системами и должны предоставлять точки интеграции для третьих сторон.
• Они имеют большое количество разных типов пользователей и ролей, в значительной степени отражающих разные типы заданий в большой организации.

Чтобы ответить на ваш вопрос, я бы сказал, что да, Rails готов. В настоящее время мы разрабатываем большую систему управления финансовыми ресурсами для компании, насчитывающей более 1000 пользователей в 20 отделах. Масштабируемость не является большой проблемой для нас, но надежность и доступность есть. Решение этой проблемы одно и то же, независимо от технологического стека.

Я бы повторил точку зрения, высказанную другими о опытных разработчиках, но это опять же относится к любому технологическому стеку. Это может быть нормально, если среднестатистический разработчик работает на некритической небольшой системе, но если вы серьезно относитесь к разработке критически важного и общеорганизационного приложения, лучше всего, чтобы над ним работали самые умные ребята.

Мы используем Ruby on Rails прежде всего для критически важных бизнес-приложений. И нам было намного проще интегрировать Ruby с другими «корпоративными» системами, например:

• мы используем Rails поверх базы данных Oracle
• мы интегрируем наши Rails-приложения с Oracle E-Business Suite (ERP и CRM-система)
• мы интегрируем аутентификацию пользователей с каталогами LDAP, аутентификацию домена Windows NTLM, аутентификацию пакета Oracle E-Business
• мы создаем веб-сервисы REST и SOAP для интеграции с другими системами

Существует множество «корпоративных» интеграционных платформ, которые должны делать такие вещи, но они, как правило, довольно дороги, и также вы часто зависаете в какой-то проблеме, а затем зависите от поставщика, решит ли он проблему или нет.

С Ruby и другими компонентами с открытым исходным кодом вы всегда можете решить проблему самостоятельно, поскольку вы можете найти причину проблемы, и ничто не скрыто от вас.

Так что если у вас есть умные разработчики, которые любят решать сложные задачи, то Ruby станет для них отличным инструментом. Но если у вас есть среднестатистические разработчики, которые не хотят изучать что-то новое и надеются, что продавцы сделают свою работу, то, вероятно, Ruby не для них. Но я сомневаюсь, что среднестатистические разработчики смогут создавать отличные программы с помощью любого инструмента.

Вот мой взгляд на это. Моя компания (в которой работает 120 000 человек) имеет преимущественно стек Java / J2EE для внутренних ИТ. Они также используют Sharepoint для управления документами / знаниями и приложения Oracle для рабочих процессов и т. Д. В течение последних 2 лет я возглавлял небольшую группу энтузиастов Ruby on Rails / Python-Django / PHP, чтобы активно пропагандировать принятие этих сред на предприятии. , Обычные (часто неверные) аргументы, с которыми мы столкнулись

1. Это не масштабируется
2. Это недостаточно безопасно для предприятия

Но нам удалось протолкнуть несколько приложений (Wordpress для блогов, пользовательские ответы Yahoo, такие как внутреннее социальное приложение для вопросов и ответов и приложение Idea / Innovation mgmt на основе Rails в стиле Digg), и все очень быстро изменилось. В настоящее время существует серьезный интерес к тому факту, что Rails / Django и его аналог могут на самом деле быть лучше для определенного класса корпоративных приложений, особенно простых, легких приложений в области управления знаниями, рабочих процессов и т. Д.

Поскольку моя ежедневная работа связана с корпоративной архитектурой, я считаю, что слово «предприятие» в настоящее время не означает размер или масштаб, а скорее относится к тому, как продается программный продукт.

Например, Ruby on Rails не является предприятием, потому что нет ни одного поставщика, который бы заходил в ваш магазин и неоднократно проводил презентации Powerpoint для сообщества разработчиков. В Ruby on Rails нет менеджера по продажам, который отвезет меня на поле для гольфа или в мой любимый ресторан на обед. Ruby on Rails также глубоко не освещается такими аналитическими фирмами, как Gartner.

Ruby on Rails никогда не будет считаться "предприятием", пока эти вещи не произойдут ...

Я веб-разработчик, и я уже создал несколько сайтов Ruby on Rails для различных компаний (от интрасетей до средних сайтов), но я не использовал его для действительно крупномасштабных приложений.

Люди всегда отмечают, что он медленный, не масштабируется и его сложно развернуть. «Проблема масштабируемости» больше не является проблемой. Это все еще немного медленнее, чем большинство других фреймворков, но я надеюсь, что rails 3 это исправит. Это не очень сложно развернуть благодаря Capistrano и mod_rails .

Реальные проблемы, которые я могу видеть с рельсами в крупных проектах:

• Не так много людей, знающих Rails. Если у вас есть приложение PHP, вы можете быть уверены, что 66% веб-разработчиков смогут его поддерживать. С рельсами это не то же самое.
• Это все еще медленнее, и если скорость критична, это может быть проблемой
• Ему все еще нужно больше компонентов для электронной коммерции и так далее. Это происходит, особенно после shopify , но, к примеру, не так готово, как Java.

Кроме того, я думаю, что Rails готов.

Часто это просто вопрос выбора правильной технологии для проекта, а иногда это могут быть рельсы. У каждого языка / фреймворка есть свои недостатки, поэтому в некоторых случаях Rails не будет самым умным выбором, но в других случаях он будет работать правильно.

Кроме того, просто дождитесь Rails 3 , это будет круто :)

Я использую рельсы в корпоративной среде, и это работает довольно хорошо. Вам просто нужно создать приложение для работы в среде. В моем случае мы являемся Java-домом, поэтому jRuby является предпочтительным методом развертывания.

Я также перестал использовать рельсы для рендеринга реальных страниц, но использую его для модулей, инструментов и быстрых и грязных сервисов, которые ссылаются на инструменты. Наши Java-сервисы не имеют никакого внутреннего инструмента, который бы взаимодействовал с ними.

Наш сайт имеет сотни (возможно, тысячу) страниц, поэтому рельсы, вероятно, будут плохим кандидатом на замену этой архитектуры. С другой стороны, если я интегрирую рельсы в сайт Java, то смогу решить довольно много проблем, которые были бы очень сложными с конца Java.

Архитектура вашего приложения является ключевой, если вы не спроектируете приложение для хорошего масштабирования, у вас будут проблемы, независимо от того, какой фреймворк / язык вы выберете.

Я создал приложение для нескольких страниц, которое получает сотни тысяч просмотров в месяц. Rails работал отлично, но большая часть контента была кеширована. У нас был один случай, когда Yahoo показывал на первой полосе историю, связанную с нами. На этой странице было не кешированное содержание rails, поэтому огромный трафик привел к отключению приложения rails, но это была моя вина, что я не оптимизировал лучше.

Я не знаю, буду ли я считать это предприятием ... но я думаю, это говорит о том, что и твиттер, и хулу построены на рельсах.

В настоящее время мы успешно используем Rails для сайта с более чем 5 миллионами уникальных записей в месяц, поэтому если предприятие = масштабирование, тогда да.

Я определенно прочитал бы этот пример использования Ruby On Rails

В этой статье я расскажу, как мы используем Ruby on Rails для создания сайта. Вы увидите основные функции, которые мы используем, а также основные плагины, от которых мы зависим каждый день. Большинство наших технологий на самом деле не ошеломляет, но я надеюсь дать вам представление о наших повседневных операциях. Моя цель - дать вам общее представление о работе команды, технологиях, которым мы доверяем в производственной среде, инструментах, которые мы используем, и средах Rails, которые наиболее важны для нас. Я буду ссылаться на ресурс, а не вдаваться в подробности в какой-либо отдельной области, но если вы хотите узнать больше о какой-либо его части, оставьте комментарий.

Да, у нас есть несколько крупных клиентов, использующих наши приложения на основе Rails (интранет и облако). Стабильность была потрясающей. Например, на ум приходят два из них с наибольшим объемом трафика и сложностью: одно из наших приложений работает в течение 2,5 лет с 0 проблемами, а еще 6 месяцев - также с 0 проблемами.