Ruby On Rails是否已为企业准备好了?
有人在使用RoR进行大规模,关键业务的企业应用程序吗?
还有其他基于人们用于这些类型的应用程序的动态语言的轻量级Web框架吗?
如果我们不使用这些类型的应用程序框架,那么阻止是什么?它仅仅是与任何大型IT组织相关联的惯性吗?这些框架的速度和稳定性问题是否足以抵消开发周期的改进?
解决方案
回答
我的一个伙伴刚刚在RecycleBank工作,他们将Rails用于整个Intranet系统。我认为Rails肯定已经为企业做好了准备,尽管这并不是大多数人所质疑的。由于内存需求,大多数人都质疑它是否可以处理大量的流量。这仍然有待观察,但是我认为该框架完全能够处理企业应用程序。
回答
YellowPages.com和Penny Arcade是我听说过的最大的事情。当然,许多企业正在将其用于内部应用程序。就扩展而言,无论我们使用哪种语言/框架,自由缓存都是秘密。
回答
如果我们与运行高流量企业站点的几乎任何人交谈,他们中的大多数人都会告诉我们同样的事情,如果处理正确,我们选择的语言将永远不会成为问题,它总是归结为IO。
如果我们查看Twitter之类的网站,请确保它们存在问题。但是他们已经承认这是因为事情没有按比例缩放。自从他们实施了更改以来,他们所做的事情一直在进行。
使我们停在这里工作的唯一原因是没人知道红宝石,也没有太多时间去学习。
回答
我还是没卖。 Twitter发生了严重故障(一次播放3天!)。在某种程度上,它被归咎于扩展RoR背后的困难:请在此处阅读。
/ mp
回答
我对大多数回复的积极程度感到非常惊讶。我是Ruby和Rails的忠实拥护者,并且同意我所说的一切,但是我认为社区中普遍认为" Rails尚未准备好迎接黄金时段"。 (考虑到社区通常比我想象的该站点的用户了解的少)
我认为从技术角度来看,其他人提出的示例表明,实际上,我们可以从Java或者.Net堆栈期望的Rails中获得正常运行时间和性能。问题是,我们无法使用每小时30美元的程序员在Rails中构建那些高性能,可靠的应用程序。 Ruby和其他动态语言似乎使出色的程序员变得异常高效和高效,但同时,它们也削弱了一般的程序员。考虑到绝大多数大型IT商店已选择提高他们可以找到的最便宜的代码猴子,我认为对于他们来说,尝试引入Rails来替代Java或者.Net将是一个非常痛苦的过渡。
回答
I think the 37Signals guys have built all of their applications using Ruby on Rails
我可以想象,毕竟他们是发明它的人。
List Apart使用RoR,虽然不是企业级的。
回答
我是IBM的顾问,在过去的一年中,我已经为使用Ruby on Rails的客户建立了多个网站。毫无疑问,Rails是"为企业准备的"。关键是要使用Rails的优势,并在它们擅长的地方使用J2EE或者其他"企业工具"。在任何应用程序的演示端,Rails都很出色。我们可以使用RESTful Web服务而无需花费大约0的工作,这对其余"企业"工具来说是一个很好的集成点。
也许我不会使用Rails来构建yahoo.com,但这没关系。从企业到最小的IT商店,都有成千上万个完美的利基空间可供我们使用。
回答
为了考虑Ruby on Rails是否已为企业准备就绪,我们必须考虑"企业"一词的含义。以我的经验,企业意味着"安全"。寻找企业解决方案的公司通常会选择大型供应商支持的技术堆栈。这样,他们知道他们可以得到支持和咨询,以换取大量的金钱。这就是整个"没有人因购买IBM而被解雇"的方法。
要考虑的另一个因素是普遍性。毫无疑问,现在Ruby仍然被视为一种外来语言,熟练的Ruby程序员的出现反映了这一点。从技术上讲,Ruby比Java或者C#更复杂,就OO纯度而言,它更接近Smalltalk,而在元编程工具方面,它更接近LISP。可以说,与Ruby程序员相比,公司将发现以较低的价格从车身修理厂获得Java或者.NET程序员更容易。这并不是侮辱Java或者.NET程序员,而是在反映这样一个事实,即许多雇主仍然将软件开发视为最便宜的竞标者来完成,而不是应做的事情。 Java和.NET程序员现在几乎成了商品,因此可以以更低的成本提供。
从技术上讲,Ruby on Rails可以像Java,.NET或者PHP等一样进行扩展。相同的基本原理适用于测量瓶颈在哪里,调整SQL查询,最小化I / O,在适当时可能对数据库模式进行规范化以及明智地使用缓存等。如果我们确实需要构建下一个eBay或者Amazon,则应该手动滚动和手动调整自己的解决方案,就像eBay和Amazon所做的那样。 J2EE在遗留集成方面具有优势,但这并不是Rails进行了优化的用例。Rails只是构建新的CRUD应用。
毫无疑问,就目前而言,Ruby是性能较慢的语言之一。在该领域已经进行了大量投资,因此,希望这种情况在未来几年内会有所改善,就像Java自问世以来所做的一样。在Ruby VM和MRI(Matz Ruby Interpreter)的替代品方面,发生了许多有趣的发展。我个人认为JRuby是值得关注的对象。它得到了Sun的支持(如图),并且因为它是Ruby的Java实现,所以它是一个整洁的特洛伊木马,我们可以使用它通过现有的JVM基础架构将Ruby引入企业。
我认为Rails尚不适合企业使用,从很多方面来说,我都希望它永远不会存在。我不特别希望看到我最喜欢的框架因J2EE领域中对我的显而易见的多供应商选择的平庸或者混乱而陷入困境。令人高兴的是,DHH似乎认为Rails应该继续成为自以为是的软件,以挠自己的痒,而不是试图成为所有公司的万事通。
回答
Twitter的故事似乎散布了" Rails无法扩展"的字眼。同时,LinkedIn使用Rails创建了一个Facebook应用程序,该应用程序每月处理1B页面浏览量。
我接受他们提出的论据,即可扩展性问题不是我们使用哪种语言/平台的产物,而更多地是关于如何在该平台中实现事物的。
回答
IBM,Oracle,Sun和JPMorgan Chase只是使用Ruby on Rails的公司中的少数。它可能没有比这更具有企业精神的了。
回答
我认为许多人对"企业"一词的真正含义感到困惑。 YelloPages.com和Penny Arcade不是企业应用程序。当然,他们可能拥有大量的用户和点击/分钟,但它们是相对简单的应用。
企业应用程序是用于运行企业的应用程序,通常意味着大型的多部门,多地点的公司。 SAP是企业系统,BaseCamp不是。
我们通常会在企业应用程序中看到的一些特征是:
- 它们又大又复杂。一个典型的ERP系统需要处理100种实体类型。
- 他们通常需要与其他系统集成,并需要为第三方提供集成点。
- 他们具有大量不同的用户类型和角色,在很大程度上反映了大型组织中的不同工作类型。
要回答问题,我会说是的,Rails已准备就绪。我们目前正在为拥有20个部门的1000多个用户的公司开发大型系统财务管理系统。可伸缩性对我们来说不是一个大问题,但可靠性和可用性却是。无论采用什么技术堆栈,解决该问题都是相同的。
我要重申其他人对熟练的开发人员的观点,但这再次适用于任何技术堆栈。让普通的开发人员在非关键的小型系统上工作可能是可以的,但是如果我们认真地开发关键且在整个企业范围内的应用程序,则最好让最聪明的人来工作。
回答
我们主要将Ruby on Rails用于"企业"关键业务应用程序。对于我们来说,将Ruby与其他"企业"系统集成起来要容易得多,例如:
- 我们在Oracle数据库之上使用Rails
- 我们将Rails应用程序与Oracle电子商务套件(ERP和CRM系统)集成在一起
- 我们将用户身份验证与LDAP目录,NTLM Windows域身份验证,Oracle电子商务套件身份验证集成在一起
- 我们构建REST和SOAP Web服务以与其他系统集成
有许多"企业"集成平台应该执行此类操作,但它们通常成本很高,而且我们经常陷于某个问题,然后我们取决于供应商是否会解决问题。
使用Ruby和其他开放源代码组件,我们始终可以自己解决问题,因为我们可以深入探究问题的根源,并且没有任何隐患。
因此,如果我们有聪明的开发人员愿意解决难题,那么Ruby将是他们的绝佳工具。但是,如果我们有普通的开发人员不想学习任何新知识,并希望供应商能够完成他们的工作,那么Ruby可能不适合他们。但是我怀疑普通开发人员是否能够使用任何工具创建出色的软件。
回答
这是我的看法。我的公司(拥有120,000名员工)主要具有用于内部IT的Java / J2EE堆栈。他们还使用Sharepoint进行文档/知识管理,并使用Oracle应用程序进行工作流等。在过去的两年中,我带领一小群Ruby on Rails / Python-Django / PHP爱好者积极地在企业内部推广采用这些框架。我们遇到的通常(通常无效)的论点
- 它不会缩放
- 对企业来说不够安全
但是,我们设法推出了一些应用程序(用于博客的Wordpress,自定义构建的Yahoo答案,例如内部社交问答应用程序和基于Digg风格的Rails的Idea / Innovation mgmt应用程序),并且情况确实很快发生了变化。现在,Rails / Django及其同类产品实际上对于某些类的企业应用程序可能会更好,尤其是在KM,工作流等领域中的简单,轻量级应用程序,这是一个强有力的支持。
回答
由于我的日常工作全都与企业体系结构有关,因此我相信"企业"一词不仅与规模和规模无关,而且还涉及软件产品的销售方式。
例如,Ruby on Rails不是企业级企业,因为没有供应商会进入商店并为开发人员社区反复进行Powerpoint演示。 Ruby on Rails没有销售主管可以带我去高尔夫球场或者我最喜欢的餐厅吃午餐。 Ruby on Rails也没有被Gartner这样的行业分析公司深深覆盖。
在这些事情发生之前,Ruby on Rails永远不会被视为"企业"。
回答
我是一名Web开发人员,我已经为多家公司(从Intranet到中型网站)构建了Ruby on Rails网站,但是我还没有将其用于大型应用程序。
人们总是指出它运行缓慢,无法扩展且难以部署。 "可伸缩性问题"不再是一个真正的问题。它仍然比大多数其他框架慢一些,但是我非常希望Rails 3可以解决此问题。多亏了Capistrano和mod_rails,部署起来并不难。
我可以在大型项目上看到的真正问题是:
- 知道Rails的人并不多。如果我们有PHP应用程序,则可以肯定有66%的Web开发人员可以维护它。使用rails是不一样的。
- 它仍然较慢,如果速度至关重要,则可能是一个问题
- 它仍然需要更多的电子商务组件。它到达那里,尤其是自shopify以来,但是它还没有像Java那样准备就绪。
除此之外,我认为Rails已经准备就绪。
通常,这只是为项目找到合适的技术的问题,在某些情况下可能是轨道。每种语言/框架都有缺点,因此在某些情况下,Rails并不是最明智的选择,但在其他情况下,它会做得恰到好处。
另外,只需等待Rails 3,它就会很棒:)
回答
我在企业环境中使用Rails,并且效果很好。我们只需塑造应用程序即可在环境中工作。就我而言,我们是一家Java公司,因此jRuby是首选的部署方法。
我也停止使用Rails渲染实际页面,而是将其用于模块,工具以及链接到工具的快速而肮脏的服务。我们的Java服务没有与之交互的后端工具。
我们的站点有数百个页面(可能是一千个页面),因此用Rails替代该体系结构可能不是一个好的选择。另一方面,如果我将rails集成到Java站点中,那么我可以解决很多问题,这些问题从Java端来看都是非常困难的。
应用程序架构是关键,如果我们设计的应用程序无法很好地扩展,那么无论我们选择哪种框架/语言,都将遇到问题。
我确实为多个页面构建了一个Rails应用程序,每个月获得数十万次点击。 Rails表现不错,但是大部分内容都已缓存。我们曾经遇到过一个案例,其中雅虎的头版故事与我们相关。该页面包含一些非缓存的Rails内容,因此大量的流量使Rails应用程序瘫痪了,但这部分是我的错误,因为它无法更好地进行优化。
回答
我不知道我是否认为它是企业级的……但是我认为,twitter和hulu都是基于Rails的,这说明了很多。
回答
目前,我们正在将Rails用于每月拥有500万唯一身份的网站,并取得了巨大的成功,因此,如果企业=规模,那么可以。
回答
我一定会阅读Ruby On Rails的这个案例研究
In this article, I'll walk you through the way we're using Ruby on Rails to build the site. You'll see the core features we're using, as well as the primary plugins that we depend on every day. Most of our technology isn't really earth shattering, but I hope to give you a glimpse inside our day to day operations. My aim is to give you a broad overview of how the team works, the technology we trust in the production environment, the tools we use, and the Rails frameworks that are most important to us. I'll link to a resource rather than going into great detail in any single area, but if you want to know more about any part of it, leave a comment.