Тендеры и лиды
Информация
Когда создаёшь технологический продукт, рано или поздно сталкиваешься с выбором: использовать готовое решение или разрабатывать собственное.
На первый взгляд всё просто. Готовая технология экономит время, а собственная даёт больше контроля. Но за годы разработки социальной платформы LO я убедился, что в реальности этот выбор гораздо сложнее.
Ошибочное решение может стоить команде месяцев работы, увеличить расходы на поддержку и замедлить развитие продукта.
И дело далеко не всегда в качестве самой технологии.
На ранних этапах разработки продукта главный ресурс — время.
Когда ещё необходимо проверить концепцию, запустить первые функции и получить обратную связь пользователей, создание собственной инфраструктуры редко бывает приоритетной задачей.
В LO мы тоже начинали с готовых технологий.
Для коммуникаций в реальном времени использовали существующие решения, включая Centrifugo и mediasoup. Для хранения данных и управления инфраструктурой — PostgreSQL, Kubernetes и другие инструменты с открытым исходным кодом.
Это позволило сосредоточиться на развитии самого приложения, а не на создании всех его компонентов с нуля.
Однако со временем ситуация меняется.
Чем сложнее становится продукт, тем больше требований возникает к его архитектуре. И технология, которая помогала быстро развиваться на старте, может начать ограничивать дальнейшие изменения.
Одна из распространённых ошибок — оценивать готовое решение только по стоимости лицензии.
Open source может быть бесплатным, но интеграция, адаптация, сопровождение и обновление требуют времени разработчиков.
Для бизнеса это вполне конкретные расходы.
Допустим, команда использует готовую инфраструктуру, которая закрывает большинство задач. Но для реализации новых функций приходится создавать дополнительные механизмы, обходить архитектурные ограничения и поддерживать сложные интеграции.
Каждое такое изменение по отдельности может казаться небольшим.
Проблема возникает, когда они начинают накапливаться.
В какой-то момент значительная часть инженерных ресурсов уходит не на развитие продукта, а на адаптацию чужой технологии под собственные требования.
И тогда необходимо пересматривать первоначальное решение.
В LO коммуникации в реальном времени являются одной из ключевых частей платформы.
Приложение объединяет личные и групповые чаты, голосовые и видеозвонки, сообщества, пользовательский контент и другие цифровые сервисы.
По мере развития продукта нам потребовалось больше контроля над установлением соединений, восстановлением связи после разрывов и обработкой изменений сетевого состояния.
Особенно это важно для мобильных устройств.
Пользователь может переключаться между Wi-Fi и мобильным интернетом, временно терять связь или возвращаться в приложение после длительного перерыва.
Коммуникационная инфраструктура должна учитывать такие сценарии и обеспечивать предсказуемое поведение приложения.
В результате мы приняли решение развивать собственный коммуникационный слой и создали ConnectX — протокол взаимодействия клиентских приложений с серверной инфраструктурой LO.
Но это решение было связано не с желанием отказаться от open source.
Нам требовался инструмент, архитектуру и развитие которого мы могли бы контролировать самостоятельно.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13829 тендеров
проведено за восемь лет работы нашего сайта.
Когда компания создаёт собственную инфраструктуру, она получает возможность адаптировать её под конкретные задачи продукта.
Но одновременно берёт на себя ответственность за всё, что раньше обеспечивалось внешним решением.
Необходимо самостоятельно заниматься тестированием, безопасностью, совместимостью компонентов, мониторингом, документацией и дальнейшим развитием технологии.
Поэтому я не считаю собственную разработку универсально правильным решением.
Она оправданна только тогда, когда преимущества контроля и гибкости перевешивают затраты на создание и сопровождение.
Для ConnectX такой подход соответствовал нашим требованиям к развитию коммуникационной инфраструктуры LO.
Но это не означает, что аналогичное решение было бы правильным для любого другого продукта.
После создания ConnectX мы не стали переписывать остальные компоненты платформы.
В LO по-прежнему используются PostgreSQL, Kubernetes и другие зрелые программные решения.
На мой взгляд, нет смысла создавать собственную базу данных или систему оркестрации контейнеров только ради технологической независимости.
Такая разработка потребовала бы значительных ресурсов, которые можно направить на улучшение пользовательского опыта и развитие продукта.
Технологическая независимость для меня заключается не в количестве собственного кода, а в способности компании самостоятельно определять архитектуру критически важных компонентов.
Готовые технологии и собственные разработки не противоречат друг другу.
Наоборот, их разумное сочетание позволяет команде эффективнее использовать ограниченные ресурсы.
За годы работы над LO я выделил несколько вопросов, которые помогают принимать подобные решения.
Первый — насколько компонент важен для ключевых функций продукта.
Если от него напрямую зависит пользовательский опыт, контроль над технологией может иметь стратегическое значение.
Второй — действительно ли готовое решение ограничивает дальнейшее развитие.
Не каждое неудобство требует переписывания инфраструктуры. Иногда проблему можно решить изменением архитектуры интеграции или оптимизацией существующей системы.
Третий — сколько будет стоить владение технологией на протяжении нескольких лет.
Важно учитывать не только первоначальную разработку, но и поддержку, обновления, тестирование и возможные технические риски.
Четвёртый — есть ли у команды необходимые компетенции.
Создать рабочий прототип и обеспечить стабильную эксплуатацию критически важной инфраструктуры — разные задачи.
Пятый — какие возможности команда теряет, выбирая собственную разработку.
Инженерные ресурсы ограничены. Время, потраченное на инфраструктуру, нельзя одновременно направить на новые функции продукта.
Поэтому решение должно учитывать не только технические преимущества, но и альтернативную стоимость разработки.
Когда мы начинали создавать LO, многие решения принимались исходя из необходимости быстрее запустить продукт.
Сегодня, когда платформа объединяет коммуникации, сообщества, контент и цифровые сервисы, требования к архитектуре стали другими.
Но главный принцип остался прежним: технологии должны помогать развивать продукт, а не становиться самоцелью.
Я не считаю правильным ни полный отказ от готовых решений, ни безусловную зависимость от них.
В одних случаях использование open source позволяет существенно ускорить развитие. В других собственная технология становится необходимым инструментом для дальнейшего масштабирования.
Главное — вовремя определить разницу между этими ситуациями.
Именно этот баланс мы продолжаем искать при развитии LO.
Никита Чиров, основатель LO.
