ruby-on-rails ruby enterprise

¿Está Ruby On Rails listo para la empresa?



ruby-on-rails enterprise (20)

¿Hay alguien por ahí que utilice RoR para aplicaciones empresariales críticas a gran escala?

¿Hay algún otro framework web liviano basado en los lenguajes dinámicos que las personas están usando para este tipo de aplicaciones?

Si no está utilizando este tipo de marcos de aplicaciones, ¿qué lo detiene? Es simplemente la inercia asociada a cualquier gran organización de TI. ¿Los problemas de velocidad y estabilidad de estos marcos son un problema suficiente como para compensar las mejoras en los tiempos del ciclo de desarrollo?

Creo que los chicos de 37Signals han desarrollado todas sus aplicaciones usando Ruby on Rails

Me puedo imaginar, ellos son los que lo inventaron después de todo.

A List Apart usa RoR, aunque no muy empresarial.

Aquí está mi opinión sobre esto. Mi compañía (que tiene 120,000 empleados) tiene una pila predominantemente Java / J2EE para TI interna. También usan Sharepoint para gestión de documentos / conocimiento y aplicaciones de Oracle para flujo de trabajo, etc. Durante los últimos 2 años, he guiado a un pequeño grupo de entusiastas de Ruby on Rails / Python-Django / PHP para buscar activamente la adopción de estos marcos dentro de la empresa . Los argumentos habituales (a menudo inválidos) con los que nos topamos

  1. No escalará
  2. No es lo suficientemente seguro para la empresa

Pero, logramos impulsar algunas aplicaciones (Wordpress para blogs, respuestas de Yahoo personalizadas como aplicación de preguntas y respuestas sociales internas y una aplicación de ideas / innovación basada en Rails Digg style Rails) y las cosas realmente han cambiado en muy poco tiempo. Ahora hay una gran aceptación por el hecho de que Rails / Django y su tipo pueden ser mejores para una cierta clase de aplicaciones empresariales, especialmente las más simples y livianas en las áreas de KM, flujo de trabajo, etc.

Como mi trabajo diario es todo acerca de la arquitectura empresarial, creo que la palabra empresa no es hoy en día de tamaño ni escala, sino que se refiere más a cómo se vende un producto de software.

Por ejemplo, Ruby on Rails no es una empresa porque no hay un proveedor que ingrese a su tienda y haga presentaciones de Powerpoint repetidas veces para la comunidad de desarrolladores. Ruby on Rails no tiene un ejecutivo de ventas que me lleve al campo de golf o a mi restaurante favorito para almorzar. Ruby on Rails tampoco está profundamente cubierto por firmas analistas de la industria como Gartner.

Ruby on Rails nunca se considerará "empresa" hasta que esto ocurra ...

Creo que muchas personas se confunden con lo que realmente significa la palabra "Enterprise". YelloPages.com y Penny Arcade no son aplicaciones empresariales. Claro, pueden tener grandes volúmenes de usuarios y hits / minuto, pero son aplicaciones relativamente simples.

Una aplicación empresarial es una que se utiliza para ejecutar una empresa, lo que generalmente significa una gran empresa de múltiples departamentos y ubicaciones múltiples. SAP es un sistema empresarial, BaseCamp no lo es.

Algunas de las características que normalmente verá en aplicaciones empresariales son:

  • Son grandes y complejos. Un sistema ERP típico necesita tratar con cientos de tipos de entidades.
  • A menudo necesitan integrarse con otros sistemas y necesitan proporcionar puntos de integración para terceros.
  • Tienen una gran cantidad de tipos de usuarios y roles diferentes, que reflejan en gran medida los diferentes tipos de trabajo en una organización grande.

Para responder a tu pregunta, diría que sí, Rails está listo. Actualmente estamos desarrollando un gran sistema de administración financiera de sistemas para una compañía de más de 1000 usuarios que cruzan 20 departamentos. La escalabilidad no es un gran problema para nosotros, pero la confiabilidad y la disponibilidad sí lo son. La solución de ese problema es la misma sin importar la acumulación de tecnología.

