In The Plex

by Steve Levy

  Sanjay and Dean cooked up a version in a few weeks, then rewrote it, and within a few months completed the first revision of the product. Google policy requires engineers to write in tandem, doing code checks of each other’s work. Not all Google engineers like the process. (One noted Google engineer categorizes programmers as either Code Nazis or artists and dreads projects where he—an artist—is paired with one of the other variety.) But Sanjay and Dean liked the process, having been close colleagues since their time together at DEC Western Research Laboratory.

  MapReduce was a blueprint for a different kind of computing, one that gave Google an edge in the cloud computing era. Add that to Google’s preexisting edges in free fiber and more efficient data centers, and it’s easy to understand how Google can do everything cheaper than its competitors, from providing huge mailboxes for free on Gmail to hosting billions of video views on YouTube, which Google bought in 2006.

  In 2006, Bisciglia came to realize that MapReduce had potential even beyond Google’s ambitious computing plans. He often interviewed college students vying for jobs at Google. The interview would be humming along, with the prodigies from Yale or Stanford posing clever solutions to problems until Bisciglia asked them the question “What would you do with a thousand times as much data?” And they would stare at him blankly. Which was a problem, because, although they didn’t know it, Google was already working on a thousand times more data than anyone suspected. But information on that scale was going to be more common as storage got cheaper, people generated more information, and ubiquitous sensors sucked up even more data that could be mined. Bisciglia realized that MapReduce offered a way to do what was otherwise unthinkable: empower a single programmer to efficiently make use of those humongous, googolesque data sets.

  Ghemawat and Dean published a paper on MapReduce, and other computer scientists used the concepts to produce an open-source version of MapReduce called Apache Hadoop. This program guaranteed that Google’s ideas would spread throughout the world and made it easier to implement cloud computing. Even though competitors would benefit, this wasn’t seen as a negative in Mountain View. If everyone adopted this new computing paradigm, people would always be just a click away from Google’s services—and Google’s ads.

  What was good for the cloud would be good for Google.

  3

  “They’re created by machines. And that is what makes us powerful.”

  In its earlier days, Google had taken pains not to draw the attention of the world’s biggest software company. But everyone knew that eventually the Silicon Valley search kings would wind up in a death cage match with Microsoft. With the development of Google’s cloud computing strategy, it became clear just how that would happen.

  Microsoft’s revenues flowed largely from two cash cows, both of which were monopolies. The first was its Windows operating system, and it was almost unthinkable that anyone could challenge that. In any case, an operating system was far from Google’s mission. The second was Microsoft Office, its applications suite with components including Word, the Excel spreadsheet, and the PowerPoint presentation software. The threat to Microsoft was that Google would apply its Internet-centric approach to attack the older company’s desktop-bound products. And that is exactly what it set out to do.

  The person in charge of Google’s strategy was the person who had first come up with the company’s business plan, and had been later instrumental in AdWords, the product that would make virtually all of Google’s money: Salar Kamangar. With AdWords bringing in several billion dollars a year, Kamangar thought he’d try something different. “I was very excited about what was happening in the applications area, and I saw there was a need for product management that I could bring,” he says.

  Google began to buy small companies producing web-based applications. One of the earlier ones was JotSpot, a creator of collaborative, wiki-style tools. It turned out to be what is called a “talent acquisition,” since the value Google derived from the purchase lay in JotSpot’s founders, Joe Kraus and Graham Spencer. A founder of the early Google competitor Excite, Kraus had developed into a visionary executive with significant start-up skills. Spencer was a brilliant engineer, the tech power behind Kraus’s ideas.

  As far as software was concerned, a more significant purchase was a start-up called Upstartle. It had been cofounded in 2004 by Sam Schillace, a former product manager for Intuit, and two friends. Looking for a good idea for a start-up, they began playing with some emerging Internet technologies, including Ajax, which lets users create web-based programs that behaved like the ones people usually installed on their computers. They found that it was possible to build a simple web-based word-processing program. Such a cloud-based word processor allowed users to work on documents from any computer in the world. Schillace and his partners called their program Writely.

  “We encountered an unbelievable amount of negativism,” says Schillace. Skeptics asked, “What would you do when you weren’t online?” To Schillace and his colleagues, the question was shortsighted. It was like condemning an appliance for using electricity. They believed that as a matter of course cloud computing would eventually become as ubiquitous as the power grid. In the meantime, people could back up their documents and use cheap lightweight client apps to view and edit them.

  Writely had barely shipped when Google bought the company. Schillace understood why Brin and Page’s company wanted it. Applications were moving to the cloud. Google was a cloud company. Google understands, he told himself. Still, he would later note, after the sale the doubters said that Google was crazy for believing that one could do word processing via the cloud. “Eric had a vision before everybody else,” says Schillace.

  After the deal closed in March 2006, the Writely team began migrating its product to the Google code base. The product became part of a project code-named Tricks, a web-based alternative to Microsoft Office. Google had already started developing a web-based spreadsheet that would be a companion to the word processor. The company was also developing a product called Google Gears that would let people keep working on their documents while offline, but the program lacked the bedrock reliability that would be required.

  When Schillace went to Google in 2006, he had to struggle to get resources in the data center. “They had this crazy hand-cobbled system where there was one guy in the middle doing the planning—it was, like, put a bottle of vodka on his desk, and you’d get your machines for the service.” That un-Googley system was replaced by something very Googley—an auction-based allocation.

  Google’s chief economist, Hal Varian, would later explain how it worked when new data centers open: “We’ll build a nice new data center and say, ‘Hey, Google Docs, would you move your machines over here?’ And they say, ‘Sure, next month.’ Because nobody wants to go through the disruption of shifting. So I suggested we run an auction similar to what airlines do when they oversell a plane—they keep offering bigger vouchers until enough customers are willing to give up their seats. In our case, we offer more machines in exchange for moving. One group might do it for fifty new ones, another for a hundred, and another won’t move unless we give them three hundred. So we give them to the lowest bidder—they get their extra capacity, and we get computation shifted to the new data center.”

  Google eventually devised an elaborate auction model for divvying up existing resources. In a paper entitled “Using a Market Economy to Provision Computer Resources Across Planet-wide Clusters,” a group of Google engineers, along with a Stanford professor of management science and engineering, reported a project that essentially made Google’s computational resources into a silicon Wall Street. Supply and demand worked here not to fix stock prices but to place a value on resources. The system not only allowed projects at Google to get fair access to storage and computational cycles but identified shortages in computers, storage, and bandwidth. Instead of the Vickery auction used by AdWords, the system used an “ascending clock auction.” At the beginning, the current pric
