For this slide and article:
https://engineering.groupon.com/2013/misc/i-tier-dismantling-the-monoliths/
From a monolithic Ruby on Rails app to the JVM
- 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.
On Thursday, 17 April 2014 15:42:23 UTC-4, Juan Gutiérrez Ortega wrote:
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?
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 J.