Volvería a repetir el punto que otros han hecho sobre los desarrolladores expertos, pero eso nuevamente se aplica a cualquier pila de tecnología. Podría estar bien que un desarrollador promedio trabaje en un sistema pequeño no crítico, pero si se toma en serio el desarrollo de una aplicación que sea crítica y para toda la empresa, lo mejor será que los más inteligentes trabajen en ello.

Definitivamente leería este caso de Ruby On Rails

En este artículo, lo guiaré por el camino que estamos usando Ruby on Rails para construir el sitio. Verá las funciones principales que estamos utilizando, así como los complementos principales de los que dependemos todos los días. La mayor parte de nuestra tecnología no es realmente demoledora, pero espero poder echarle un vistazo dentro de nuestras operaciones diarias. Mi objetivo es brindarle una visión general amplia de cómo funciona el equipo, la tecnología en la que confiamos en el entorno de producción, las herramientas que utilizamos y los marcos de Rails que son más importantes para nosotros. Voy a vincular a un recurso en lugar de entrar en gran detalle en un área determinada, pero si quieres saber más sobre cualquier parte de él, deja un comentario.

Estamos al día usando Rails para un sitio con más de 5 millones de exclusiones / mes con gran éxito, por lo que si enterprise = scale, entonces sí.

Estamos usando Ruby on Rails principalmente para aplicaciones comerciales críticas "empresariales". Y para nosotros ha sido mucho más fácil integrar Ruby con otros sistemas "empresariales", por ejemplo:

  • estamos utilizando Rails en la parte superior de la base de datos Oracle
  • integramos nuestras aplicaciones Rails con Oracle E-Business Suite (sistema ERP y CRM)
  • integramos autenticación de usuario con directorios LDAP, autenticación de dominio NTLM Windows, autenticación de suite Oracle E-Business
  • creamos servicios web REST y SOAP para la integración con otros sistemas

Hay muchas plataformas de integración "empresariales" que se supone que hacen ese tipo de cosas, pero por lo general son bastante costosas y, a menudo, te quedas atascado en algún problema y luego dependes del proveedor si resuelve el problema o no.

Con Ruby y otros componentes de código abierto, siempre podrá resolver el problema usted mismo, ya que puede profundizar hasta el origen del problema y no tiene nada oculto.

Entonces, si tienes desarrolladores inteligentes a quienes les gusta resolver problemas difíciles, entonces Ruby será una excelente herramienta para ellos. Pero si tienes desarrolladores promedio que no quieren aprender nada nuevo y que esperan que los proveedores hagan su trabajo, probablemente Ruby no sea para ellos. Pero dudo que los desarrolladores promedio puedan crear un gran software con cualquier herramienta.

Estoy bastante sorprendido de lo positivas que han sido la mayoría de las respuestas. Soy un gran admirador de Ruby and Rails y estoy de acuerdo con todo lo que se ha dicho, pero tengo la sensación de que hay una suposición general en la comunidad de que "Rails aún no está listo para el horario estelar". (dado que la comunidad generalmente está menos informada de lo que imagino que son los usuarios de este sitio)

Creo que, desde una perspectiva técnica, los ejemplos que otros han mencionado muestran que, de hecho, puede obtener el tiempo de actividad y el rendimiento de Rails que espera de una pila Java o .Net. El problema es que no puedes construir ese tipo de aplicaciones confiables y de alto rendimiento en Rails con 30 $ / hora de programadores. Ruby y otros lenguajes dinámicos parecen permitir a los grandes programadores convertirse en increíblemente eficientes y productivos, pero al mismo tiempo simplemente paralizan a los programadores regulares. Y considerando que la gran mayoría de las grandes tiendas de TI han optado por obtener los monos con códigos más baratos que puedan encontrar, creo que sería una transición muy dolorosa para ellos intentar introducir a Rails como un reemplazo para Java o .Net.

IBM, Oracle, Sun y JPMorgan Chase son solo algunas de las compañías que usan Ruby on Rails. Probablemente no sea más productivo que eso.

La historia de Twitter parece haber corrido la voz de que "Rails no escala". Mientras tanto, LinkedIn creó una aplicación de Facebook utilizando Rails que maneja 1B vistas de página / mes .

Compro el argumento que hacen, que es que los problemas de escalabilidad son menos producto de qué lenguaje / plataforma utilizas y más sobre cómo implementar cosas dentro de esa plataforma.