e of each resource would be displayed, and Google engineers in competing projects could claim them at that price. The ideal outcome would ensure sufficient resources for everyone, in which case the auction stopped. Otherwise, the automated auctioneer would raise the prices for the next “time slot,” and remaining competitors for those resources had to decide whether to bid higher. And so on, until the engineers not willing to stake their budgets on the most contested resources dropped out. “Hence,” write the paper’s authors, “the auction allows users to ‘discover’ prices in which all users pay/receive payment in proportion to uniform resource prices.”

  To round out its suite of web applications, Google began developing a cloud-based alternative to Microsoft’s PowerPoint. In early 2007, it heard about an innovative start-up that was working on a web-based presentation program that had some even niftier features than the one Google was developing internally. Wayne Crosby and Robby Walker had begun a company called Zenter. Funded by $15,000 from a start-up incubator called Y Combinator, they set out to create their web-based program in four months. They were working out of a small apartment in Mountain View with almost no furniture: their dining room table was a large Styrofoam box that had once held a case of Lean Cuisine meals that Walker’s father had sent them so they wouldn’t starve. Back in his home state of Arizona, Crosby’s wife was about to give birth to their first child. In ten weeks they wrote 40,000 lines of code, creating a program that let users alter their presentations on the fly. And then Google called, eventually buying the company for several million dollars.

  By the time it bought Zenter, Google had already released a beta version of its web-based productivity suite, Google Docs. Google Docs had one huge advantage over Microsoft Office: it was free. Google also began marketing a version to corporations, universities, government agencies, charging $50 a year “per seat” (i.e., for each user) for a license. Adoption was slow but steady. Googlers, however, gobbled it up. It was as though their brains were already in … the cloud. “Ninety-five percent of the company was using it in, like, a month, with no pushing at all,” says Schillace. “It just took the company over.”

  When Schillace began talking to outsiders in 2007, the first reaction he got was “Are you frigging nuts? This will never work.” Some months later, people would say, “Maybe it’s going to work.” By 2010, the qualifiers had been deleted. “Every conversation I have acknowledges that cloud computing is clearly going to happen,” Schillace says, “and the only interesting thing is whether we’re going to win or someone else is.”

  The surest sign that Schillace was right? In 2010, Microsoft rolled out an online version of its Office product—for free. Even if only a small percentage of the marketplace used Google’s own productivity apps, the company had achieved its larger goal—moving work onto the web.

  Google’s next step would put it even more squarely into Microsoft’s sights: it was going to build its own version of the web application that had been at the center of Microsoft’s government antitrust case, a browser.

  The idea long predated Google’s plans for web-based applications. In 2001, Page and Brin had told Schmidt they wanted Google to build its own browser. Right away. Schmidt understood the impulse: browsers were important. They were the vehicles by which people navigated the web, and it made sense for Google to have an alternative to the Microsoft Internet Explorer browser in case Bill Gates and company built in features that would favor Microsoft. But Schmidt originally nixed the plan. “I said, ‘Give me a break,’” he recalls. “‘We don’t have any cash!’” Most of all, he felt that a Google browser would arouse the ire of Microsoft. “I did not believe the company was strong enough to withstand a browser fight,” he says. “I didn’t want to moon the giant.”

  Schmidt brokered a compromise with Sergey and Larry to forestall the inevitable. Google would begin a partnership with the Mozilla Foundation, the nonprofit founded with money from Netscape’s sale to AOL. The foundation’s key product was an open-source browser called Firefox. Google was already the biggest source of revenue for the foundation, paying it millions of dollars to ensure that the search box in Firefox was powered by Google. In the new arrangement, Google hired some top engineers from Mozilla, including Ben Goodger and Darin Fisher. While their employer would be Google, their job would be the same: making improvements in Firefox. Another hiring coup came with Linus Upson, a thirty-seven-year-old engineer with browser experience from Netscape, Steve Jobs’s company NeXT, and Palm, where he created the browser for the PalmPilot. “This was very clever on Larry and Sergey’s part,” says Schmidt, “because, of course, these people doing Firefox extensions are perfectly capable of doing a great browser.”

  The Mozilla refugees worked in what was known at Google as the Product Client Group. This group covered all of Google’s applications that were not web-based but hewed to the more traditional model, where a user installs the program on a computer and thereafter runs it on that machine.

  The first Google client app was the Google Toolbar, an application that let users put the Google search box onto their browsers. John Doerr was a big supporter, urging that Google should aggressively push the product so that the company would not be vulnerable if Microsoft built its own search engine into its Internet Explorer browser. “I was quite nearly panicked that Google was getting to all the world’s people through Microsoft’s browser,” says Doerr. But the product was languishing until a new associate product manager, Wesley Chan, arrived and was assigned to the team. Chan would later develop Google Analytics. Larry Page approached Chan on his first day. “I’m so happy you’re thinking about this,” he said, “because this is a disaster. If we don’t fix it, we’ll cancel the project.”

  Chan realized that users were ignoring the Toolbar because it provided no value to them. His idea was to implement a feature that would allow people to block annoying pop-up windows, which at the time were a plague on the net. But when he presented the idea at a meeting, Brin and Page, who had tied water bottles to the venetian blind cords and were playing a game of water-bottle tetherball, nixed the idea. “That’s the dumbest thing I’ve ever heard!” said Page. “Where did we find you?” Chan built the pop-up blocker anyway, and surreptitiously installed it on Page’s computer. (“He’d leave the computer on in his office,” says Chan.) Not long afterward, Page remarked that his browser was running faster. Chan told him that he’d installed the pop-up blocker.

  “Didn’t I tell you not to do that?” asked Page.

  “Oh, it was a 20 percent project,” said Chan. Page dropped his suspicions and okayed the feature, which helped spur millions of Toolbar downloads.

  In subsequent years, the client group added more products: Google Desktop, which allowed users to use Google technology to search the contents of their own hard drives; the Google Pack, a set of applications from other software companies that Google bundled together and let users download all at once; and a not-yet-released project called GDrive, which would let users store documents in Google’s data centers.

  The head of the Product Client Group was an intense engineer named Sundar Pichai. Born in Madras, India, he was among many Googlers who had attended the Indian Institute of Technology. After graduation, he followed the well-trod path to the United States and earned an M.S. in computer science at Stanford. But Pichai left academia in 1995. “The PhD just seemed like too long a commitment,” he says. “I just wanted to work.” He took various jobs in semiconductors and came to enjoy product management and business management, so he went to business school. He was working at McKinsey & Company in 2003 when one of his younger colleagues announced that he was going to take a job at Google. Pichai tried to talk him out of leaving until he realized that the arguments in favor of joining Google were actually much stronger. Ten months later, Pichai became a Google employee. It was April 1, 2004, and Google was in war room mode because of the Gmail announcement.

  In spring 2006, Pichai’s client group was working in Building 44, across Charleston Street
