Одна из самых забавных вещей в создании Unsplash - это размер, масштаб и популярность продукта.

В среднем в день наш API обрабатывает более 10 миллионов запросов от unsplash.com и тысяч сторонних приложений, наш конвейер данных обрабатывает миллионы событий, наши фиды добавляют 60 миллионов обновления, и мы обслуживаем 60 миллионов изображений.

При этом наша команда относительно небольшая: 2 дизайнера, 3 фронтенда, 3 бэкенда и 1 дата-инженер. Никому не поручают DevOps, и все тратят большую часть своего времени на эксперименты и разработку новых функций для стимулирования роста.

Несмотря на то, что мы многого достигли с помощью Unsplash, мы все еще находимся в самом начале его пути как продукта и бизнеса. Нам еще многое предстоит доказать, а это означает, что нам нужна целая команда, сосредоточенная и решающая проблемы, уникальные для Unsplash, а не те, которые разделяет каждая компания, такие как развертывание, сетевая безопасность, инфраструктура, управление зависимостями и т. Д.

За последние 3 года мы разработали набор принципов, которые позволяют нам сосредоточиться на росте, а не на проблемах масштабирования. К сожалению, для тех из вас, кто ищет волшебную пулю, ее нет: просто здравый смысл и набор принципов, которые мы щедро позаимствовали у других.

1. Создавайте скучные, очевидные решения.

А.К.А. Будьте прагматичны ™

Прежде чем приступить к внедрению нового инструмента, будь то новая база данных (RethinkDB, RocksDB и т. Д.), Новый шаблон («все работает!») Или новая архитектура («микросервисы на помощь!»), Исчерпайте очевидное. варианты в первую очередь.

На бэкэнде очень мало проблем, которые нельзя решить «достаточно хорошо» с помощью стандартных инструментов и нескольких проверенных шаблонов, таких как кэширование, пакетная обработка, асинхронные операции и агрегирование перед запросом.

2. Сосредоточьтесь на решении проблем пользователей, а не на технических проблемах.

Unsplash - это продуктовая компания, а не технологическая компания. Инвесторы дали нам много денег специально для того, чтобы мы могли сосредоточиться на решении продуктовой и рыночной проблемы, а не пытаться добиться 3% -ного снижения эксплуатационных расходов для нашего применения общей технологии.

Вместо этого мы сосредотачиваем свое время на подключении готовых технологий таким образом, чтобы решить проблемы наших пользователей и расширить сообщество Unsplash. Это элементы, уникальные для Unsplash, и если нам удастся создать что-то уникальное и ценное, мы сможем заняться оптимизацией и тяжелой настройкой позже, когда эти 3% оптимизации могут стать основными оставшимися источниками роста.

Это может сбить с толку потенциальных товарищей по команде, так как они услышат о «масштабе» и небольшой команде Unsplash, использовании изображений и искусственного интеллекта, а также будущих функциях только для того, чтобы понять, что мы используем множество готовых технологий, сервисов и фреймворков. , при этом мы платим небольшую премию за то, чтобы передать внутреннюю разработку этих технологий нашим будущим товарищам по команде.

Конвейеры развертывания, конфигурация сервера, системные зависимости, обработка данных, анализ данных, обработка изображений и персонализация (и это лишь некоторые из них) - вот примеры областей, в которые мы решили не инвестировать наши инженерные ресурсы, а вместо этого выбрали сторонние сервисы для обработки. каждый из них.

3. Кидайте деньги на технические проблемы.

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

В команде стало чем-то вроде шутки, что моим первым ответом на любую проблему будет: «Вы пробовали кидаться в нее деньгами?». Но это не шутка, а один из моих любимых подходов к решению проблем.

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

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

Итак, это три довольно простых, но абстрактных принципа, которым мы следуем.

Как это на самом деле выглядит?

Если вы посмотрите на архитектуру Unsplash, то увидите, что у нас очень простая - почти скучная (по крайней мере, по стандартам 2017 года) - настройка.

Мы используем Heroku везде, где можем, чтобы упростить развертывание, настройку, тестирование, обслуживание и масштабирование наших основных приложений. Heroku - это волшебство, поскольку оно абстрагирует части приложения и процесса разработки, с которыми не должен нуждаться член команды, чтобы строить и отправлять эксперимент.

Мы агрессивно минимизируем код, который пишем для логики приложения (фиолетовые области). В логике приложения мы в значительной степени опираемся на фреймворки, созданные другими людьми, которые, будучи экспертами в своих областях, создали набор принципов, которые должны работать в 95% наших сценариев использования.

Мы сильно полагаемся на Redis, ElasticSearch и Postgres для всех производственных нагрузок. В прошлом мы пробовали другие базы данных, но всегда возвращались к этим трем, поскольку уверены в своем понимании того, как эти базы данных работают под нагрузкой.

Мы активно используем рабочие очереди, помещая столько операций в очередь асинхронной обработки, будь то обновление, агрегирование или синхронизация ресурсов.

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

