OK. Everybody, repeat after me: The Rules of Google Do Not Apply To Me.

(Yes, yes, unless of course you happen to, you know, work for Google.)

I refer to this mistake as The Google Fallacy – namely, that the ins and outs of what makes Google tick can be generalized to every web site if not the Internet as a whole. The problem with this assertion is that Google’s challenges are unique to Google. Unless you to have a few million servers to administer and $4.2B/quarter of revenue coming over your web site with a 45% year-over-year growth, extrapolating their issues to you just doesn’t work.

Reason #1: You don’t have millions of servers for your web site.

Managing web servers is not unlike going up a hill. Having a few servers is like having a baseball mound as your hill. From any vantage point, you can see the entire hill on all sides. A single person knows where all the dirt is and what needs to be done to make it play worthy.

As your server count goes up, the hill goes with it. A couple of hundred of servers is that tall hill that you’d rather drive up, but walking it is entirely doable. Managing this tall hill needs a few people dedicated to the task in order to keep tabs on where everything is and investing a bit into automation (e.g., lawn mowers) is a worthwhile endeavor.

But when you get to millions of servers, you’re going up a sheer cliff. The problems and resulting tools are entirely different. Extrapolating a few servers to a million servers doesn’t work in either direction for the same reason gardening tools suitable for a baseball mound don’t work well for hanging off a cliff.

Reason #2: You don’t have a small army of bright software engineers

No doubt, your team is smart. The difference is, you pay your engineers in Costco food and stock worth the paper it is printed on. Google pays their software engineers with real money, stock that’s worth something, and food made by professional chefs. This means that you have to doll out serious stock to smart guys willing to make a bet on your idea and stock is a finite resource which means you aren’t going to have a very large team.

Google advocates that homegrown software running on commodity platforms can scale vastly better than commercial alternatives. For Google, this is (largely) true. The problems that they face are so unique that infrastructure vendors would have to dedicate non-trivial engineering resources to satisfy the needs of a single customer. Even with Google’s scale and buying power, such an investment almost never works out well for the vendor. Thus, Google often finds that vendor based solutions either don’t scale or solve a problem unique to them. This because that scaling up means building it yourself.

So when Google says that the right way to do something is to write your own software, keep in mind that they have a small army of engineers that they can dedicate to such problems. This investment is worth it to them because if one hundred senior software engineers (loaded cost: $20M/yr) can improve efficiency by 0.1%, those engineers have paid for themselves. When you improve your software efficiency by 0.1%, you have moved your bottom line by exactly $0. As a result, commodity solutions (e.g., stock LAMP as opposed to custom kernels) are probably a better choice for you.

Reason #3:  You aren’t building your product for Google alone

This is really directly at vendors that cite Google as an example customer. The problem with Google as an example customer is that they are so entirely unique, that if you built something to their spec, you won’t be building something useful to everyone else.

As a result of this unique situation, it simply isn’t a good idea to look to how Google solved their challenges unless you happen to also have insight into what made Google take that direction in the first place. (Hint: They rarely if ever share details of their decision-making progress.) Doing so provides misleading information that when scaled down, don’t work out nearly as well. If anything, it could backfire and work against you.