No sé si lo consideraría una empresa ... pero creo que dice mucho que Twitter y Hulu están construidos sobre rieles.

Para considerar si Ruby on Rails está listo para la empresa, debe pensar en lo que significa el término "empresa". En mi experiencia, la empresa significa "seguro". Las empresas que buscan una solución empresarial generalmente eligen una pila de tecnología respaldada por grandes proveedores. De esta forma, saben que pueden obtener apoyo y, probablemente, asesoría a cambio de gastar grandes cantidades de dinero. Es el enfoque de "nadie fue despedido por comprar IBM".

Otro factor a considerar es la ubicuidad. No hay duda de que en este momento Ruby todavía se ve como un lenguaje algo exótico y la disponibilidad de hábiles programadores de Ruby refleja esto. Técnicamente, Ruby es más sofisticado que Java o C #, está más cerca de Smalltalk en términos de pureza de OO y más cerca de LISP en cuanto a las instalaciones de meta-programación. Basta con decir que a las compañías les resultará más fácil obtener programadores Java o .NET a un precio bajo en las tiendas físicas que ser programadores de Ruby. Eso no es para insultar a los programadores de Java o .NET, más bien es un reflejo del hecho de que hay muchos empleadores que todavía consideran el desarrollo de software como algo que debe hacer el postor más barato, en lugar de hacerlo de forma correcta. Los programadores de Java y .NET son ahora prácticamente un producto básico, por lo que se pueden ofrecer a un costo menor.

Técnicamente, Ruby on Rails puede escalar tan bien como Java, .NET o PHP, etc. Se aplican los mismos principios básicos para medir dónde están los cuellos de botella, ajustar sus consultas SQL, minimizar la E / S, posiblemente desnormalizar el esquema de la base de datos si es apropiado y hacer uso juicioso del almacenamiento en caché, etc. Si necesita construir el próximo eBay o Amazon, entonces debe realizar un ajuste manual y afinar manualmente su propia solución, tal como lo hicieron eBay y Amazon. J2EE tiene la ventaja en la integración heredada, pero ese no es el caso de uso que Rails está optimizado de todos modos: Rails se trata de construir nuevas aplicaciones CRUD.

No hay duda de que, tal como está actualmente, Ruby es uno de los idiomas de ejecución más lenta; se está invirtiendo mucho en esta área, así que espere que la situación mejore en los próximos años, tal como lo hizo con Java desde que salió. Hay muchos desarrollos interesantes que tienen lugar en el campo de las máquinas virtuales Ruby y alternativas a la resonancia magnética (intérprete de Matz Ruby). Personalmente creo que JRuby es alguien a quien hay que vigilar. Está respaldado por Sun (vaya figura) y porque es una implementación de Java de Ruby, es un caballo de Troya ordenado que puede utilizar para obtener Ruby en su empresa, a través de su infraestructura de JVM existente.

No creo que Rails esté todavía allí para la empresa y de muchas maneras espero que nunca sea así. En particular, no quiero ver que mi marco favorito se empantane por la mediocridad o la confusión de la elección de múltiples proveedores que me resulta evidente en el mundo J2EE. Afortunadamente, DHH parece decidido a que Rails continúe siendo un software obstinado para rascarse su propia picazón, en lugar de tratar de ser todo para todas las empresas.

Si habla con casi cualquier persona que tenga un sitio de alto tráfico empresarial, la mayoría de ellos le dirá lo mismo, el idioma que elija si se maneja correctamente nunca será su problema, siempre se reducirá a IO.

Si miras sitios como Twitter, seguro que tenían problemas. Pero ya admitieron que era porque las cosas no se habían escalado correctamente. Desde que implementaron los cambios, hicieron cosas que han estado avanzando.

Lo único que nos detiene aquí donde trabajo es que nadie conoce el rubí y realmente no tiene mucho tiempo para aprender.

Soy desarrollador web y ya he creado algunos sitios web de Ruby on Rails para varias compañías (desde intranet hasta sitios web de mediana escala), pero no los he usado para una aplicación a gran escala.

La gente siempre señala que es lento, no se escalará y es difícil de implementar. El "problema de escalabilidad" ya no es uno. Todavía es un poco más lento que la mayoría de los otros frameworks, pero espero que los rieles 3 arreglen esto. Ya no es realmente difícil de implementar gracias a Capistrano y mod_rails .

