Почему мы отказались от части готовых технологий при разработке LO — и не собираемся отказываться от open source
Меня зовут Никита Чиров, я основатель LO (LiveOnce).
Сегодня на нашей платформе зарегистрировано более 110 тысяч пользователей. В LO развиваются чаты, звонки, сообщества, Flows, музыка, места и события. Мы также работаем над картографическим направлением и планируем развивать экосистему мини-приложений.
Но за этими функциями стоит восемь лет работы над технологической инфраструктурой. И за это время мы усвоили один важный урок:
Собственная технология имеет смысл только тогда, когда она даёт продукту преимущество.
Можно потратить годы на создание собственной базы данных, системы оркестрации или сервера сообщений. Но если пользователь не получит от этого ничего нового, возникает вопрос: зачем?
Как мы начинали: готовые решения вместо разработки всего с нуля
На старте LO мы не пытались построить всю инфраструктуру самостоятельно.
Для небольшой команды это было бы неоправданно дорого и долго.
Нам нужно было запускать функции, проверять идеи и постепенно развивать платформу. Поэтому мы использовали доступные технологии, которые позволяли решать задачи без многолетней разработки собственной инфраструктуры.
Такой подход дал нам возможность сосредоточиться на самом продукте.
Вместо того чтобы создавать ещё одну базу данных или универсальную систему коммуникаций, мы могли заниматься тем, что действительно отличает LO от других приложений.
И сегодня я считаю этот подход правильным.
Более того, если бы мы начинали разработку сейчас, то, вероятно, использовали бы ещё больше готовых инструментов.
Современный open source позволяет небольшим командам создавать сложные продукты с инфраструктурой, на которую раньше потребовались бы десятки инженеров.
Однако со временем у готовых решений обнаруживается одна особенность.
Они создаются для большого количества компаний и не обязаны идеально соответствовать требованиям конкретного продукта.
Когда готовая технология начинает ограничивать продукт
Представим, что вы используете стороннюю технологию, которая решает 90% необходимых задач.
Оставшиеся 10% можно компенсировать дополнительными компонентами, настройками или изменениями архитектуры.
На раннем этапе это разумно.
Но продукт растёт.
Появляются новые функции, меняются требования к производительности, возникают дополнительные сценарии использования.
И постепенно команда начинает тратить всё больше времени не на разработку оптимального решения, а на обход ограничений существующей технологии.
В какой-то момент возникает выбор: продолжать приспосабливать продукт к инфраструктуре или изменить саму инфраструктуру.
Для нас такой момент наступил в области real-time-коммуникаций.
Почему LO начал переходить на собственную real-time-инфраструктуру
В течение длительного времени мы использовали готовые технологии, включая Centrifugo, а для отдельных коммуникационных задач — mediasoup.
Эти решения позволили нам быстрее развивать платформу и не тратить ресурсы на создание всей коммуникационной инфраструктуры с нуля.
Но постепенно роль real-time-компонентов внутри LO изменилась.
Первоначально они обеспечивали отдельные функции. Со временем коммуникации стали одним из фундаментальных элементов платформы.
Чаты, звонки, статусы пользователей, события и синхронизация между устройствами предъявляют собственные требования к работе системы.
При этом мы развиваем не отдельный мессенджер, а платформу, в которой взаимодействуют разные сервисы.
Поэтому мы приняли решение постепенно переходить от прежнего стека к собственной real-time-системе.
Важно понимать: мы не отказались от готовых решений потому, что они были плохими.
Они выполнили свою задачу на определённом этапе развития LO.
Но требования продукта изменились.
И нам потребовался больший контроль над одним из его ключевых технологических компонентов.
ConnectX: зачем социальной платформе собственный протокол
Одним из результатов этой работы стало создание ConnectX — собственного протокола LO.
На первый взгляд разработка отдельного протокола может показаться избыточной задачей.
Особенно для платформы, которая пока не насчитывает миллионы пользователей.
Но для нас важен не сам факт наличия собственной технологии, а возможность управлять поведением коммуникационного слоя.
В частности, нас интересовали установление соединений, восстановление после разрывов, работа в нестабильных сетях и дальнейшее развитие взаимодействия приложения с инфраструктурой.
В одном из обновлений оптимизация ConnectX позволила примерно на 20% ускорить установление соединения.
Для пользователя это означает более быстрый отклик приложения.
При этом человеку совершенно необязательно знать, какой именно протокол используется внутри.
Пользователь открывает LO, отправляет сообщение или начинает звонок. Его интересует результат, а не название инфраструктурного компонента.
Именно так, на мой взгляд, должны работать хорошие внутренние технологии.
Они не требуют внимания пользователя, но напрямую влияют на качество его опыта.
Почему мы продолжаем использовать PostgreSQL и Kubernetes
После истории с ConnectX может возникнуть логичный вопрос: если мы разрабатываем собственные технологии, почему бы постепенно не заменить ими весь сторонний стек?
Потому что в этом нет смысла.
В LO используются PostgreSQL, Kubernetes и множество других open-source-решений.
И мы не планируем создавать собственные аналоги только ради технологической независимости.
Например, разработка собственной базы данных потребовала бы значительных инженерных ресурсов.
Причём написать первую рабочую версию — лишь небольшая часть задачи.
Дальше потребуются тестирование, безопасность, поддержка, оптимизация, совместимость и постоянное исправление ошибок.
У зрелых open-source-проектов над этими задачами работают большие сообщества разработчиков и компаний.
Отказываться от результатов их работы без конкретного преимущества для продукта было бы нерационально.
Поэтому наш подход заключается не в максимальном количестве собственных технологий.
Мы разрабатываем свои решения там, где контроль над ними действительно влияет на развитие LO.
Во всех остальных случаях качественный open source может быть более эффективным выбором.
Главная опасность — не чужой код, а зависимость от чужих решений
На мой взгляд, многие компании неправильно понимают технологическую независимость.
Они считают, что для её достижения необходимо отказаться от максимального количества внешних технологий.
Но сама по себе сторонняя разработка не обязательно создаёт зависимость.
Например, если компания использует открытое программное обеспечение, она может изучать его исходный код, модифицировать, поддерживать необходимую версию или заменить другим решением.
Совсем другая ситуация возникает, когда критическая функция продукта полностью зависит от закрытого внешнего сервиса.
Поставщик может изменить тарифы, ограничить API, прекратить поддержку определённой функции или поменять условия использования.
И тогда возможности вашего продукта начинают определяться решениями другой компании.
Для нас это принципиальная разница.
Мы не стремимся отказаться от всего чужого кода.
Мы стремимся не оказаться в ситуации, когда дальнейшее развитие LO невозможно без согласия или участия конкретного поставщика.
Почему архитектура важнее выбора конкретной технологии
За восемь лет разработки LO мы неоднократно пересматривали технические решения.
Некоторые технологии, которые отлично подходили нам несколько лет назад, сегодня уже не полностью отвечают требованиям платформы.
Но это не означает, что их первоначальный выбор был ошибкой.
В своё время они позволили быстрее запустить функции и развивать продукт.
Проблема возникает тогда, когда архитектура построена так, что заменить технологию практически невозможно.
Именно поэтому при проектировании инфраструктуры мы стараемся учитывать не только текущую эффективность решения, но и возможность отказаться от него в будущем.
Через несколько лет могут измениться требования пользователей, появиться новые технологии или существенно увеличиться масштаб платформы.
Архитектура должна допускать такие изменения.
Для нас технологическая гибкость — это не менее важное преимущество, чем производительность отдельных компонентов.
Зачем инвестировать в инфраструктуру, если у LO пока 110 тысяч пользователей?
Этот вопрос вполне справедлив.
Сегодня на LO зарегистрировано более 110 тысяч пользователей.
По сравнению с крупнейшими социальными платформами это небольшая аудитория.
Можно было бы направить больше ресурсов на маркетинг, а развитие инфраструктуры отложить.
Возможно, в таком случае количество пользователей уже сейчас было бы выше.
Но существовал бы и другой риск: привлечь большую аудиторию на технологическую основу, которую впоследствии всё равно пришлось бы серьёзно перестраивать.
Большую часть восьмилетней истории LO мы инвестировали прежде всего в развитие продукта и его технологий.
Для нас было важно создать платформу, которую можно последовательно развивать в течение многих лет.
Теперь мы подходим к следующему этапу.
Если раньше главной задачей было доказать, что мы способны построить такую технологическую систему, то теперь необходимо показать, что её можно масштабировать.
И более 110 тысяч пользователей — далеко не тот результат, на котором мы собираемся остановиться.
Следующий этап LO — платформа для сторонних разработчиков
Сегодня LO объединяет несколько направлений: коммуникации, Flows, сообщества, музыку, места и события.
Мы работаем над картографическими возможностями.
Одним из следующих крупных этапов должны стать мини-приложения и инструменты для сторонних разработчиков.
Это меняет требования к инфраструктуре.
Когда компания создаёт одно приложение, её технические системы обслуживают собственный продукт.
Но когда сторонние разработчики начинают создавать сервисы поверх этой инфраструктуры, она сама становится частью продукта.
В такой ситуации особенно важно иметь возможность самостоятельно определять развитие критических технологий.
Именно поэтому мы уделяем столько внимания собственной технологической базе.
Не для того, чтобы заявить, что всё внутри LO написано нашей командой.
А для того, чтобы развитие платформы определялось потребностями её пользователей и разработчиков.
Какие выводы мы сделали за восемь лет
Сегодня я бы сформулировал наш подход следующим образом.
Если готовая открытая технология полностью решает задачу — используем её.
Если существующее решение можно адаптировать под наши требования — рассматриваем такую возможность.
Если технология становится критической для продукта и начинает ограничивать его развитие — можем разработать собственную.
При этом важно сохранять архитектурную гибкость и возможность менять решения по мере развития платформы.
Я не считаю, что технологически зрелая компания должна стремиться к максимальному количеству собственного кода.
Скорее наоборот.
Зрелость проявляется в способности понимать, какие технологии действительно необходимо контролировать, а где эффективнее использовать уже существующие разработки.
Сегодня LO не зависит технически от одного внешнего решения, без которого дальнейшее развитие платформы остановилось бы.
Для меня это и есть технологическая независимость.
Не стремление написать всё самостоятельно, а возможность самостоятельно принимать решения о будущем своего продукта.
Open source позволяет нам использовать лучшие существующие разработки.
Собственные технологии дают контроль там, где он действительно необходим.
А правильно построенная архитектура позволяет выбирать между ними.