Почему Google одержала верх над Yahoo — на примере решения одной проблемы Статьи редакции

Бывший разработчик Google о противостоянии ИТ-гигантов

Бывший разработчик Google Мохит Арон написал для Techcrunch колонку, в которой рассказал о том, как в начале 2000-х два интернет-гиганта сражались за долю на рынке и искали решение для быстро масштабирования бизнеса. По мнению Арона, Yahoo пошла по неверному пути, отказавшись от создания собственной архитектуры, и в итоге попала в тупиковую ситуацию.

«Вероятно, компания Yahoo переживает свои последние дни как самостоятельный бизнес. Хотя десятилетие назад компания наступала на пятки Google — ныне одной из самых дорогих компаний мира», — пишет разработчик.

По словам Мохита Арона, больше десяти лет назад он пришел в Google, чтобы заниматься разработкой файловой системы: «Я начал работать в Google в 2003 году — тогда два интернет-гиганта сражались друг с другом за лидерство на быстрорастущем рынке интернета. Многие факторы повлияли на конечный результат, но один был особенно важен — отличие в подходе к базовой архитектуре».

Google и Yahoo пошли разными путями, когда бизнес требовал быстрого масштабирования, рассказывает Арон. Yahoo нашла решение в готовой системе NetApp — она позволяла быстро добавлять дополнительное пространство на сервере и, таким образом, масштабировать бизнес. В итоге каждый сервис, который запускала Yahoo, работал на базе NetApp и компания стала крупнейшим поставщиком ИТ-гиганта.

В это время в Маунтин-Вью Google начала разработку своей собственной файловой системы — Google File Systems. Она проектировалась как платформа, которая подходит для всех сервисов компании и должна была стать частью экосистемы Google.

Вместо того, чтобы использовать новейшие системы хранения в качестве основы бизнеса, Google File System использовала простые серверы для поддержки гибкой и устойчивой архитектуры. Решение должно было решить вопросы масштабируемости и отказоустойчивости раз и навсегда, упростить и ускорить будущее развертывание веб-приложений: от карт до облачных систем.

— Мохит Арон

Потребовалось четыре года для того, чтобы внедрить файловую систему Google во все важные операции. К этому времени казалось, что Yahoo ушла далеко вперед в масштабировании своих сервисов, пишет разработчик.

Однако вскоре быстрое развитие Yahoo начало давать трещины. Так как спрос продолжал расти, компании приходилось тратить всё больше и больше ресурсов на инженерно-технические работы по поддержанию инфраструктуры. Кроме того, добавление новых сервисов требовало дополнительных затрат на адаптацию NetApp.

В итоге, идентичные проблемы для двух сервисов — например, поиск Yahoo и почтовый сервис Yahoo — требовали разных решений, так как они работали на разной инфраструктуре.

Google же могла использовать общую архитектуру для всех своих сервисов. Например, после покупки Youtube, руководство могло просто сказать «Уберите свой backend и используйте нашу платформу». Инженерам достаточно было обновить архитектуру один раз, чтобы она обновилась для всех сервисов Google.

Еще один плюс общего инфраструктурного решения — разделение ресурсов. Если один сервер не занят поиском он, например, может использоваться для обработки почтовых запросов, рассказывает Арон.

Это простая история о важности создания гибкой архитектуры, но я вынес из нее один урок, которые не относится к технологическим проблемам. Нужно полностью разобраться в проблеме, прежде чем приступать к её решению.

— Мохит Арон

Разработчик рекомендует всегда отталкиваться от идеального варианта решения проблемы, а затем пытаться применить его к текущей ситуации. По мнению Арона, это ключевое отличие множества успешных проектов. Например, Facebook полностью самостоятельно проектирует свою инфраструктуру — от серверных стоек до камер слежения в дата-центре.

0
52 комментария
Написать комментарий...
Сергей Токарев

Вот оно чо, Михалыч. А мужики-то думали, что из-за качества поиска и формулы PageRank...

Ответить
Развернуть ветку
Андрей Захаров

Не исключено, что качество поиска - производная от технологических проблем, а они - производная от финансовых затрат на реализацию, а они - производная от выбранной архитектуры/стратегии развития технических решений.

Я не верю в простое объяснение проблем, которое "у всех на виду". Мой опыт показывает, что истинные причины провала всегда скрыты, а наружу транслируется удобная кому-то точка зрения "кто виноват и что делать".

Ответить
Развернуть ветку
49 комментариев
Раскрывать всегда