Почему технологическая независимость не означает «писать всё самим»

За восемь лет разработки LO у нас появилось много собственных технологий — от ConnectX до real-time-инфраструктуры. При этом мы продолжаем использовать PostgreSQL, Kubernetes и другие open-source-решения. Рассказываю, почему для нас технологическая независимость — это не отказ от чужого кода, а возможность самостоятельно определять развитие продукта.

Меня зовут Никита Чиров, я основатель LO (LiveOnce).

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

Со временем у нас сформировался довольно простой принцип: технологическая независимость не означает, что компания должна написать всё самостоятельно.

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

В open source есть огромное количество отличных технологий. Нет никакого смысла создавать собственную базу данных только для того, чтобы назвать ее собственной.

Но есть принципиальная разница между использованием сторонней технологии и зависимостью от нее.

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

И для нас это значительно важнее количества строк собственного кода.

Когда мы начинали LO восемь лет назад, наша задача была довольно очевидной: создать продукт.

У небольшой команды нет смысла тратить несколько лет на разработку всей инфраструктуры с нуля.

Если существует хорошая база данных — используй ее.

Если есть готовая технология для realtime — используй ее.

Если open-source-проект закрывает задачу — нет необходимости создавать собственный аналог просто ради принципа.

На ранних этапах LO мы именно так и поступали.

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

И если бы мы начинали LO сегодня, я бы поступил точно так же.

Возможно, даже активнее.

За последние годы качество и количество доступных open-source-технологий выросло настолько, что небольшая команда сегодня может построить инфраструктуру, для которой раньше потребовались бы десятки инженеров.

Проблема начинается в другом месте.

Представим, что одна из критических функций вашего продукта работает через сторонний сервис.

Вы не контролируете его код и инфраструктуру. Вы не определяете его технические ограничения. Не можете самостоятельно изменить API.

Сегодня сервис работает прекрасно.

Завтра поставщик меняет условия.

Послезавтра увеличивает стоимость.

Потом закрывает необходимую функцию.

И внезапно оказывается, что решение другой компании напрямую определяет возможности вашего продукта.

Для меня это и есть технологическая зависимость.

С open source ситуация часто совершенно другая.

Код доступен. Его можно изучать и модифицировать. Можно сделать fork. Можно поддерживать необходимую версию самостоятельно. В конце концов, технологию можно заменить.

Поэтому сам факт использования чужого кода ничего не говорит о технологической независимости компании.

LO использует PostgreSQL.

Использует Kubernetes.

Использует множество других открытых технологий.

Мы не собираемся писать собственный PostgreSQL.

И не планируем создавать LO Kubernetes.

Потому что это не даст пользователю LO практически ничего.

Независимость от чужого кода и независимость от чужих решений — совершенно разные вещи.

Нас интересует второе.

Есть другая сторона вопроса.

Даже очень хорошая технология не обязана подходить вашему продукту всегда.

Большинство популярных решений создаются универсальными. Их задача — удовлетворить требования тысяч разных компаний.

И это прекрасно работает.

До определенного момента.

Допустим, готовая технология закрывает 90% ваших требований.

Оставшиеся 10% можно обойти.

Вы немного адаптируете архитектуру.

Добавляете дополнительный слой.

Делаете workaround.

На раннем этапе это почти всегда выгоднее собственной разработки.

Но продукт развивается.

Появляются новые сценарии.

И те самые 10% постепенно превращаются в 20%.

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

Для меня это важный сигнал.

Технология должна адаптироваться к продукту, а не продукт к технологии.

Хороший пример из истории LO — real-time-инфраструктура.

Долгое время мы использовали готовые решения, включая Centrifugo, а для части коммуникационных задач — mediasoup.

Это хорошие технологии.

И их использование на определенном этапе было абсолютно правильным решением.

Они позволили нам не тратить годы на создание собственной инфраструктуры и быстрее развивать сам LO.

Но постепенно realtime перестал быть для нас просто одним из компонентов.

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

Требования LO изменились.

Мы могли продолжать адаптировать архитектуру под существующие решения.

Или получить больший контроль над одним из ключевых слоев платформы.

Мы выбрали второе.

В результате начали переходить от прежнего стека к собственной real-time-системе.

И здесь важно еще раз подчеркнуть: мы сделали это не потому, что используемые технологии были плохими.

Хорошая технология тоже может перестать соответствовать конкретному продукту.

Похожая логика привела нас к созданию ConnectX — собственного протокола LO.

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

На практике причины значительно прозаичнее.

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

