9 ms·
Twitter: From Ruby on Rails to the JVM [video]
- jsavimbi 15y agoAnyone pondering their technology stack should watch this video. It doesn't matter what you initially employ as a technology/framework/server to get your app up and running, but if you need to scale the JVM is were it's at. I say that as a Rubyist.
- mattdeboard 15y agoI was surprised when I got some pushback on this concept at a local Django meetup last week. A lot of people believe that Python & Ruby-type languages are the backend languages of the future.
- wwkeyboard 15y agoIt all depends on the problem. Dynamic languages like Ruby and Python are good for rapid development, but not for high volume, soft realtime problems like Twitter has. Just make sure to match your tools to you problems and try and oddly hack a solution with a tool that is not best for the job.
- mattdeboard 15y agoYeah my contention was that they're great for certain phases but once you start reaching scaling problems the JVM might be the better solution.
- cdavid 15y agoAlso, twitter is at a point where they can afford the best programmers, and where hardware efficiency becomes a big issue. In my experience, a lot of web-based small companies are more limited by skill, development practice than language and hardware usage. Only once you solved the former can you focus on the latter.
- cageface 15y agoTo be fair, you're very unlikely to ever have to solve the kinds of scaling problems Twitter has had to solve. You'll get your app off the ground faster with Python or Ruby.
- jsavimbi 15y agoYou will get your app of the ground faster, but you're selling yourself short if you're a technology-based company thinking that you'll never have scaling problems. Competing against Twitter or any other social-based app you'll probably never encounter that level of scale, but any financial application will need to be both fast and handle the complexities that only the JVM can address. Like he states at the end of the video, when describing the 7000+ tpm during the WWC: "...we do things like Forex spikes upon our standard baseline growth. So right now the JVM is really the only mechanism that we can build upon that gives us the flexibility to do something like that."
- cageface 15y agoPlenty of companies do huge transaction volumes on dynamic languages. Twitter is a freak outlier. If you try to solve problems long before you actually have them chances are you'll come up with the wrong solutions.
- gcampbell 15y agoI'm pretty sure he said "4x" rather than "Forex".
- jsavimbi 15y agoGood catch, and make sense given the context. My mind is stuck in HFT mode and constantly has me worried.
- jsavimbi 15y agoPeople are going to defend their language of choice, but I have to look up to see what the big dogs are doing, try and understand why they're doing it and what type of influences they're under when it comes time to choose a technology stack to address and solve a problem. Ruby, and Python to certain extent with Django, suffers from the Rails attitude of opinionated development where either it's all Rails or nothing, because that's what they're used to developing and feel uncomfortable outside of it, or worse, are under the impression that Rails is the end-all. That simply doesn't work in a scaling environment. I've found that Java developers are not only easier to recruit due to their shear numbers, but are more receptive to other avenues of approaching a problem and have a better set of skills with which to approach it or are at least able to migrate to other technologies, like Scala for example.
- delambo 15y agoComing from a Java workshop, I have noticed the exact opposite - the majority of Java developers I have worked with are unwilling to touch or experiment with anything other than Java, even languages on the JVM like Scala; alternatively, I have noticed python developers are much more open and agile when it comes to moving in and out of other languages.
- jsavimbi 15y agoIn retrospect, I should've said depending on the environment and the willingness of the devs involved, but yeah, they always find a way back to Java.
- kemiller 15y agoCould that be because the experimental ones have already moved into Ruby/Python years ago? The Rails world certainly has a lot of ex-java programmers.
- ibejoeb 15y agoThey are the languages of the present (and future, for a while I'm sure), but the JVM is the platform to write these languages to.
- petercooper 15y agoDirect YouTube link: http://www.youtube.com/watch?v=ohHdZXnsNi8 http://www.youtube.com/watch?v=ohHdZXnsNi8
- rhizome 15y agoOP is an ontwik posting bot. Thanks.
- sscheper 15y agoSurprised no other person brought this up.
- petercooper 15y agoOntwik clearly provides some sort of service, if only to dredge up YouTube videos that we've otherwise missed.. but I can't help but feel there's a "better way" for these videos to be discovered than a site that just embeds and adds no editorial context.
- rhizome 15y agoOf course there is: one can post a link to the YouTube to HN with a title that describes the content. No separate website necessary.
- angerman 15y agoOne thing that wasn't touched was JRuby[1], on their site they state high performance and real threading as advantages. If twitter has (some of) the best ruby developer (mentioned somewhere at the end of the video), why have they neglected JRuby? Why is it no option? For legacy code with native extensions this makes sense. But is jruby slower, more memory hungry on the JVM then scala or clojure? I always though that JRuby was one of the more performant languages on the JVM? Apart from that it was an interesting talk. [1]: http://www.jruby.org/ http://www.jruby.org/
- cageface 15y agoJRuby is fast for a Ruby implementation, but it's still far, far slower than Scala or Java itself. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=jruby&lang2=scala http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
- bad_user 15y agoI do get that a dynamic language like Ruby will always be slower than a language like Java, which has primitives and where many things, including static method calls, are solved at compile time. But citing the Alioth.Debian benchmarks? Really? Dude, take a look at the source-code of those benchmarks sometimes -- they are completely useless ;)
- netghost 15y agoIf you want a fast dynamic language, take a look at Lua. It's surprisingly fast, especially LuaJIT, and pretty straight forward (almost boring really). The main downside is that there isn't the breadth of community around it.
- cppsnob 15y agoLua's threading is just as broken as Python or Ruby. Maybe even more so.
- 15y ago
- troymc 15y agoI noticed that every time Twitter acquired a company, they also accrued a new language: * Summize brought Scala * BackType brought Clojure Has anyone noticed that pattern elsewhere?
- skrebbel 15y agoA bit boring, but Google comes to mind.
- jorgeortiz85 15y agoTwitter started looking at Scala before the Summize acquisition. Also, to my knowledge, Scala was not being used at Summize.
- rrrazdan 15y agoI was recently in a quandary over the choice of technology. I started RoR and I really like it. However I was concerned about long term implications of that choice. The thing that I am taking from this talk is that I shouldn't worry about that, right now. If and when I need to scale, I will have enough resources to make a better choice. Resources that I don't have right now.
- xal 15y agoShopify is still 100% ROR and we serve hundreds of millions of requests. You will be fine :-) It's a competitive advantage for us, we move faster then the rest of the market.
- lionheart 15y agoWell, correct me if I'm wring but Shopfiy is a completely different scaling problem from Twitter. As I understand it Shopify's individual hosted stores are pretty much self-contained. So you can pretty much stick each one on it's own server with it's own database and it'll be fine. Twitter accounts all have to be able to talk to eachother in real time so you can't do that. My current startup has a Shopify-like architecture which is what I'm counting on to help me if I ever need to scale fast. So I think the first question you have to ask yourself when considering scaling is: what is my architecture like?
- jsavimbi 15y ago> So you can pretty much stick each one on it's own server with it's own database and it'll be fine. That is not a scalable solution. Yes, it'll get you up and running out of the box, but as you keep spinning up servers to host each store and it's database you'll have to keep adding exponential resources (hardware, software, meatware) to the problem and keep you from achieving economies of scale.
- psykotic 15y ago>Yes, it'll get you up and running out of the box, but as you keep spinning up servers to host each store and it's database you'll have to keep adding exponential resources (hardware, software, meatware) to the problem and keep you from achieving economies of scale. No, you'd be adding resources at a _linear_ rate relative to the growth of the customer base. The point about economies of scale is true enough but has nothing to do with a lack of exponential growth in costs.
- sahglie 15y agoWith the release of Java 7 (invokedynamic) the performance of these dynamic languages (like ruby and python) may become much less of a factor (JRuby and Jython). At least that's what the JRuby folks imply: http://www.engineyard.com/blog/2011/jruby-1-6-released-now-what/ http://www.engineyard.com/blog/2011/jruby-1-6-released-now-w... Punch Line from Link: "There’s a very real chance that invokedynamic could improve JRuby performance many times, putting us on par with our statically-typed brothers like Java and Scala. And that means you can write Ruby code without fear. Awesome."
- mark_l_watson 15y agoRight on! I was going to make the same comment until I saw yours. Charles Nutter has been very enthusiastic about invokedynamic based speed improvements - can't wait. A little off topic: as a consultant it seems like the demand for Clojure was been tremendous: Clojure is a nice language and very performant. It will be really interesting to see how much large speed improvements in JRuby will cut into Java's, Clojure's and Scala's developer market-share.
- equark 15y agoIs there any evidence this is actually true? Currently, IronPython and IronRuby do not have great performance on the CLR despite dynamic support.
- igouy 15y agoJRuby JVM 1.6.0_25 :: JRuby JVM 1.7.0 http://anonscm.debian.org/viewvc/shootout/shootout/website/websites/u32q/data/data.csv?r1=1.775&r2=1.776 http://anonscm.debian.org/viewvc/shootout/shootout/website/w...
- gcampbell 15y agoIf any of this stuff sounds interesting to you, we're hiring for all sorts of positions: http://twitter.com/jobs http://twitter.com/jobs
- hello_moto 15y agoMany people seem to refer only the scalability (performance, that is) side of the argument but only few who actually pointed out the developer's productivity of choosing Scala and Java for Twitter situation. http://www.infoq.com/articles/twitter-java-use http://www.infoq.com/articles/twitter-java-use
- schumihan 15y agoAgreed. You can achieve very high productivity if you use Scala and Java properly.
- neduma 15y agoAny thoughts solving scaling issues with node.js..
- stock_toaster 15y agoUntil node gets some type of bind-fork-accept mechanism (built in) to utilize more than one cpu in a native and simple fashion (cluster/multi-node are close), I feel it will not gain the same level of traction that java has. People also have opinions about java(scala/clojure) vs javascript from a language preference standpoint. I think it is too early to tell what impact this will have. However, many developers I know seem to have a strong distaste for Java, the JVM, and the ecosystem around both. I think several of those folks would look to node, erlang, or possibly even golang (if it gets faster) simply to avoid using java.
- hello_moto 15y agoI noticed that the people who have a strong distaste for Java are largely application-developers. In most cases, these developers usually just work with the available libraries or APIs to build a website backed by database (some of them are consultants that build similar apps over and over again). Back-end developers seem to (maybe?) prefer to use Java.
- veemjeem 15y agoWhere are you pulling your hunch from? If anything, most of the ruby & node developers came from the back-end world of Java. I know I'm one of these people. Backend java developers have to use configuration heavy IOC frameworks like Spring, Guice, Hibernate, etc, whereas most of these ideas can be emulated in a more flexible language like Ruby.
- hello_moto 15y agoGuice is configuration heavy? That's the first time I've heard about that. The last time I used Spring, I only have to provide one applicationContext.xml file that contains the XML header (XSD stuff) and 1 line of configuration to inject _every_single_injection_required_for_my_app_ Things changed. Perhaps I was misusing the word "back-end". When I refer to app-developers, I'm pointing toward people who build web-apps using Struts, Spring, JEE, EJB (I see where you think that back-end means completely EJB/Service/Hibernate). The non-app-developers seem to keen on building infrastructure around the Java ecosystems: Hadoop, HBase, Cassandra, ZooKeeper, custom server using Netty or Apache Mina. Or even building platforms such as GWT, Android.
- MrMcDowall 15y agoNo one will ever be in the position of handling so much real-time data as Twitter is. The rest of us can just get on with it and stop trying to pre-empt situations that will probably never happen to us.
- xentronium 15y agoMany companies in financial sector handle similar workloads. I know a couple of HFT shops, they're all java.
- MrMcDowall 15y agoFor sure, I was meaning from the perspective of a startup. There's obviously existing industries where real-time data is big, but they don't tend to be web fronted serving hundreds of millions of users.
- moe 15y agoI'm still not getting the futz they're making over their "scale". So your inbound load is 7000 tweets/sec or roughly 250 MBit/s (assuming 4k per tweet). Then you fan that out to (assuming) 20 append-only mailboxes on average. Perhaps my assumptions are far off, but I'm only arriving at a couple GBit/s here and a low two digit number of terabytes/storage per year. This sounds like "a couple racks" to me, not like "a couple datacenters".
- gnuvince 15y agoAs I understand it -- and I might be wrong here -- the inbound traffic is not the real problem; it's the distribution to all the followers. If you have 7000 tweets coming in and you need to send it to the 120 followers of all these posters in real time, that makes a lot of data shuffling.
- lenn0x 15y agoHere is an old presentation from a year ago. http://www.slideshare.net/nkallen/q-con-3770885 http://www.slideshare.net/nkallen/q-con-3770885 Now, at the time they were doing peak 2000 tweet/s. The fan-out was 1.2M deliveries a second... So if we go with the current 600:1 ratio at 7000/s, that's about 4.2M/s. I actually know it's much higher now since I work there but other things to consider is we have a large data warehouse, search, API, pipelines to external parties for the firehose, logging at terabytes an hour, in-house metric collection doing 3M writes/s, etc. http://www.scribd.com/doc/59830692/Cassandra-at-Twitter http://www.scribd.com/doc/59830692/Cassandra-at-Twitter It add's up very fast.
- SonicSoul 15y agovery interesting talk. I was surprised that there was no mention of using a lower level language i.e. c or c++ in order to maximize cpu/ram utilization. while JVM is a clear winner over ROR it does add some overhead. I guess it is a sweet spot between performance and code manageability.
- swiharta 15y agoI'm pretty sure the project I'm working on will be the next Twitter, and this video's making me second guess staying with RoR.
- hkarthik 15y agoPart of the problem is that any typical Web Application framework is ill suited to building a full real time system like Twitter. I doubt their story would have been much rosier if had they gone with Spring MVC, Hibernate, and Oracle from the start. The minute you start moving away from CRUD based application design and moving into SOA, you're already signing up for a significant rewrite, even if you stick with the same platform.
- eurohacker 15y agois there any good site that would explain when to use what technology - like when you need many concurrent users then dont use ROR but use JVM or C++ or Scala instead, if you need to build a fast prototype build on ROR or PHP etc.
- lhnn 15y agoAn ignoramous question: Aren't there faster languages than Java?
- jingweno 15y agoI think most people misunderstand the point made by Raffi...yes, JVM has awesome performance, but never try to solve performance issue up front by sacrificing the agility offered by RoR. Not everyone is building Twitter, you don't even know whether you will hit the point where the VM is blocking your way. If you blame all the performance issue to the VM level, you are simply doing it wrong...In 90% of the cases, MRI is fast enough and meet your requirement (GitHub, Groupon, Living Social and many others are using RoR BTW). Twitter is very pragmatic at this respect, they have tried all the means to scale the app on RoR before they move to the JVM. Never ever try to solve a requirement that doesn't even exist in your own app...
- jingweno 15y agoThe point is you probably never need that performance gain on the VM level (YAGNI) at all. Things are changing very fast in software development, your project could die or fail long before you really think about performance optimization on the VM level. But when you start a project and think that my project will fail because I use Rails and Rails doesn’t scale, you are doing it all wrong! What you really need is a tool that helps you iterate faster. Rails falls into this category. And that’s the productivity gain that I am thinking when starting a company. As a pragmatic approach, a half century of software engineering says that you should write the code first and worry about making it faster only if it is too slow. Donald Knuth is right: Premature optimization is the root of all evil. Don’t merely let the VM performance metric blind you to this fundamental truth. If you are chasing for a performing language, Java/Scala is not your ultimate solution, C/C++ is, even Erlang. I actually don’t see a problem with “performance” emerging as the requirement in the Ruby world sooner than others, say Java/Scala, because this “sooner” is very contextual and depends a lot on the implementation. To give you more info, GitHub is on RoR since it started, and till now they haven’t hit the so-called “Rails does not scale” point ( http://teachmetocode.com/podca.. http://teachmetocode.com/podca... ). So are many other projects. Besides, think about Twitter, they only recently try to port everything to the JVM, after Rails has served them a couple years. All these facts tell you, this “sooner” may never happen to your own app, and most importantly, Rails can scale, although it may not scale as well as others! But once you hit the point where Rails, or Ruby in general, doesn't meet your performance requirement (assuming you are lucky enough to build another Twitter), do what Twitter suggests you to do in the video. Is that too late? Not at all. Because by then, you have the resources to do whatever you want, even inventing a VM that is more performing than JVM. To summarize, the Ruby VM was fast yesterday, is still fast today, and will be faster tomorrow. In 90% of the cases, it's just fast enough. Do I need the performance gain by switching to JVM? Don't know yet. It'd be better to let the market drive you. Does Rails provide the agility I want to start a project? 100% hell yeah!