To horribly slaughter a cliche, the first million is the easiest part. Last month a million unique visitors viewed one of the mobile sites supported by the API I've been gradually expanding. The success is a tremendous validation of its highly-cohesive, low-coupling; something that makes it flexible enough so that we continue to find new places to "plug into" beyond mobile
Streaming out data one HTTP request at a time would be worthless, however, if it was more a molasses drip than a shot of silly string . As demands continue to grow I've begun reassessing my own development processes so that my development infrastructure is best suited to handle the next quarter. Thankfully I'm coming off a May in which I was able to attend a series of high level conferences dealing with just that.
Listening to companies like Netflix and Twilio I noticed a number of approaches repeated. Once can't simply drop all of these in at the onset of a project, however. While some are free to be implemented at any point in the software life cycle, others have dependencies that first need to be established. To illustrate this (because I'm visual like that) I put together the following diagram in Google Docs:
The first thing that I thought after finishing the game-like "tech tree" of useful software infrastructure was:
I don't have time to get everything done in the leftmost "product" part; now I'm supposed to also implement all this other stuff too?
We all know we should be doing that other stuff. It's much the same way we know we're supposed to slow cook our meals and work toward six-pack abs in our copious free time. The benefits are obvious. Its just that the hours to do so are not.
It's something that I'll have to figure out before the next million come a calling.