Как мы делили бизнес 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 для клиентов из РФ. Конкретики было мало, и надо отметить, что до сих пор мы не потеряли доступ. Тем не менее риск остаться без доступа к инфраструктуре, исходникам и всем клиентским базам данных нельзя было игнорировать, нужно было действовать и очень быстро.

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

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

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

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

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

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

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

• Первое — инфраструктура (где хранятся данные). Как раз на хранение данных оказывает влияние законодательство.
• Второе — зависимость от технологического стека. Здесь в первую очередь речь идет о проприетарном ПО, таком как Microsoft SQL, или других облачных сервисах, таких как Amazon Web Services или Azure Microsoft.

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

Декабрь 2021

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

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

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

Март 2022

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

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

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

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

• Технологическая развитость,
• Большое количество сервисов, в частности управляемый кластер SQL серверов, управляемый класс Kubernetes, очередь сообщений.

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

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

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

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

• Так как мы использовали Azure, то подсели на весь технологический стек. Мы использовали не только виртуальные машины, но сервисные шины, облачные функции, serverless (бессерверные) вычисления, отдельную редакцию Azure SQL. Соответственно среда разработки была тоже Azure DevOps. Так как при переходе меняется всё, начиная от среды разработки, заканчивая языками, на которых всё пишется, то пришлось переходить на новую среду разработки (GitLab).
• Возникли определенные особенности работы баз данных. Несмотря на то, что и в Azure, и в Яндекс, это SQL сервер, оказалось, что в нескольких запросах обычная редакция Enterprise Edition на Яндексе ведет себя не так, как ожидалось.

На примере: есть довольно сложный запрос, который генерит приложение и отправляет его в базу данных. На 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 дней.