Factoring over Scaling (was: Another server question (mixing node.js and LC))

[Richard Gaskin]

It's easy to get excited about C10k problems, and I got caught up in it 
myself.  Geeks love this stuff.  It's hard to resist.

But once the coffee wore off, I changed hats and reconsidered this 
problem from the standpoint not of an implementer, but a business owner.

Here's the core of the business need, summarized from two posts:

jonathandlynch wrote:
 > A given transaction involves processing a user request, making two
 > or three requests to the database, and returning around 500 kB to
 > the user.
...
 > Basically, I am soon going to start pitching augmented tours (idea
 > suggested by guys at a business incubator) to tourism companies, using
 > Augmented Earth, and I don’t want to have the server crash if a large
 > number of people are using it all at once.

Questions to consider, not for us but for your business planning:

- How many users will be an achievable maximum?

- How many users do you have today?

- What is your attrition rate?

- How long will it take you to get from your current
   user base to that maximum?

- What marketing plan will be needed to acquire those
   new customers?

- How much will that marketing plan cost to execute
   this year, next year, and the year after?

And Guy Kawasaki's favorite question:

- How will you be able to fulfill that marketing plan if you spend
   all your money on infrastructure development and provisioning?

:)

Grab your favorite after-dinner beverage, settle into your comfy chair, 
and enjoy this talk by Guy, esp. Mistake #2:

   Guy Kawasaki: The Top 10 Mistakes of Entrepreneurs
   See Mistake #2: Scaling too soon (@10:57):
   https://www.youtube.com/watch?v=HHjgK6p4nrw


What we all want is one system that will handle anything we throw at it.

But what we truly need is just any system that will handle the customer 
load we have today, with enough unused capacity for near-term growth.

When we run into capacity limits we have the most enviable business 
problem:  too many customers. :)

That problem is self-correcting in software, unlike other forms of 
manufacturing that have a cost of physical goods per unit sold.  We have 
no supply chain, no fabrication, no inventory warehouse.  In software, 
the only raw materials needed are bandwidth and CPU time, both of which 
are far easier to acquire than customers.

Ultimately every system will run into capacity constraints. If you get 
as big as Google, you'll eventually outgrow literally every existing 
system on earth and even need to invent your own file system.  Most of 
us don't get that big.  And on one starts that big.


If you find yourself with that most enviable of business problems, you 
can rest easy because:

- You're not the first person to need scaling.

- At that point you have income to invest in scaling.


Harder than scaling is launching, with marketing a close second.  And 
unless both of those happen, and are done with excellence, any 
investment in scaling won't matter.

So with all that in mind, I would prioritize time-to-market first, 
leaving as much time and money as you can for marketing.

To make the most of development time, use what you know.

It's not necessary to have large-scale capacity at the outset.  You just 
want to make sure you don't make future scaling efforts harder than they 
need to be.

For where you are at the moment, factoring may be more valuable than 
scaling.  Use what you know and enjoy, and just make sure that your 
system is set up with each element as discrete as it can practically be: 
  client, server logic, server storage.  Separation of concerns, as they 
say.

If you set those up with well-defined APIs between them, you can change 
out any one of them without affecting the other two.

Then you can turn your attention to the harder work, the marketing plan. 
  And when that pays off you'll be able to expand system components as 
you need to.

And with any luck, you might even get so big that you'll need to invent 
your own file system too.  I hope you do.  But along the way you'll be 
able to consider scaling horizontally, or vertically, or both, as you 
learn more about usage patterns as the actual needs become evident.

TL;DR: Relax about scaling, go cut some code. :)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com