Почему 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...

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

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

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

Ответить
Развернуть ветку
Valentin Dombrovsky

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

Как мило читать это про Яху, которая была крупнейшей интернет-компанией ещё до появления Гугл. "Наступает на пятки" догоняющий, а тот, кого обогнали, он просто постепенно отстаёт.

Ответить
Развернуть ветку
Valentin Dombrovsky

Впрочем, вижу, что вновь издержки перевода. В оригинале "was running neck-and-neck" - "шла ноздря в ноздрю". Так правильней.

Ответить
Развернуть ветку
Serge Arsentiev

Крупность-то оказалась временной - набор клиентской базы в Интернет так же прост (помните, зазывное интернетовское - представьте что у Вашего товара или услуги миллионы клиентов!"), как и потеря клиентов - легко перебегающих к кому угодно.

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

А теперь представим что владелец самостоятельно, нажатием кнопки
меняет свой автомобиль также легко как интернет поиск, браузер или почту - в понедельник превращает свой VW в KIA, а через неделю, поддавшись рекламе, в Great Wall, ужаснувшись, на недельку делает машину Toyota'ой, а подумав немного, через месяц - в Ford.

При этом все указанные бренды добавляют его к статистике продаж за год, и продолжают считать своим клиентом.

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

Кстати, высказываемые в статье тезисы напрямую противоречат столь часто популяризируемым в последнее время идеям "делай как проще", "делай как быстрее", "используй готовые решения"

Оказывается, когда на кону серьезные деньги, то технология (своя) предрешают успех. Спешка нужная только для пузырей/ловли блох ;-)

Ответить
Развернуть ветку
Praetorian

Противоречат каким идеям? Когда Google был на уровне стартапа, он так и делал- проще и легче, когда вырос начал выстраивать свою архитектуру.

Ответить
Развернуть ветку
5 комментариев
Serge Arsentiev

А на чем они до этого (и во время 4-х летней разработки) держали все сервисы?

Ответить
Развернуть ветку
5 комментариев
Konstantin

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

Ответить
Развернуть ветку
1 комментарий
Anthony Marchenko

Не понятно почему только Yahoo не купил просто NetApp и заточил бы под себя

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Serge Arsentiev

Я не понял, что такое Google File System (дисковая система или платформа, если последнее, то что именно она включает?), и можно ли купить на нее лицензию и делать кластер серверов для своей системы - ну хотя бы виртуального хостинга, например.

Или она закрытая разработка Google?

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

Нет, это распределенная файловая система.

Насколько я знаю, это закрытая разработка. Есть системы аналогичного назначения, но с другими характеристиками.

Ответить
Развернуть ветку
2 комментария
Валентин

Есть прекрасная фс ceph,она открыта и её очень удобно использовать и масштабировать.

Ответить
Развернуть ветку
21 комментарий
Konstantin Smirnov

Как использование GFS позволяет взять и - р-раз - выкинуть инородный бэкенд?

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

Если бакэнд занимался хранением/индексацией данных, то почему бы и нет ?

Ответить
Развернуть ветку
Konstantin

Целиком - очевидно, никак. Подменить систему хранения и извлечения данных, заодно пришив свой поиск - можно.

Ответить
Развернуть ветку
Praetorian

1) Перенаправить хранилище в GFS в фоновом режиме или 2) постепенно по мере копирования каждого старого сервера переформатировать его в GFS и использовать для копирования

Ответить
Развернуть ветку
Serge Arsentiev

Как любят говорить всякие ученые, если взять только начало и конец рассуждения - то получается или бред или колдовство.
А чтобы провести человека полным путем, надо очень долго учиться ... а учить они, походу не хотят, если откровения о компонентах системы из 2005 года, доходят до нас в 2016.

Кто там говорил про комм. тайну? Типичный случай истечения подписки о неразглашении, после которой, однако тоже не рекомендуется разглашать :) А он разгласил ... видимо потому что повторение этого уже не имеет смысла - они ушли далеко вперед в _технологической обработке огромных объемов информации_, но, к сожалению, не в ее интеллектуальном анализе ..

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Читать все 52 комментария
null