Los problemas reales que puedo ver con los rieles en proyectos a gran escala:

  • No hay mucha gente que conozca a Rails. Si tiene una aplicación PHP, puede estar seguro de que el 66% de los desarrolladores web podrán mantenerla. Con rieles que no es lo mismo.
  • Todavía es más lento y si la velocidad es crítica, podría ser un problema
  • Todavía necesita más componentes para el comercio electrónico, etc. Está llegando, especialmente desde shopify , pero no está tan listo como Java, por ejemplo.

Aparte de eso, creo que Rails está listo.

A menudo, solo se trata de encontrar la tecnología adecuada para el proyecto y, en ocasiones, puede ser raíles. Cada lenguaje / marco tiene inconvenientes, por lo que en algunos casos Rails no será la opción más inteligente, pero en otros casos hará el trabajo perfecto.

Además, solo espera por Rails 3 , será increíble :)

Trabajo como consultor en IBM y he creado varios sitios web para clientes que usan Ruby on Rails en el último año. Rails está sin duda "listo para la empresa". La clave es usar rieles para lo que sobresale, y usar J2EE u otras "herramientas empresariales" donde sobresalgan. Rails es excelente para la presentación de cualquier aplicación. Puede consumir servicios web RESTful sin aproximadamente 0 trabajos, y ese es un gran punto de integración para el resto de sus herramientas "empresariales".

Tal vez no usaría rails para compilar yahoo.com, pero está bien. Hay cientos y miles de nichos perfectos donde puede usar rieles, desde la Enterprise hasta las tiendas de TI más pequeñas.

Un amigo mío acaba de terminar de trabajar en RecycleBank, y estaban usando Rails para todo su sistema de intranet. Creo que Rails definitivamente está listo para la empresa, aunque eso no es lo que más se ha cuestionado. La mayoría de las personas se pregunta si puede manejar una cantidad ridícula de tráfico debido a los requisitos de memoria. Eso todavía no se ha visto, pero creo que el framework es completamente capaz de manejar aplicaciones empresariales.

Uso raíles en un entorno empresarial y funciona bastante bien. Solo tienes que moldear tu aplicación para trabajar en el entorno. En mi caso, somos una casa Java, por lo que jRuby es el método de implementación de elección.

También dejé de usar rieles para representar las páginas reales, pero lo uso para módulos, herramientas y servicios rápidos y sucios que se vinculan a las herramientas. Nuestros servicios de Java no tienen una herramienta de back-end que interactúe con ellos.

Nuestro sitio tiene cientos (posiblemente miles) de páginas, por lo que los rieles probablemente sean un candidato pobre para reemplazar esa arquitectura. Por otro lado, si integro los rieles en el sitio de Java, entonces puedo resolver algunos problemas que serían muy difíciles desde el final de Java.

La arquitectura de su aplicación es clave, si no diseña la aplicación para escalar bien, entonces tendrá problemas sin importar el marco / lenguaje que elija.

Construí una aplicación de rieles para varias páginas que reciben cientos de miles de visitas / mes. Rails lo hizo bien, pero la mayor parte del contenido se almacenó en caché. Tuvimos una instancia en la que yahoo tenía una historia destacada en la página principal vinculada a nosotros. La página tenía algunos contenidos de rieles que no estaban en la memoria caché, por lo que el enorme tráfico redujo la aplicación de rieles, pero fue parcialmente mi culpa por no optimizar mejor.

YellowPages.com y Penny Arcade son las más grandes de las que he oído hablar de la cabeza. Por supuesto, muchas empresas lo están usando para aplicaciones internas. En cuanto a la escala, el almacenamiento en caché liberal es el secreto sin importar cuál sea su lenguaje / marco.

Sí, tenemos varios clientes grandes que usan nuestras aplicaciones basadas en Rails (intranet y en la nube). La estabilidad ha sido asombrosa Por ejemplo, dos vienen a la mente como los que tienen más tráfico y complejidad: una de nuestras aplicaciones ha estado en producción durante 2.5 años con 0 problemas y otros 6 meses ahora, también con 0 problemas.