Re: Recent Criticism about Ruby (Scalability, etc.)

On Fri, Oct 05, 2007 at 06:15:05AM +0900, Jay Levitt wrote:
> On Fri, 5 Oct 2007 02:03:42 +0900, Chad Perrin wrote:
> > On Thu, Oct 04, 2007 at 07:10:05AM +0900, Jay Levitt wrote:
> >> On Thu, 4 Oct 2007 04:40:52 +0900, Chad Perrin wrote:
> >>> It's close enough (again), for many purposes, to "realistic".  When you
> >>> can get roughly linear scaling up to 100 times as much scaling needs, as
> >>> opposed to trying to get similar scaling capabilities out of throwing
> >>> programmers (or programmer time) at the problem, that's certainly
> >>> "realistic" in my estimation.
> >> 
> >> A lot depends on your application requirements.  If you design it from the
> >> ground up to be "shared nothing", then you may well be lucky enough to
> >> truly HAVE shared nothing.  But you'll also have a pretty limited feature
> >> set.
> > 
> > "Feature-rich" is overrated.  Anyone who tries to be everything to
> > everyone will end up being not the right thing to pretty much everyone.
> > You only get into the kind of trouble you describe when you try to hard
> > to get *everyone* interested.
> 
> *chuckle* I do believe that's the first time in recorded history that
> anyone has accused AOL of being feature-rich.

AOL has always been "feature-rich".  It just isn't the right thing for
almost anyone at all, because when you get that "feature-rich" you get
very feature-targeted -- in that you're catering only to the people who
want all, or most, of what you provide.  People who want little or none
of what you provide (beyond basics) will go somewhere else, because that
"somewhere else" doesn't impose a whole lot of overhead.  The fact that
AOL features have often been broken, slow, and in-the-way kludgey never
changed the fact that there were a lot of them -- and, in fact, it's in
large part the sheer weight of features that made the feature set so
unusable to so many people.

Trying to trap people in an AOL-only internet, rather than letting them
seamlessly out into the Internet, was a "feature" -- it was just a
feature pretty much nobody wanted.  Most of AOL's features have tended to
be much like that.


> 
> The point I was making with all the features you snipped was that it
> *doesn't* take wild, pie-in-the-sky everything-to-everyone features to
> prevent your application from scaling linearly.  Any little thing can trip
> you up.  Most of the features I listed were either small facets of behavior
> or byproducts of other design decisions.  And some of them (e.g. saving
> disk space) were actually "scaling" features themselves; what helps you
> scale to 100x (fitting on the available disk drives) may hinder you at
> 10000x (when your servers are in different data centers).

. . . but you can get pretty close to linear scalability within specific
ranges of scaling, especially if you *avoid* massive feature lists.
Sure, they don't have to be "wild, pie-in-the-sky" features, but you
missed my point with that statement.  My point wasn't that one feature is
"everything to everyone", but that seventy features is trying to provide
exactly that without doing any one thing that, examined in a vacuum,
looks unreasonable.

In other words, if you want to minimize scalability hurdles, one of the
most important things you can do is pick a focus area.


> 
> >> What's the big buzzword today?  Social networking.  What did we used to
> >> call that?  "Community."  What was the single biggest sticky-paper
> >> community feature?  Buddy lists.  Who does buddy lists besides the Big Guys
> >> (who can throw money at it) and the really small guys (who fit on a single
> >> server)?  Nobody.  Why?  Doesn't scale linearly.  Think about what it takes
> >> to offer a feature that, for every simultaneous user, checks the list of
> >> every other simultaneous user for people you know.  Shared-nothing *that*.
> > 
> > The answer to that, from where I'm sitting, is to choose between focusing
> > on "social networking" and focusing on something else.  If you're just
> > adding it as "yet another feature" to your application to become
> > buzzword-compliant, you'll become another dot-com startup has-been.  Of
> > course, there's also always the business strategy of "look successful,
> > sell to someone big" without actually turning a positive buck along the
> > way -- and if that's what you want to do, you're on your own.
> 
> I'm not really sure what that has to do with... well, with anything.  But
> then, my point probably wasn't all that clear to you, either.  The point
> was that there's always a tension between feature-set and scalability.

