Lessons from Google on the economics of SaaS operations
There’s something special about having a boss that proves he can still teach you a thing or two every day.
I spent a beautiful day this week in Monterey for the Tier 1 SaaS evolution summit. During a pannel on infrastructure solutions for SaaS, 3tera’s own Vlad Miloushev reduced the question to simple economics, and based on the number of people that picked up a pen to jot down notes, I wasn’t the only one who hadn’t done the following math.
Vlad noted that based on current estimates, Google operates between 500,000 and 1,000,000 servers.
If we divide the average of those esimates (750,000 for the math impaired) into their Q4 ’06 revenue, we find that Google generated $4274 per server last quarter. Annualized, that’s $17,095 per server each year.
Google is notoriously efficient in their operations. Plus, their application is stateless, while most SaaS applications are not. So, if you’re running a SaaS company you need to consider whether you can realistically generate more revenue per server than Google. For our example, though, let’s assume you do quite a bit better and generate $24,000 in revenue per server each year.
What does this mean for the operations budget? Google spends about 40% on COGs, but the majority of that is traffic acquisition. 10% is related to operations, but that’s unrealistic for most companies. To support R&D, sales and generate a reaonable return, Vlad estimated COGs, including support, needs to be kept below 30%. Allowing 5% for support, that means 25% of revenue can be spent on operations, or $6,000/server each year. That’s $500/server each month.
I couldn’t find a managed service provider that’ll quote $500/server. Because of the labor involved, most start at more than twice that amount. However, doubling the operations budget for a typical SaaS company means raising more captial or starving R&D or sales and marketing, both of which will have long term consequences.
SaaS companies need a more efficient way of hosting their applications and that, of course, is what utility computing is all about.

