« FiltrBox – can be huge | Main | Stacking the Shuttle »



Feed You can follow this conversation by subscribing to the comment feed for this post.

You Mon Tsang

Great post Todd. Love your thoughts on what is probably the next step of running a service: where the actual costs are. As our service grows, we’ve been focused on the actual cost of providing the service. We’re looking at power use, CPU, storage space, hardware costs. We look at each of our configuration and estimated how much we spend per marginal page served.

Todd Vernon

@You Mon: Maybe I’ll take this up in a future post. I will say however that most web service based business have 90% gross margin or better so this stuff is kind of in the noise. That’s what great about these kinds of businesses... Depending on the business however, storage can certainly get expensive.

Tom Chikoore

Great advice for startups, Todd. These are some of the technology aspects that are often overlooked until something breaks. I love how you have touched on the most important points and condensed them into one post.

Todd Vernon

@Tom: Thanks, most stuff out there is less prescriptive and quickly gets down into nuts and bolts of specific technologies. This post was designed to simply be a checklist of stuff that make a big difference in the early days.


Interesting points.

You mention decoupling the database and using flat files - what mechanism should be used to lock and share those flat files? Since there are multiple web servers you\’ll need some way to lock/share them right? NFS and flock? That just sounds like migrating your problems from the database into a new area. Or are you referring to caching out the ultimate html page and not just the data behind it? In which case sure, that works fine...for anonymous users

Todd Vernon

@greggles: Don’t get me wrong, you can get really exotic here but that’s not what I’m suggesting.. A lot of services have stats pages, or profile pages, or report type pages that can be very query intensive. Im suggesting that a lot of these don’t change that much from day to day.. Build a task that writes flat files periodically. Then when the page get served, just serve the flat file..No locks required.. In the past I have done a lot of projects where a lot was happening in real-time. As these actions happened we wanted to record (or log) that the actions had happened.. Rather than putting database calls right in the middle of a pseudo real-time process we just wrote those actions to queues that another process would log as time permitted. That way a database slowdown would not affect a real-time process (web conferencing). The major theme is don’t think of the database as your bitch. Its very expensive to interact with it (even if it’s not when you first build the product). Always ask yourself if we ‘have’ to interact with it now, or can I ‘easily’ move that out of the flow of app. my $.02

Thomas Jordan

Right on... do it right the first time, or fail. So what’s the opposite of a green bean?

Todd Vernon

@Thomas Jordan: Hmm, I don’t know.. I have to think about that. I got the term from Jim Lejeal one of my co-founders at Raindance. I will consult him.


green bean--very funny but so right on. Great post and comments. As for opposite, I think you just want to be something other than a green bean, not necessarily the opposite. There are many ways to be without being a bean. Don’t be the bean.


I’ve found that a great way to scale initially for service based startups is AWS (aws.amazon.com) and RightScale. AWS is pay for what you use and RightScale is $500/mnth. That is pretty cheap while you figure out if your idea has traction. If you are able to prove your business, then bringing some of the RightScale tools in house probably makes sense considering the community around AWS. Note that AWS for all processing, storage, queuing capabilities, etc. probably doesn’t scale longterm (in some cases it might) but again it is a great way to prove your idea and offload scalability concerns upfront.

The comments to this entry are closed.

Lijit Ad Network