That was sorta my point, too -- except that I wasy saying that since
there's a tension, you need to pick a direction, and if your direction
kills scalability that's your own fault and not disproof of the fact that
near-linear scalability is possible.  The fact of the matter is that the
same things that break linearality of scalabilty for your software are
the things that break linearality of scalability for everything else,
too.  You may start watching your "everything to everyone" business plan
circling the drain, now.


> 
> On the other hand, I find it remarkable that a huge crop of "social
> networking" sites have become immensely popular without the most obvious
> social networking feature - who else is here? - because that feature just
> doesn't scale.  It would be like if e-commerce grew to its current levels
> without real-time credit card processing, or if Flickr only let you upload
> ASCII-art of photos because photos are too big to store.

I don't find that so odd.  The "most obvious" social networking feature
is actually not all that great a feature for a new business venture.  It
was solved a long damned time ago with technologies like IRC.  It's not
new.  The other stuff being implemented by all these "social networking"
sites *is* new, at least in an Internet context -- or presented in a new
manner.


> 
> > You don't always have to write shared-nothing code to get near-linear
> > scalability -- and it's true that near-linear scalability is something
> > that only exists within certain ranges before you hit a cost or resource
> > requirement spike, but if you're smart you plan ahead for those kinds of
> > things.  Things don't always go as planned, of course, but if you're
> > smart you plan for *that*, too, by setting aside "money for a rainy day"
> > and ensuring that, short of your main datacenters and every off-site
> > backup in the world being eliminated by meteor strikes simultaneously,
> > any major scaling issues will not require a sudden "right now" fix.
> 
> I both agree and violently disagree.  The problem with "if you're smart you
> plan ahead" is that (a) you often won't know what your pain points will be
> until shortly before you hit them, (b) even if you do, they may not be in
> your control, and (c) you don't always know how fast you're going to grow.
> It would be foolish for me to invest in a large Arizona data center in case
> the traffic to my last-updated-in-2005 blog spikes 10000x next year.  (And
> I do keep promising my financial advisor that I'm selling the data center.)  
> 
> But sometimes externalities do hit your business; it becomes "steam engine
> time", and you're the steam engine.  Verizon nee AT&T nee the Bell
> Telephone Company had, literally, over a hundred years of experience
> telling them how much their business would grow each year.  And that worked
> very well until 1995, when all of a sudden the online world was booming,
> people were leaving their phones off the hook even when they weren't home,
> and suddenly they ran out of dial tones.
> 
> Luckily for them, they were the phone company; nobody had anywhere to run.
> But if they were in a competitive business, they'd be toast, because
> someone would fill the need that they couldn't.  Remember Friendster?
> Great idea, great product, right time, couldn't scale as quickly as their
> user base, slow site, toast.

I don't generally like to be so harsh, but . . . if you plan badly, your
plan fails.  Sorry to burst the bubble for anyone who thinks that hard
work and good intentions should automatically translate into success.
This is not something that can be blamed on the potential scalability of
well-written software.  The blame for that rests entirely at the feet of
those who made the planning decisions in the first place.


> 
> > I'm curious how any of this is meant to support the position that a
> > faster-executing programming language that imposes greater hurdles on
> > programmer productivity will be a better investment for scalability than
> > designing a system that can absorb greater loads by adding hardware
> > resources.
> 
> It isn't.  Elsewhere in this thread, in fact, I was arguing that programmer
> productivity is far more important to orders-of-magnitude scalability than
> raw language performance.  I agree with you on that.  Where I disagreed was
> that it was realistic for "many purposes" to assume linear scalability.
> Show me any site design and I'll show you a dozen places it falls over at a
> few orders of magnitude.

Show me where it falls over at a few orders of magnitude, and I'll show
you software that is being misused -- or, looked at from the other
direction, miswritten -- if it's being written well at all.  If it's not
being written well at all, that's pretty much irrelevant to my point
anyway, since poor software development can kill anything.

This is why focus is important: when you're trying to be all things to
all people (the all-singing, all-dancing, dish-washing performing
monkey), there's no give in any area to make compromises so that in other
areas it'll scale, because there's nothing you don't need out of a
system.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade. 
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?