from the core campus. They were preparing for the Firefox 2.0 launch, but not unexpectedly, there were conversations about designing an ideal browsing app of their own. The team believed that there was a flaw in the current generation of browsers. Microsoft’s Internet Explorer and Mozilla’s Firefox had been conceived in the 1990s, before the cloud computing era. Now the web was expected to become not just a means of delivering information but also a platform for running programs. Those creaky old browsers could not easily adapt to the new reality. The conclusion was obvious: only by building its own browser could Google bring the browser into the cloud age. Even if it didn’t catch on, it might jar the current browsers into radicalizing their own approach, triggering a spiral of innovation not seen since the 1990s browser wars between Microsoft and Netscape.

  The Google engineers began informally discussing what a totally new browser should look like. One key change they had in mind was something called multiprocess architecture. This is the system that helps a computer keep going when an application crashes or freezes. Why not extend that idea to browsers, so if one tab crashes, the other tabs would be unaffected? Starting from scratch had other advantages. The program could be designed to look cleaner and run faster. This fit with the corporate religion of making software with spartan interfaces that run with the speed of Usain Bolt.

  Google had gotten a lot of flak for its impersonal interface style—some thought its programs and search pages so plain as to be ugly. “It’s like they almost want it to be insipid,” says Andy Hertzfeld, a former Macintosh wizard now at Google. Many decisions were made by testing rather than aesthetics—sometimes a minor tweak in spacing or the shade of a color could result in millions of dollars lost or gained in AdWord clicks. Also, Larry Page, wary of anything that would degrade performance, would routinely bounce any interface element with clever frills such as animation. “Artsy” designers seldom lasted long in the company, and one defector left behind a blistering blog post on Google’s visual shortcomings. The fact was, Google didn’t want to be beautiful. Marissa Mayer, the fierce protector of Google’s look, once quelled an incipient revolt by designers by finally defining what rankled her about a stunning design submitted to her. “It looks like a human was involved in choosing what went where,” Marissa told them. “It looks too editorialized. Google products are machine-driven. They’re created by machines. And that is what makes us powerful. That’s what makes our products great.” In other words, the message Google wanted to convey was that its products had no human bias. “It was like this lightbulb went off,” says Margaret Stewart, a key curator of the Google interface. “Marissa said Google products are machine-driven. It was the locked-up principle that had never been expressed, and that was of enormous assistance to us.”