В IT-платформе для синхронизации поставщиков и производителей с маркетплейсами Hubber рассказали Highload о трансформации продукта за пять лет с момента запуска: с какими технологиями работают, какие совершали ошибки и почему постепенно уходят от монолитной архитектуры.
Компания появилась в 2016 году. Тогда наняли первого PHP-разработчика, оформили требования стейкхолдеров в начальное техническое задание и запустили процесс разработки. Через полгода вышел первый релиз.
Основной идеей было создание продукта, который закрывает максимальное число процессов в работе дропшиппера. Начиная от CRM, куда поступают заказы, и заканчивая различными коннекторами, через которые можно передавать товар в любой необходимый канал. Ядро — Product Information Management System (PIM), то есть товарный хаб (отсюда и название). Хотелось сделать все и сразу, как это часто происходит при запуске стартапа, признаются в Hubber.
Вначале была идея написать standalone-приложение под Linux, чтобы все устанавливалось на компьютере клиента. Но все же решили двигаться в сторону Software as a Service (SaaS).
Вот одна из первых блок-схем продукта:
На хостинге хранился код, базы данных — MySQL и MongoDB. Также появилась часть функционала на Node.js (который и обслуживал MongoDB).
Код занимал мало места и легко разворачивался. Обновление на продакшен-окружении происходило еще вручную, dev-среды не было, так как не было и пользователей. Заходили на сервер, вручную писали git pull и получали апдейт.
В Hubber говорят, что две недели перед релизом «жестко овертаймили», чтобы успеть к презентации проекта на конференции ECommerce 2016 в ноябре того же года. В итоге — успели и показали продукт рынку.
Сейчас, оглядываясь на запуск, в Hubber говорят, что ни о чем не жалеют, так как получили незаменимый опыт, но тогда, осенью 2016-го, без багов не обошлось, потому что решили сразу выдать большой объем функционала.
На эту тему в компании рассказывают анекдот:
Заходят тестировщики в бар и заказывают одну кружку пива, две кружки пива, 0,5 кружки пива, ноль кружек пива, ящерицу в стакане. Затем в бар заходит реальный клиент и молча проходит в уборную. Бар вспыхивает, и все погибают.
В компании признают: когда начали появляться первые пользователи, то обнаружились такие баги, о которых раньше и подумать не могли. Первыми клиентами стали около 300 компаний, которым «было нелегко», ведь баги вылезли прямо в корневом функционале. Но клиенты все равно продолжали работать с Hubber, используя рабочую часть функционала для автоматизации своих бизнес-процессов.
Это воодушевило компанию. Она решила масштабироваться, «фиксить баги» и постепенно менять модель, чтобы монетизировать продукт.
Путем проб и ошибок в Hubber поняли, что, работая по модели водопада, далеко не уедешь, и начали внедрять Scrum. На практике оказалось, что двигаясь небольшими итерациями, можно быстрее получать обратную связь от пользователей и исправлять ошибки.
В начале 2017 года возникла идея о необходимости масштабирования. Решили двигаться в сторону социальной бизнес-сети — Facebook для e-commerce. Штат разработчиков в Hubber тогда составлял десять человек.
Менять продукт нужно было очень быстро. Исправляя уже существующий функционал, начали добавлять в продукт новую логику, а также внедрять AngularJS 1.6 на фронтенд. Когда бизнес уже наседает, сложно расставить приоритеты, но компания все же сосредоточилась на экспансии и начала пускать пользователей в систему бесплатно.
Функционал социальной сети включал в себя много составляющих: схема добавления в партнеры, внутренние чаты, уведомления и т.д. К 2021 году от бизнес-моделей и гипотез того времени в продукте из функционала осталась только лента новостей. «Даже сейчас есть некоторые куски кода, которые до сих пор выпиливаем, уже будучи платформенным онлайн-дистрибьютором», — говорят в Hubber.
Хотя функционал бизнес-сети внедрялся впопыхах, приложение явно ожило. Появились компании, которые начали загружать товары в систему, чтобы доверить кому-то их перепродажу.
В середине 2018 года компания познакомилась с Rozetka. Та уже работала как маркетплейс, но у нее еще не было функционала, который бы позволял заводить поставщиков с контентом разных форматов. А у Hubber функционал преобразования контента был. Там взяли товары своих поставщиков и объединили их в один файл импорта для добавления на Rozetka.
После начали уже массово подключать к системе маркетплейсы. В очередной раз бизнес-модель изменилась, а вместе с ней — и код продукта.
Кроме того, появление маркетплейсов подразумевало разработку промежуточной прослойки — «админки», где нужно модерировать контент от поставщиков, чтобы он не сразу появлялся на витринах.
Система начала становиться тяжеловеснее и сложнее. Когда компания постоянно импортирует и экспортирует тысячи, а то и сотни тысяч SKU, это завязывается на модели баз данных. При каждом перетекании товаров происходит копирование данных, база данных растет, что начинает приводить к замедлению работы системы в целом.
Архитектура при этом особо не менялась. «Допиливался» функционал по работе с маркетплейсами, инструменты по стандартизации категорий и опций, различные синхронизации.
Технологии тоже не менялись — в компании еще не видели в этом необходимости.
Когда Hubber начал набирать обороты, компания вышла на Leroy Merlin Vostok и предложила разработать маркетплейс с нуля, используя свои наработки.
Так появилась отдельная компания Scallium, которая занимается разработкой больших e-commerce-систем. Ее историю подробно рассказали здесь. О том, как строятся большие маркетплейсы, ребята из Scallium расскажут в следующих материалах.
Так как многие разработчики ушли делать маркетплейс для Leroy Merlin, в разработке самого Hubber некоторое время не было заметных изменений.
В начале 2019 года, когда уже был готов маркетплейс для Leroy Merlin, часть команды начала разработку Scallium, а остальные вернулись в работу над Hubber.
Начали пересматривать архитектуру и структуру приложения, разбираться с безопасностью и скоростью работы. В тот момент произошли «глобальные изменения»: автоматизация развертывания и управления приложением при помощи Docker, настройка CI/CD через Jenkins, переход на git-flow.
Происходили не структурные изменения, то есть логика приложения не менялась, подчеркивают в Hubber. Менялась конфигурация и работа всей экосистемы в целом. Но этого было недостаточно — приложению требовались кардинальные изменения.
Hubber решили пересобрать с чистого листа. Для этого разработали новую схему архитектуры. Вот она:
Целью снова было масштабирование продукта, а задачей — перейти на микросервисную архитектуру с хорошим деплоем, предсказуемостью и отказоустойчивостью.
Строить решили при помощи Kubernetes на фреймворке Symfony. Фронтенд должен стать независимым приложением, которое общается с API Gateway через язык запросов GraphQL, что должно было позволить строить гибкую коммуникацию через API как внутри экосистемы, так и за ее пределами.
Собрали команду и начали разработку. Вот только пользователи этот проект так и не увидели.
Одной из проблем стал тот самый протокол GraphQL, который должен был стать связующим звеном между внутренними элементами системы (коммуникация между сервисами тоже подразумевала работу через GraphQL) и внешним миром. В то время не было ни готовых решений на PHP в том формате, которого требовала архитектура, ни «набитых шишек» у разработчиков, признают в Hubber. То есть большая часть времени, по сути, ушла не на разработку продукта, а на разработку самих технологий, на которых этот продукт будет разрабатываться.
В Hubber поняли, что в таком темпе, с имеющимися библиотеками и ресурсами просто не смогут осилить то, что запланировали. Разработку отложили до лучших времен. Решили, что Hubber должен набрать больше оборотов как бизнес, чтобы компания вернулась к Hubber 2.0.
Пока же внимание снова направили на текущий продукт, которым к тому времени уже пользовалось более 800 компаний.
В Hubber утверждают, что за последние два года закрыли все критические баги, стабилизировали платформу, полностью переделали биллинг и увеличили количество активных компаний, которые пользуются продуктом.
Стабилизация позволила подключить более крупных клиентов вроде ERC, Lamoda или «Эпицентра». Сейчас с проектом, по собственным данным, работают больше 1200 бизнесов, включая также Kasta, OLX, Prom.ua, «Боржоми». Растет объем данных и транзакций, число товаров и генераций файлов импорта/экспорта.
В среднем, по данным компании, один маркетплейс забирает с Hubber 182 000 SKU. Каждые два часа происходит обновление всех товарных фидов (каждой карточки товара), которые магазины загрузили на свои витрины. Это миллионы операций на серверах.
В компании уверены, что нужно двигаться к микросервисной архитектуре, чтобы продолжать рост. Уходить от монолитного кода в Hubber хотят потому, что «монолит» сложно масштабировать. Разделение на микросервисы же должно позволить точечно балансировать нагрузку и масштабировать отдельные компоненты системы.
«Когда количество пользователей и товаров на платформе вырастет до тех значений, когда сервер не сможет вынести нагрузку, мы придем к тому, что не можем развивать бизнес. Мы не сможем привлекать новых клиентов, потому что система не сможет обработать их фиды», — говорят в Hubber.
К микросервисам в компании пошли обходным путем. До недавнего времени весь код внутри «монолита» был очень тесно связан между собой. Сейчас разработчики проводят рефакторинг и разделяют ключевой функционал приложения на отдельные независимые модули внутри монолита. Новый функционал сразу выносят в модули.
Это пока что не микросервисы. Но из-за того, что модули отвязаны друг от друга, по идее, уже не должно составить большого труда разнести их на независимые сервисы и построить микросервисную архитектуру уже в ближайшем будущем.
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…
