Готов ли Ruby на Rails для предприятия?

Для того чтобы решить, готов ли Ruby на Rails для предприятия, вы должны подумать о том, что означает термин "enterprise". По моему опыту, "Энтерпрайз" означает "safe". Компании, которые ищут корпоративное решение, обычно выбирают технологический стек, поддерживаемый крупными поставщиками. Таким образом, они знают, что могут получить поддержку и, возможно, консультацию в обмен на большие суммы денег. Это весь подход "nobody ever got fired for buying IBM".

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

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

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

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

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

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

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

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

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

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

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

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

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

Я работаю консультантом с IBM и за последний год создал несколько сайтов для клиентов, использующих Ruby на Rails. Rails-это, без сомнения, "ready for the enterprise." ключ к тому, чтобы использовать rails для того, что он превосходит, и использовать J2EE или другие "enterprise tools", где они excel. Rails отлично подходит для презентации в конце любого приложения. Вы можете использовать RESTful веб-службы без приблизительно 0 рабочих мест, и это отличная точка интеграции с rest ваших инструментов "enterprise".

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

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

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

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

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

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

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

Я очень удивлен тем, насколько позитивными были большинство ответов. Я большой поклонник Ruby и Rails и согласен со всем, что было сказано, но у меня есть ощущение, что в сообществе существует общее предположение, что "Rails just isn't ready for prime-time yet." (при условии, что сообщество обычно менее информировано, чем я представляю себе пользователей этого сайта)

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

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

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

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

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

Но нам удалось протолкнуть несколько приложений (Wordpress для блоггинга, специально построенные ответы Yahoo, такие как внутреннее приложение social Q&A и приложение Digg style Rails, основанное на идее/инновациях mgmt), и все действительно изменилось за очень короткое время. В настоящее время существует сильный бай-ин для того, что Rails/Django и ему подобные действительно могут быть лучше для определенного класса корпоративных приложений, особенно простых, легких в областях KM, workflow и т. д.

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

Люди всегда указывают на то, что он медленный, не масштабируется и трудно развертывается. "scalability issue" на самом деле больше не является таковым. Это все еще немного медленнее, чем большинство других фреймворков, но у меня есть хорошая надежда, что rails 3 исправит это. Это не очень трудно развернуть больше благодаря Capistrano и mod_ _ 32 .

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

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

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

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

Кроме того, просто подождите Rails 3 , это будет потрясающе :)

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

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

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

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

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

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

Список отдельно использует RoR, хотя и не очень корпоративный.

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

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

Мы сейчас используем Rails для сайта с более чем 5 миллионами uniques / month с большим успехом, так что если enterprise = scale, то да.

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

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

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

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

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

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

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

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

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

/mp