2008-08-18 6 views
69

Есть ли кто-нибудь там, используя RoR для крупномасштабных бизнес-критически важных корпоративных приложений?Является ли Ruby On Rails готовым к Enterprise?

Существуют ли какие-либо другие облегченные веб-рамки на основе динамических языков, которые люди используют для этих типов приложений?

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

+1

Я нашел это полезным. В статье рассматриваются некоторые из сильных и слабых сторон для Rails в Enterprise. http://weblog.rubyonrails.org/2010/3/24/rails-and-the-enterprise/ – Jason 2013-04-06 21:48:48

ответ

2

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

2

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

3

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

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

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

-7

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

/тр

+1

Итак, поскольку у Твиттера были массовые отключения в течение 3 дней, поэтому все веб-сайты (в том числе предприятия) не будут масштабироваться? – Jaryl 2008-12-29 03:09:09

+1

http://twitter.com/ev/statuses/801530348 – 2009-04-17 03:22:37

+1

Я думаю, что называть Twitter золотой стандарт того, может ли язык масштабироваться, очень смехотворно. Они переключились на среду на основе Java и все еще имеют проблемы. Это ошибка Java или это результат того, что платформа растет быстрее, чем кто-либо мог ожидать? – thaBadDawg 2009-08-08 23:23:00

6

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

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

+4

На самом деле это не так, что они калечат так себе программистов. У некоторых людей просто нет желания или мышления, чтобы выучить новый язык или рамки. Это, как правило, люди, которые подошли к профессии с идеей, что они только когда-либо должны изучать один язык или технологию, и они будут зарабатывать деньги от этого набора навыков на всю свою жизнь. И если этот язык/технология - это .net или java (чаще всего), они будут использовать слово enterprise свободно, особенно в ситуации, когда они боятся узнать что-то новое. – Vasil 2009-08-07 09:56:39

3

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

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


A List Apart использует RoR, но не очень-то предприятие.

10

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

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

+6

с Yahoo! использует PHP ... почему бы не Ruby? – rtacconi 2009-07-15 14:49:34

122

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

Еще один фактор для рассмотрения - вездесущность. Нет никаких сомнений в том, что сейчас Ruby по-прежнему рассматривается как несколько экзотический язык, и наличие опытных программистов Ruby отражает это. Технически Ruby является более сложным, чем Java или C#, будучи ближе к Smalltalk с точки зрения чистоты OO и ближе к 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 VM и альтернативы МРТ (Matz Ruby Interpreter). Лично я считаю, что JRuby должен следить за собой. Он поддерживается Sun (go figure), и потому что это реализация Java Ruby, это аккуратный троянский конь, который вы можете использовать, чтобы получить Ruby на свое предприятие через существующую инфраструктуру JVM.

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

+8

Фантастический товар! – 2009-07-27 19:16:32

+2

Спасибо Эдуардо! :-) – 2009-07-27 20:13:50

+0

Разработчики ядра JRuby теперь перешли на EngineYard. – 2009-08-02 13:36:10

6

В рассказе Twitter рассказывается, что «Rails не масштабируется». Между тем, LinkedIn создал приложение Facebook с использованием Rails, которое равно handling 1B page views/month.

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

9

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

25

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

Приложение для предприятий - это приложение, которое используется для запуска предприятия - как правило, это большая многоотраслевая многоуровневая компания. SAP - это корпоративная система, BaseCamp - нет.

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

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

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

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

9

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

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

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

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

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

6

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

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

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

12

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

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

Рубин на Rails никогда не будет считаться «предприятие», пока эти вещи не происходят ...

5

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

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

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

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

Помимо этого, я думаю, что Rails готов.

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

Кроме того, просто ждать Rails 3, это будет удивительным :)

1

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

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

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

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

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

1

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

1

Мы используем Rails для сайта с более чем 5 миллионами уникалов в месяц с большим успехом, поэтому, если enterprise = scale then yes.

1

Я бы определенно прочитать эту социологическое исследование Ruby On Rails

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

2

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