Особенности Yandex Cloud в Казахстане

В 2015-2016 году я руководил проектом адаптации небольшого SaaS (разрабатываемого до этого ещё лет 5) к модели Managed On-premise (и заодно White Label), когда необходимо было развернуть несколько выделенных копий сервиса (помимо тестовых окружений) для крупных клиентов. Делом это оказалось небыстрым и кропотливым, и вылилось в длинную цепочку взаимосвязанных планов, доработок и релизов. Пришлось решать вопросы развёртывания на разных площадках со своими техническими особенностями, менять подход к циклам релизов (синхронная выкатка затруднена), добавлять фиче-флаги, новые параметры, заводить независимые аккаунты используемых коммерческих сервисов (типа рассылок), менять принципы тарификации, убирать из кода массу вшитых вещей типа доменов, брэндирования, некоторых текстов, учиться эффективно собирать и выкатывать брэндированные версии мобильных приложений. Основательно в этом помогло то, что мы использовали SaltStack (по нему я веду отдельный блог). Короче ужас-ужас.

Но даже имея такой опыт, я всё равно затрудняюсь представить, чего стоило команде Яндекс Облака запустить отдельную копию в Казахстане… Многие технологии облака росли из технологий самого Яндекса, и наверняка там за десятилетия развития было зашито много завязок на единую компанию-владельца и её инфраструктуру. Потом появилось облако и видимо была проделана большая работа по выделению сервисов в независимые компоненты и инстансы. И тут раз, потребовалось поднять отдельную суверенную копию облака, сохранив при этом эффективность развития и управления.

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

И всё-же я не рад, что всё это обособлено в отдельные структуры. Для Яндекса это вероятно выльется в дополнительные накладные расходы (организационные, технические, финансовые) и снизит скорость развития сервисов. AWS в силу большей централизации таких потерь не имеет, а следовательно эффективнее. Для пользователей облака это выльется в то, что в единой консоли Yandex Cloud нельзя просто взять и выбрать зону kz1-a или ru-central1-a и получить вычислительные ресурсы в нужном регионе, оплачивая их в своей валюте.

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

• API Gateway
• Cloud Functions
• Serverless Containers
• Data Streams
• Cloud Postbox
• Yandex Query
• IoT Core
• Managed YDB
• CDN
• SpeechKit

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

• Lockbox
• Cloud DNS
• Monitoring
• Object Storage
• Message Queue
• Certificate Manager
• Audit Trails
• Container Registry
• Key Management Service
• Data Transfer
• Cloud Logging

Вот табличка (в разрезе бессерверных компонентов, и скорее всего не исчерпывающая) со списком технических различий которые я обнаружил:

Уже по количеству разных доменов и выделенному LIR можно догадаться о масштабах проекта суверенного облака в Казахстане. Вообще свой TLD yandex это довольно престижно, было бы неимоверно круто если бы Яндекс консолидировал под ним все ресурсы.

Интересно, а были ли в Яндексе дебаты по поводу основного домена облака - yandex.cloud или cloud.yandex?

В заключение, небольшие пояснения по табличке:

• Разные адреса консоли, организации, биллинга и мониторинга нужно указывать для доступа к облаку в соответствующей стране. К счастью, для доступа к KZ консоли оказалось достаточно моего аккаунта на российском yandex.ru.
• YC CLI endpoint необходим для управления ресурсами конкретного облака из командной строки. Российский endpoint зашит по умолчанию, казахский нужно указывать явно в параметре --endpoint или профиле конфигурации. Обратите внимание на соответствующие различия в документации RU и KZ. Под капотом используются и поддомены, например отдельный IAM iam.api.yandexcloud.kz.
• Тот же самый endpoint необходимо указывать и в блоке конфигурации provider в Terraform.
• Cloud Storage Endpoint потребуется указывать в утилитах совместимых с S3 (AWS CLI, rclone и десятках других), а также библиотеках типа boto. И да, это отдельное пространство имён бакетов, которые обязаны быть уникальными.
• Message Queue Endpoint нужен для boto и других SDK совместимых с AWS SQS.
• Планируются две дополнительные зоны доступности
• Мобильное приложение для iOS (для Android возможно тоже, но я не проверял) облако в Казахстане пока не поддерживает

Если вы хотите обеспечить возможность деплоя копии вашего проекта в Казахстане, вам потребуется учесть все эти параметры в Terraform коде (а без Terraform обеспечить идентичность окружений довольно проблематично и трудоёмко). Также рекомендую к зазубриванию принципы The Twelve-Factor App. Мне в своё время они сильно помогли в реализации проекта упомянутого в начале статьи.

Бесплатный тестовый доступ на два месяца к Yandex Cloud в РК можно получить тут.

16 мая 2024 года состоялось мероприятие Yandex Cloud Kazakhstan Deep Dive, где раскрыты некоторые подробности запуска Яндекс Облака в Казахстане:

Если у вас есть вопросы или уточнения, можете написать мне .