For this slide and article:
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/
-
Any coment please, any experience?,
-
Rails or not Rails for a Social network?
Thanks.
J
Juan Gutiérrez Ortega wrote in post #1143438:
For this slide and article:
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/
"In general the single app architecture is the problem, not the language/runtime/web framework. I’m sure there are ways that we could have improved the monolith, but having apps with limited responsibility gave us more value. We could have used Rails to get to this new architecture, but we felt Node with our home-grown application stack gave us more flexibility." -- Sean McCullough
This was the key comment that I took from this excellent article. This has everything do with moving from a "monolithic" web application to a modular service oriented architecture.
Did you actually read though this article yourself?
"We built the Groupon routing service (which we call Grout) as an nginx module. It allows us to do lots of cool things like conduct A/B tests between different implementations of the same app on different servers."
They essentially build their own "home-grown application stack". If you have the time, experience and manpower to do that then fantastic, go for it.
I guess what I'm saying is to consider where they started, and how they grew (and eventually outgrew) their stack. Imagine if Groupon started out saying, "We're going to build our own web stack so that when we have millions of visitors per day we can handle the traffic. We have one or two developers to get this done, and by the way we have no idea what we actually need."
Just consider how far Ruby on Rails has taken Groupon, and the success it has afforded them. There's a lot to be said about actually delivering a product/service. Rails can often still be one of the best and fastest frameworks for delivering real services. There is no "silver bullet" framework that perfectly handles everything that anyone might ever need.
Having too much traffic for your web application stack to handle is a good thing. It means your existing stack served its purpose and helped make your site a success. When you realize that success, and you have a reasonable business model, then you will have the resources to consider building your own, finely tuned, web stack tailored specifically for your needs.
This presentation was clearly written by a Java guy with a Java mindset. Yes, he talks in the presentation about how "We, the Java community, screwed up," however he clearly still has that Java mindset. An indication of this is putting static typing in the "pro" column.
Let's take a close look a reference to one of the slides in the presentation:
"Dependency injection is not a virtue in Ruby" -- DHH
Did you actually read the full article by DHH? Not just the out of context snippet pasted into the slide? If not then you should.
http://david.heinemeierhansson.com/2012/dependency-injection-is-not-a-virtue.html
I've seen dozens of articles similar to this one, and hear this practically ever day in my day job (as a Java developer no less). It's all "sour grapes" in my mind. Statements like, "Rails is good for toy blog sites" is really off-putting. But, when I hear things like this I start to consider those "toy" web sites.
I would certainly not consider sites like Basecamp, Pivotal Tracker, GitHub and the thousands of other successful web applications that use Ruby and Ruby on Rails, in full or in part, to be anything close to "toy" sites. Even sites that decided to move on to other architectures, famously Twitter, turned nothing into an extremely popular service, in large part due to starting with Ruby on Rails.
To conclude Rails, like any web framework, has its place and is a really great way to get something started. In more cases than not its perfectly capable of handling traffic and scaling out nicely. Having to worry about scaling issues is a good thing. If your current stack can't handle it then you should have the resources to address those issues.
I think if you’re planning to build a social network starting today, scaling to millions of users is the least of your problems. Getting users, and even more so keeping and monetizing said users are what you need to worry about when starting out. It’s like deciding you want to open a restaurant and then immediately focusing on picking out a soccer stadium for all your customers to sit in.
SOA is not a silver bullet - and if you’re just starting out and learning what your customers want, it may just be a regular bullet pointed at your foot. You’ll notice there are very few “we started out with SOA” success stories but a lot of “we started out monolithic, got masses of customers, and then refactored to SOA” ones. The reason (I suspect) is that SOA-up-front imposes serious costs (deployment is complicated, debugging is complicated, performance tuning is complicated) and makes changes difficult - if you’re building from scratch and it turns out the “services” you divided the code into don’t really make sense, you’re in for a lot of rewriting…
–Matt Jones