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

On Fri, 5 Oct 2007 06:41:13 +0900, Chad Perrin wrote:

>> *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".  

OK, the first time got a chuckle.  The second time gets a "what AOL were
you smoking?"

Seriously.  You're a techie, not in AOL's targeted "novice" market, so I
assume most of your interactions with AOL were (a) commercials involving
Batman, (b) free DVDs in your cereal box, and (c) friends and family that
asked you for help in uninstalling it.  So I can understand if you got the
wrong impression of AOL, and all the shiny lights impressed you.

Experience is subjective, and all that, so I can never know the AOL you
used.  All I know is the AOL I wrote.  And it had like a dozen features
visible to the user.

Seriously.  The features boiled down to:
- Get connected (by some modem bank near you, hopefully)
- Get registered (and choose a pricing plan that you like)
- Get mail, with a friendly voice, and send some, too
- See a welcome screen ("portal!") that told you what might be interesting
- Go to chat rooms
- Send instant messages (and later see a buddy list)
- Message boards and software libraries 
- Navigate graphical or text forms, all of which either led you to other
forms, or text articles, or gateways to outside information services (news,
weather, etc).
- Eventually, ta-da: Go to the web, or at least a small, embedded version
of the web.

That's about it.  The vast majority of the server-side software deals with
the implementation details of it all; drilling down to specify exact
behaviour for each use case, or "drilling out" to see what reporting,
billing, maintenance, scaling, security, etc. requirements are implied by
the design.

The AOL software, even in its current "most advanced ever" form, still
doesn't have a fraction of the features that your average web browser, mail
client, or - heck - text editor has.  The reason it's "so easy to use it
[was] #1" is that any request to add any feature went through a very
thorough vetting to predict how many people would actually want that
feature, and how many novices would be confused by it.  That's not a recipe
for feature bloat.

> 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.

Well, there were a few things that led AOL down that path. 

The first was the most pragmatic:  AOL was launched and well-established
before the idea of "commercial internet access to the masses" was even
considered feasible.  I don't remember exactly what year the rules changed
to allow commercial providers to resell Internet access, but AOL's
infrastructure was starting to take shape in 1982, and our core servers
didn't even speak TCP/IP well.  So the bolt-on nature of most of the early
Internet-related features was a function of legacy design.

The second was the very quick realization that we WERE the Eternal
September everybody feared.   If AOL handed everyone a fresh copy of
Internet Explorer, put them through two weeks Computer Camp, gave them a
list of web sites, and said "go!" the world would have been crushed by the
weight.  AOL actually had to provide the cushion, in the form of caching
proxies - which, yes, had many of their own flaws.

I know that on the engineering side, as the large-scale Internet grew up
around us, we spent most of our time trying to figure out the best ways to
leverage the new technology and retire our decade-old kludges.  L2TP
replaced many parts of the internal client-to-server protocol, and the
back-end mail system now natively supports a lot more IMAP functionality
than it was ever designed to do.

But I can babble about AOL all day, I can see your criticisms and top them
tenfold, but nobody really cares about that ancient history.

I use AOL as an example in this scaling thread because people are talking
about what it takes to scale an application, and we seem to have agreed
that we're now talking about orders-of-magnitude scaling, not just "Should
I define more mongrels" scaling.  And I've got lots of experience in
knowing what does and doesn't scale, and what the early warning signs are
and what they aren't.

And the point I keep trying to make, though you keep deflecting it, is that
there ARE no guarantees that if you "do everything right" with a focused
business plan and a lightweight feature set, you're golden for scaling.  Go
back to the little list of AOL mail features I posted, and realize that not
a single one of them scales linearly.  And realize that you might well
implement a feature like that in a different system, maybe even without
thinking about it, because it's not a big deal.  (Let's select a nicer
screen name for someone if they can't find the one they want.)

And those features are the ones that bite you, more so than the "you tried
to be everything to everyone" features that seem to worry you.  AOL wasn't
an Enterprise-Grade Solution System Provider Framework for Communicating
Entity Value Relations among Stakeholders; that type of "a something to do
somethings" overgeneralization stays in the enterprise world.  AOL was just
a way to talk to people.

-- 
Jay Levitt                |
Boston, MA                | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm         | - Kristoffer