Мы используем ряд сервисов облачного мониторинга, таких как Datadog, New Relic, Sentry и Logentries, вместо того, чтобы пытаться управлять собственными стеками StatsD или ELK или накатывать их.

Мы передаем весь наш хостинг изображений и инфраструктуру Imgix, ведущей в мире компании по динамической обработке изображений. По мере того, как они добавляют ведущие в отрасли функции, наша команда соглашается с одним изменением URL-адреса, предоставляя нашим пользователям новейшие технологии оптимизации и обработки изображений.

Мы переносим все действия наших пользователей в Stream, службу агрегирования каналов, используя их знания о создании и оптимизации высокомасштабируемых персонализированных каналов. Stream упрощает обработку миллиардов действий в простой API для ввода и вывода, с производительностью, на изучение и оптимизацию которой у нашей команды уйдут месяцы, если не годы.

Мы не обучаем собственные алгоритмы распознавания изображений, а вместо этого используем TinEye для обратного поиска изображений и Google Vision для понимания и классификации изображений.

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

В то же время мы инвестируем в те части Unsplash, которые связаны с повышением нашей основной компетенции.

За последний год мы постепенно перевели приложение из одного приложения Rails в Rails API, веб-приложение на базе Node + React и отдельное приложение данных, которое обрабатывает сбор и обработку данных для всех наших внутренних показателей и показателей продукта. .

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

  • На фронтенде наша команда использует React и Webpack с небольшим сервером Express для поддержки рендеринга на стороне сервера и проксирования API. Мы сознательно не привязывали инструменты нашей фронтенд-команды к нашей бэкэнд-команде с помощью временных хаков, таких как react-rails или webpacker. Сообщество Javascript, несомненно, создает лучшие инструменты для внешнего интерфейса, поэтому встроенная работа с Javascript позволяет нашей команде быстрее и быстрее создавать функции более высокого качества.
  • На бэкэнде наша команда продолжает использовать лучший фреймворк для простого веб-приложения: Rails. Экосистема Rails продолжает создавать лучшие интегрированные инструменты для разработки серверных функций, и поскольку Rails является настолько широко используемым фреймворком, все возможные проблемы уже были изучены, задокументированы и решены другими командами.
  • Что касается данных, наша команда использует небольшой сервер Express для сбора и постановки данных в очередь на обработку. Фактической обработкой данных занимается Snowplow, размещенный на наборе образов AWS, что упрощает настройку и настройку. Это позволяет нашему единственному инженеру по обработке данных, Тиму, уделять большую часть своего времени передаче данных в Snowplow и из Snowplow таким образом, чтобы облегчить понимание и понимание остальной части команды.

Мы вкладываем большие средства в написание тестов, измеряем производительность с помощью таких инструментов, как Scientist и Datadog, внедряем изменения с помощью экспериментов и автоматизируем как можно большую часть нашей инфраструктуры.

Мы разрабатываем новый внутренний GraphQL API для ускорения независимых итераций экспериментов, новых функций и новых продуктов, так как мы обнаружили, что наш RESTful API не работает без высокого уровня координации между нашими данными, дизайном и интерфейсом. , и бэкэнд-команды - время, которое лучше потратить на функции, а не на изменения JSON.

Хотя над этими изменениями, очевидно, было весело работать, мы не делаем их, чтобы почесать наш зуд как разработчики, а, скорее, чтобы решить реальные проблемы, мешающие нашей способности быстро выполнять итерации и расти.

Я думаю, что у большинства людей, читающих о том, как построен Unsplash, будет одна из трех реакций:

  1. Unsplash прост, поэтому очевидно, что вы можете воспользоваться этим подходом. То, что я создаю, сложно, поэтому нам нужно делать эти вещи.
  2. Я разработчик. Звучит очень скучно - я хочу создать следующую высокомасштабируемую систему распознавания изображений!
  3. Круто 👍 Мне все равно, просто покажи мне несколько потрясающих бесплатных фотографий, которые я могу использовать.

Для людей, думающих №1, вы правы, очевидно, что есть компании, которые делают гораздо более сложные вещи, чем то, что мы делаем в Unsplash. Но, в конце концов, большинство компаний просто нет. По сути, мы все создаем одни и те же системы, но с немного другой направленностью, поэтому технологии можно абстрагировать до фреймворков и повторно использовать в таком большом количестве проектов, и почему большинство сообщений о найме выглядят чертовски похожими.

Что касается пункта 2, я говорю, что все зависит от того, что вам интересно. Если вы заинтересованы в расширении границ технологий, тогда идите работать в компанию, миссия которой состоит в том, чтобы делать это. Однако их немного, и они очень редки, потому что, в конце концов, большинство компаний просто не делают этого.

А что касается номера №3, я говорю «да», это совершенно верно. В конце концов, это все, о чем мы заботимся!

Если у вас есть какие-либо вопросы или вы хотите глубже погрузиться в это, напишите мне в Twitter @lukechesser. Кроме того, если вы обнаружите, что киваете в ответ и любите получать отличные впечатления, мы нанимаем в Unsplash 👉