Even Larry Page (Google co-founder) did everything he could to extend Google’s runway…
I’ve been thinking (and blogging) a lot lately about the importance of extending the runway for startups. Giving a startup enough time to be successful is one of the keys to success. You can do that through funding, or building recurring revenue that allows the company to continue on, or apparently by saving money on gas or slimming down server hardware. Check out these two stories from a story on Larry Page (Google co-founder) in Slate:
In 1999, for instance, the method by which large Web companies such as eBay, Yahoo, and Google added server space had become fairly routine. They purchased servers and installed them in cages at giant warehouses owned by third-party vendors. The warehouse companies would pay for the power that kept the servers running and the air conditioning that kept them cool, and the website owners would pay for space by the square foot. Page figured if Google was going to pay per square foot, he was going to stuff as many servers into that space as he could. He took apart servers and began hunting for ways to shrink them. The first thing to go? All the off switches.
“Why would you ever want to turn a server off?” he reportedly asked.
Stripped of useless components and fitted with corkboard to keep wires from crossing, Google developed new super-slim servers. They looked ugly. But before long, Google would end up paying the same price to host 1,500 servers as early rival Inktomi paid to host 50. As a result, Google’s search ran a lot faster, and Inktomi, along with many of Google’s other search rivals, was left in the dust.
AND
In 1998, Page and Brin decided to take all eight of Google’s employees on a company ski trip to Lake Tahoe. When they went to rent a van, they discovered they could save $2.50 per day if they designated a single driver. Page designated himself. He drove the whole way while everyone else played math games in the back.
The other thing they removed is all the stuff that makes machines reliable. The basic way of thinking was, it was better to have a lot of unreliable servers that you could build cheaply and stuff in racks, and design the software to deal with unreliable hardware. Turned out to be a winning move.
Interesting perspective, thanks for sharing. I’d love your thoughts on Google, Amazon and Dropbox in that space.
It is an interesting space isn’t it? I think the telling sign will be when the various vendors in cloud space have a lot of uptake. The real challenge is in scaling. Also, look to see the first one to have a massive data loss incident, and/or service outages related to the stateful data for a service being unavailable.
It really comes down to a few things:
– how much computing power can you provide
– how cheaply efficiently can you run that computing power
– how efficiently can you allocate resources to clients (tetrising jobs)
– how effectively do you keep stateful data multi-homed
– how seamlessly can work around entire data center outages
– how effective do you get services close to clients in terms of network distance.
Now that I look at it, that is more than a few things, but at a high level I think those are the things that are going to shape cloud computing.
I will say this, these are really really hard problems. There aren’t a lot of people in the world who can build this sort of infrastructure. In the end, it is going to come down to who ends up with the most human capital in this problem space.
Terrific points on the future of cloud computing, Matt. Thanks!