Являясь свидетелями, возможно, последних дней Yahoo как самостоятельного бизнеса, удивительно, что еще десятилетие назад эта компания была достойным соперником Google, одной из крупнейших мировых компаний на сегодняшний день.
Многие факторы повлияли на столь разное нынешнее положение этих двух брендов, но один из них в особенности, а именно: различие в подходе к базовой инфраструктуре (core infrastructure).
Разница в подходах
Google и Yahoo стали развиваться разными путями, когда в условиях растущей интернет-экономики потребовалось быстрое масштабирование бизнеса. Для Yahoo решением стала система хранения NetApp, позволившая компании быстро увеличивать место на сервере. Почти каждый новый сервис Yahoo в конечном итоге работал на базе NetApp, и вскоре компания стала их крупнейшим клиентом.
В это же время Google начал разработку своей собственной файловой системы Google File System. Она задумывалась как платформа, которая подходила бы для всех сервисов компании и стала бы частью их будущей экосистемы. Вместо того, чтобы использовать новейшие системы хранения в качестве основы, Google File System задействовала стандартные серверы для обеспечения гибкой и эластичной архитектуры. Она должна была решить проблемы с расширением и эластичностью раз и навсегда, упростив и ускорив внедрение веб-приложений: от карт до облачного хранилища.
Сложности масштабирования
Прошло 4 года прежде, чем Google File System стал использоваться компанией во всех важных операциях. Между тем, Yahoo за это время удалось заметно продвинуться вперед в гонке за доминирование в интернет-пространстве.
Однако стремительный выход на рынок Yahoo начал давать трещины. Поскольку спрос продолжал расти, недостатки их инфраструктуры вылились в растущие затраты на технические работы, а также на поставщика. Каждый раз добавляя новый сервис, Yahoo был вынужден переконструировать NetApp платформу.
В результате, идентичные проблемы для отдельных сервисов, как, например, Yahoo Search и Yahoo Mail, нуждались в разных решениях, поскольку работали на разных инфраструктурах. Фрагментированная инфраструктура также продемонстрировала несостоятельность ресурса, ввиду того, что каждый сервис требовал отдельного места на сервере и вычислительной мощности.
С другой стороны, файловая система Google позволяла использовать общую архитектуру для всех сервисов. После покупки YouTube, к примеру, Google мог просто сказать: «Уберите ваш back-end, мы будем использовать нашу платформу». Инженеры могли единожды сделать необходимый апгрейд архитектуры, и результат был бы применен ко всем сервисам Google.
И, наконец, гибкая платформа позволила использовать ресурсы разными сервисами, то есть когда один сервер не был занят поиском, он мог использоваться для обработки электронной почты.
Поскольку стоимость и сложность инфраструктуры Yahoo значительно увеличились, компания просто не могла позволить себе больше конкурировать с Google по темпу разработки и освоения новых приложений.
Вместо заключения
Все вышесказанное могло бы стать простой историей о важности создания гибкой архитектуры, но урок, который можно извлечь из нее, выходит далеко за рамки инфраструктуры. Необходимо полностью осознать проблему, прежде чем приниматься за ее решение.
Определив проблему, постройте идеальное решение, игнорируя весь предыдущий опыт. А затем уже подумайте, как вы можете применить данное решение конкретно к вашей ситуации.
Это являлось и является ключевым аспектом успеха многих стартапов. Так, решение Amazon продавать инфраструктуру как услугу разрушило предшествующий успех Comdisco, использовавшего стороннюю инфраструктуру. В качестве еще одного примера можно привести Facebook, создающего целиком свою собственную инфраструктуру — от серверных стоек до камер.
Конечно, иногда при таком подходе приходится жертвовать стремительным ростом. Но стоит помнить, что быстрые решения создают большой риск в виде растущей сложности и неэффективности, как мы могли убедиться уже на примере с Yahoo.
Высоких вам конверсий!
По материалам: techcrunch.comimage source grahamsblog
