Google Does Not Mock Bing

The Register posted an article titled ‘Google Mocks Bing‘ based on a panel I was on at GigaOm’s Structure 09 conference. Normally I wouldn’t bother refuting anything published by The Register, but I felt this particular article deserved a little clarification.

I wasn’t mocking Bing when I said “Bing for it, you can find it.” I meant that seriously, in the spirit of giving props to a competitor, and a good one at that. Najam and I have been friends since before Google had a business plan, and I have the greatest respect for him and for Microsoft as a company. The Microsoft approach has some good points, which work for their business plan. I was speaking of one particular approach, among several others, which can solve the same problem. There was no undercutting anything, there are two approaches and thats that.

Taking some time to analyze these approaches, one is an “ops heavy” plan, which is more flexible, faster at deployment, and there is the “ops light” plan, which is initially slower, more difficult to work with, and has much faster optimization once it is up and running.

The ops heavy approach relies on customized solutions for each product. You have several products, each with their own hardware, software stack, storage, load balancing etc. The ops light approach relies on software primitives which abstract away (within reason), the underlying fabric and connectivity. The ops heavy approach obviously can be more flexible in time to market, fit to requirements and expenditure. The ops light plan requires more upfront work, and is locally not optimal in almost every case, but – and here is the key – on a global basis, I believe is almost always the correct approach. You can roll out a small fix and that is immediately amortized over the entire body of products that rely on the primitives supplied. I used the example of GFS. There are many others. The OPEX for maintaining the infrastructure is spread out over the entire base product, there are no silos which almost guarantee inefficiencies. However, this is not the only approach and depending on how the organization structure is laid out, the ops heavy approach may very well be the correct approach. The downside of the ops light approach is long time to get up to speed for infrastructure, constrained programming environment, inefficient exposure of the underlying fabric (almost by definition if you are working with an abstraction, you will lose significant amounts of information that could be used to optimize the end result), and a slower, less flexible support structure – which is better at doing things at vast scale and cannot deal well with one-offs.