Cloud, on-prem или sovereign hosting для telco data: три варианта с разными trade-offs

Три варианта в сегодняшней реальности УЗ

Когда обсуждается «cloud vs on-prem» для телекома, в реальности это решение из трёх вариантов.

Public cloud (AWS, Azure, GCP). Международные провайдеры с высокими возможностями и проверенной надёжностью. В УЗ — присутствие ограниченное (нет локальных регионов у major-провайдеров), latency выше, вопросы по data residency.

On-prem. Собственная инфраструктура. Полный контроль. Капиталоёмкая модель. Ответственность за операции на операторе.

Sovereign cloud. Локальные cloud-провайдеры, частно operated с регуляторными лицензиями. Data residency в стране. Возможности обычно меньше, чем у крупных public-провайдеров, но достаточные для большинства use cases.

Каждый вариант имеет свою область применимости, и универсальный ответ «всё в cloud» или «cloud не подходит по регуляторным причинам» — упрощение, которое не отражает реальность.

Сравнение по ключевым параметрам

Параметр	Public cloud	On-prem	Sovereign cloud
CapEx	низкий	высокий	низкий-средний
OpEx	высокий-предсказуемый	средний	средний
Capability frontier	самый высокий	ограничен командой	средний
Data residency	сложно для строгих требований	полный контроль	локальная
Регуляторная простота	сложно	простая	простая
Доступность специалистов локально	сложно	проще	проще
Time to provision	минуты	месяцы	часы-дни
Vendor lock-in	высокий	низкий	средний

Что определяет выбор

Класс данных. Customer PII, биометрические данные, финансовые транзакции обычно требуют data residency. Подходят sovereign cloud или on-prem. Маркетинговая аналитика, доставка контента могут жить в public cloud.

Требования к latency. Customer-facing real-time требует низкой latency. Cloud-регионы в УЗ ограничены. Если public cloud — нужен либо edge presence, либо sovereign cloud.

Доступность специалистов. Public cloud требует экспертизы, которой на локальном рынке относительно мало. On-prem-специалистов больше, но число снижается. Sovereign cloud — middle ground.

Total cost of ownership. Зависит от sizing, паттернов трафика. Public cloud дешевле для переменных нагрузок, дороже для стабильных high-volume.

Регуляторный ландшафт. Регуляторная рамка УЗ для трансграничной передачи данных (Закон о ПДн ЗРУ-547) ставит ограничения для определённых классов данных.

Гибридная модель часто оптимальна

Чисто один или другой редко работает. Большинство операторов выбирают гибрид:

Customer-facing real-time core — sovereign cloud или on-prem (низкая latency, регуляторное соответствие).

Аналитика, ML-обучение, batch-обработка — public cloud (возможности, масштаб).

Бэкап и DR — split (sovereign плюс public).

Разработка и тестирование — public cloud (скорость, гибкость).

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

Что часто идёт не по плану

Public cloud bill shock. Provisioning без дисциплины ведёт к неожиданным затратам. Через 12 месяцев обнаружение «мы тратим X на cloud» становится организационной проблемой.

Завышенная оценка on-prem capacity. Покупают 5-летний capacity upfront, через 2 года спрос меняется, инфраструктура underutilised. CapEx потерян.

Пробелы в возможностях sovereign cloud. Локальный провайдер не имеет конкретного нужного сервиса. Workaround (кастомная сборка) — overhead выше ожидаемого.

Гибрид без ясного ownership. Без чёткого архитектурного стандарта команды используют разные clouds inconsistently. Фрагментация.

Vendor lock-in через специфические cloud-сервисы. Сборка на проприетарных cloud-сервисах делает миграцию prohibitively expensive позже.

Когда какая модель подходит

Public cloud first. Если оператор small или mid-size без строгих требований к data residency, фокус на росте, есть cloud-skilled команда.

On-prem first. Если оператор large, established, имеет существующую инвестицию в data center, регуляторная среда строгая, CapEx доступен.

Sovereign cloud first. Если data residency строго требуется, локальные возможности адекватны, CapEx ограничен, операционная команда среднего уровня.

Гибрид. Если бизнес-нагрузки структурно разнообразны — есть real-time customer-facing И large-scale аналитика, И legacy-системы, которые сложно мигрировать.

Что обсудить на committee

Какова регуляторная среда для трансграничной передачи данных для специфики оператора? Это часто определяет основные ограничения.

Какова текущая инфраструктурная инвентаризация и возраст? Это влияет на CapEx, доступный для обновления on-prem.

Какова доступность cloud-специалистов в команде? И ландшафт найма?

Какое 5-летнее TCO-сравнение для каждого варианта? Не «cloud дешевле», а конкретные числа.

Готов ли организационно на гибридную сложность, если выбран гибрид?

Что может сделать SamaraliSoft

Hosting Strategy Architecture — классификация нагрузок по требованиям (data residency, latency, масштаб, частота изменений), TCO-моделирование по трём вариантам, анализ регуляторной рамки, дизайн гибридной архитектуры если применимо и поэтапный migration roadmap в течение 18-24 месяцев.

Внутренние ссылки

• /architecture/telecom-around-core-architecture/ — слой вокруг core
• /insights/telecom-data-contracts/ — data contracts
• /insights/telecom-event-driven/ — событийный фундамент
• /insights/telecom-master-data/ — master data

Источники

• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома
• ЦБ РУ — биометрическая верификация digital banking
• MNP.UZ — портабельность