Как мы делили бизнес Timetta между Россией и Европой

Timetta — облачное решение для учета времени, контроля проектов и управления ресурсами. В далеком 2017 году я рассказывал о нашем продукте в рубрике Трибуна, правда тогда он еще назывался WorkPoint. В этой заметки расскажу, как после февраля 2022 года нам пришлось делить бизнес.

Timetta — специализированное решение, предназначенное, в первую очередь, для компаний из сферы Professioanal Services (консультантов, аудиторов, проектировщиков, архитекторов и так далее). С первых дней работы над продуктом, мы понимали, что таких компаний в России не слишком много, если сравнивать с Европой и Северной Америкой. Поэтому сразу делали продукт мультиязычным, а в качестве локации для размещения выбрали инфраструктуру Microsoft Azure и кластер в Ирландии.

Размещение в Azure определило и технологический стек. Под капотом Timetta активно использовались сервисы Azure, например Elastic Pool Azure DB на базе MS SQL, Application Insight, сервисную шину и многое другое. Это сильно упрощало разработку и администрирование, но повышало зависимость от сервисов Microsoft. реда разработки была тоже Azure DevOps и все исходники хранились там же. В 2016 году было сложно предугадать, что зависимость от Azure станет критической проблемой для продукта в РФ.

Для поддержки продаж в Европе мы открыли компанию в Чехии, которая получила права на дистрибуцию Timetta. При этом важно, что и продукт и инфраструктура были едины для всех локаций.

А потом наступил 2022 год.

В феврале мы получили от Microsoft сообщение о том, что компания планирует приостановить доступ к сервисам Azure для клиентов из РФ. Конкретики было мало, и надо отметить, что до сих пор мы не потеряли доступ. Тем не менее риск остаться без доступа к инфраструктуре, исходникам и всем клиентским базам данных нельзя было игнорировать, нужно было действовать и очень быстро.

Стало ясно, что дальше жить с одним продуктом для Европы и РФ не получится, это должны быть две полностью автономные системы и, соответственно, независимые компании.

Система для клиентов из РФ, равно как и их данные, должны полностью переехать на территорию России и стать независимыми от внешних поставщиков проприетарного ПО, на сколько это возможно.

Так мы начали «Большой переезд».

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

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

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

Что касается импортозависимости, здесь есть две стороны вопроса:

Так что задачи при переезде было две: перенести данные в РФ и скорректировать технологический стек так, чтобы он был импортонезависимым.

Декабрь 2021

К концу 2021 года выпустили on-premises версию, которая предназначена для развертывания на базе Linux-контейнеров в среде Kubernetes или любого другого совместимого регистратора.

Это позволяло крупным клиентам ещё в конце прошлого года приземлять данные на территории РФ в собственном корпоративном облаке или любом другом месте корпоративного хранения.

Поскольку мы перешли на развертывание на Linux контейнерах, то это был первый шаг к импортонезависимости технологического стека.

Март 2022

К концу 2021 года события стали ускоряться, и мы также приняли решение о переносе облачного сервиса на территорию РФ. Одним из последних аргументов в пользу переезда было письмо от компании Name Chip, регистратора доменных имен, о том, что мы должны убрать свои домены с их площадки.

Мы посмотрели существующие на рынке решения (Yandex.Cloud, облачные решения от Mail и Ростелеком). В данном случае нас интересовали PaaS (Platform-as-a-service) — поставщики платформенных облачных услуг.

Мы остановили свой выбор на Yandex.Cloud.

Выбрали эту платформу по двум причинам:

Ещё один важный фактор — действительно хорошая документация.

Мы приняли решение, начали работы. Когда поняли, что общественные, политические и экономические риски становятся неуправляемыми, запустили перенос системы на Yandex.Cloud. Начали работы за дне недели, перенесли всё за три дня 6-8 марта.

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

Какие возникают проблемы при переносе:

На примере: есть довольно сложный запрос, который генерит приложение и отправляет его в базу данных. На Azure SQL запрос отправляется 3 миллисекунды, тут он выполнялся в 400-500 раз медленнее. Конечно, не всё работает так, только один конкретный запрос. Но всё равно это требует внимания и большой работы — отслеживать, переписывать, адаптировать.

Плюс из-за того, что нам нужно было время на то, чтобы перенести систему протестировать её и запустить, пришлось взять технологическое окно. Мы сделали это в длинные выходные 6-8 марта, но оказалось что для многих компаний и это чувствительно. За три дня в поддержку пришло больше 50 писем + какое-то количество звонков, хотя, конечно, мы предупреждали о перерыве в работе.

Сейчас для российских компаний мы работаем на open-source стеке и инфраструктуре на базе Yandex.Cloud, а также предоставляем клиентам развертывание системы в их инфраструктуре.

Для финальных клиентов ничего не изменилось. Условия соглашений не меняются, по-прежнему наш главный параметр — это отказоустойчивость системы. Система должна быть доступна 95-99% времени, и этот параметр мы не меняем. Второй параметр — время отклика системы, его мы также не планируем снижать.

Что касается стоимости одной вычислительной единицы — пока не понятно. С одной стороны — именно по базовым вычислительным мощностям (сloud сomputing) Яндекс дешевле. Но в Azure более совершенная архитектура. Она позволяет добиться большей вычислительной плотности. Elastic data pool и прочие приложения позволяют купить немного мощностей, но расширяться каждую минуту, если нужно больше ресурсов. У Яндекса же покупается лицензия SQL вообще, и в течение месяца невозможно маневрировать. У нас же потребность в вычислениях может расти и сокращаться не то что в течение месяца — в течение дня. Например, в понедельник и пятницу, когда в Timetta все заполняют таймшиты.

Плюс, так как раньше Timetta работала и в Европе, и в России, то компания до сих пор обвязана большим количеством сервисов, которые хостятся или управляются западными компаниями, в частности CRM, Microsoft Office и прочие. Мы решили, что рисковать данными клиентов не можем, поэтому именно их перенесли в первую очередь. В сервисах же, где мы пока можем сохранять универсальность, пробуем её сохранять. Но в целом исходим из того, что технологическая изоляция будет продолжаться и лучше быть готовыми к тому, чтобы иметь всё локальное.

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

Здесь можно получить бесплатный доступ к Timetta на 14 дней.