В одном из обновлений оптимизация ConnectX позволила примерно на 20% ускорить установление соединения.

Для большинства пользователей название ConnectX ничего не значит.

И не должно.

Человек не должен знать, какой протокол используется внутри LO.

Он должен открыть приложение — и оно должно быстро работать.

Вообще, лучшие инфраструктурные технологии обычно именно такие.

Пользователь не замечает их существования.

Но мгновенно замечает их отсутствие.

После таких примеров может сложиться впечатление, что наша конечная цель — постепенно заменить все внешние технологии собственными.

Это не так.

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

Но одновременно существует огромное количество open-source-проектов, которые делают свою работу превосходно.

Переписывать их только ради того, чтобы сказать «у нас всё свое», бессмысленно.

Собственная технология — это дорого.

Причем стоимость ее разработки — только начало.

Дальше ее нужно поддерживать.

Тестировать.

Документировать.

Следить за безопасностью.

Обеспечивать обратную совместимость.

Оптимизировать.

Исправлять ошибки.

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

У зрелого open-source-проекта часть этой работы распределена между большим количеством разработчиков и компаний по всему миру.

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

Поэтому мы не оцениваем технологическую зрелость LO количеством собственных разработок.

Есть только один действительно важный вопрос:

дает ли контроль над этой технологией преимущество самому продукту?

Если нет — хорошее готовое решение часто будет правильным выбором.

За восемь лет у нас постепенно сформировалось три подхода.

Если существует хорошая открытая технология, которая полностью отвечает требованиям LO, — мы ее используем.

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

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

Это позволяет не впадать ни в одну из крайностей.

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

Вторая — пытаться написать самостоятельно абсолютно всё и тратить инженерные ресурсы на задачи, которые уже прекрасно решены.

Нам не подходит ни один вариант.

Хороший open source мы используем. Критические технологии контролируем. А там, где существующие решения начинают ограничивать LO, можем создавать свои.

Но есть еще одна вещь, которая, на мой взгляд, важнее выбора конкретной технологии.

Это возможность от нее отказаться.

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

Изменится продукт.

Появится новая технология.

Изменятся требования пользователей.

Сам проект станет больше.

Поэтому одна из главных архитектурных ошибок — не использование стороннего решения само по себе.

Ошибка — построить систему таким образом, что заменить его практически невозможно.

За восемь лет мы неоднократно убеждались в этом.

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

В тот момент оно позволило быстрее развивать LO.

Оно выполнило свою задачу.

Но продукт изменился — и архитектура должна иметь возможность измениться вместе с ним.

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

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

Внутри платформы развиваются общение, Flows, сообщества, музыка, места и события. Мы работаем над картографическим направлением.

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

И здесь требования к фундаменту становятся другими.

Пока вы создаете одно приложение, инфраструктура обслуживает ваш продукт.

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

В этот момент возможность самостоятельно определять развитие критических технологий становится особенно важной.

Поэтому собственная технологическая база для нас — не способ сказать, что у LO «всё свое».

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

Это вполне справедливый вопрос.

Сегодня в LO зарегистрировано более 110 тысяч пользователей.

По меркам крупнейших социальных платформ — немного.

Мы могли направить больше ресурсов на маркетинг и меньше — на инфраструктуру.

Вероятно, тогда цифра зарегистрированных пользователей сегодня была бы больше.

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

Большую часть этих восьми лет мы инвестировали прежде всего в сам продукт и его технологии.

И более 110 тысяч пользователей — не тот масштаб, на котором мы хотим остановиться.

Теперь задача меняется.

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

Следующий этап должен показать другое:

способны ли мы эту платформу масштабировать.

Сегодня у LO много собственных решений.

Одновременно внутри нашей инфраструктуры остается много отличного open source.

И я не вижу здесь никакого противоречия.

Наоборот.

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

Создавать собственную технологию там, где она дает преимущество.

Использовать открытую там, где она эффективнее.

Менять решение, когда меняются требования.

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

Сегодня мы технически не зависим от одного внешнего решения, без которого развитие LO остановилось бы.

И именно это для меня является технологической независимостью.

Не количество собственных репозиториев.

Не процент самостоятельно написанного кода.

И не попытка построить всё с нуля.

Наша цель — не независимость от чужого кода. Наша цель — независимость от чужих решений.

Open source дает нам возможность использовать лучшее из того, что уже создано.

Собственные технологии дают контроль там, где он действительно необходим.

А архитектура должна давать самое важное — возможность выбирать между ними.