Готовы ли Ruby On Rails к Enterprise?

Кто-нибудь там использует RoR для крупномасштабных бизнес-критически важных корпоративных приложений?

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

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

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

A List Apart использует RoR, но не очень корпоративно.

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

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

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

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