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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
