Привет, Хабр!  

Очередная «революционная» облачная платформа? Да ладно! Похоже, в этом году нас ждет парад похожих историй — все как один «независимые», «инновационные» и «готовые заменить AWS». 

В чем дело? В июне этого года MWS (входит в облачный бизнес МТС) официально заявила о запуске новой облачной платформы собственной разработки MWS Cloud Platform — без зависимостей от вендоров и сторонних технологий, Серьёзно — совсем без зависимостей? Захотелось разобраться, что действительно скрывается за такими заявлениями.

В этой статье последовательно проанализируем все аспекты платформы — от процесса регистрации до конкретных сервисов, сравним с решениями конкурентов и дадим объективную оценку. Особое внимание уделим тем моментам, где слова расходятся с реальным положением дел, а также проанализируем, насколько платформа готова к использованию в production-среде. 

P.S. Информация актуальна на момент публикации статьи.

«Когда я увидел отсылку к собственной разработке, сразу вспомнил ряд подобных проектов, которые через год тихо закрывались. Хотелось бы ошибаться, но пока это выглядит как очередная переупаковка привычных нам вещей. И VMware тут совсем не причем», — Frontend Tech Lead

Первое знакомство: 10 дней ожидания вместо мгновенного доступа

В ноябре 2024 года MWS запустила реалити-проект про разработку облака и пригласила избранных на бета-тестирование (видимо, только тех, кто готов ждать 10 дней) своего «уникального» решения. Заявлено: никакого зарубежного кода, полный суверенитет и магия импортозамещения.  

Но как только я попытался зарегистрироваться, волшебство закончилось: 

1. Заполняешь форму (имя, почта, телефон — все по классике).  

2. Ждёшь «ручной проверки» (даже мой домашний NAS умеет автоматически выдавать доступ).  

3. Получаешь письмо: «Спасибо за интерес! Ожидайте ответа до 10 дней».

10 дней? Ребята, за это время я уже разверну кластер в Yandex Cloud или даже на Raspberry Pi в подвале своего дедушки! 

 4. Второе письмо: «Давайте созвонимся!»

Нет, я не хочу обсуждать мои тест-драйвы по телефону, я хочу просто попробовать ваш сервис! 

 Вывод: Нет self-service, нет мгновенного доступа.

 Почему это плохо?

• Кто будет ждать 10 дней в эпоху instant-доступа в AWS/Yandex Cloud?

• Если платформа такая инновационная, почему нельзя дать триал без допросов?

Интерфейс: PREVIEW как синоним «мы это не доделали» 

После преодоления барьера регистрации пользователь попадает в панель управления, которая структурно разделена на несколько ключевых разделов:

1. Организация — управление проектами, пользователями и биллингом.

2. Консоль управления — основные сервисы платформы, внутри которой можно выделить отдельно Virtual Infrastructure — работа с VMware vCloud Director.

Раздел «Организация» — база есть, но без изысков

В разделе организации находится стандартный набор инструментов управления. Проекты позволяют управлять платежами в биллинг-аккаунте и ресурсами — классическая схема, знакомая по AWS Organizations или GCP Resource Manager. Все ресурсы создаются внутри проектов, что логично и правильно с точки зрения изоляции.

Управление пользователями и ролями реализовано в стиле «админ, юзер, наблюдатель» с возможностью настройки сервисных ролей. Базовый функционал присутствует, но до гибкости AWS IAM или даже Yandex Cloud IAM здесь как до Луны пешком. Биллинг-аккаунты позволяют отслеживать расходы — тоже стандартная функциональность без революций.

Консоль управления: парад PREVIEW-сервисов

Здесь начинается самое интересное. Практически все сервисы помечены как PREVIEW, что в переводе с корпоративного означает «ребят, мы это еще не доделали». Давайте пройдемся по каждому сервису и посмотрим, что же нам предлагает «платформа собственной разработки».

Compute (Preview): амбиции есть, реализация хромает. Железная хватка ограничений

Первое, что бросается в глаза при работе с Compute — статус PREVIEW без SLA и бесплатное использование через грант. Честно предупреждают: только для тестирования. Спасибо за честность, но когда же production?

При создании виртуальной машины видим две зоны доступности — неплохо для старта, хотя у AWS в регионе обычно минимум три AZ, а у Yandex Cloud в московском регионе уже четыре зоны. Типы инстансов разделены на General Purpose, CPU optimized и Memory optimized — правильный подход к сегментации ресурсов.

Диапазон конфигураций простирается от скромных 2 vCPU и 8 GB RAM до вполне приличных 48 vCPU и 192 GB RAM. Наличие CPU-оптимизированных инстансов с соотношением 2:1 (память к CPU) — хороший знак понимания потребностей рынка. Но вот создать custom-конфигурацию как в Google Cloud или определить гарантированную долю vCPU как в Yandex Cloud — увы, нельзя. В эпоху, когда AWS предлагает буквально сотни типов инстансов под любую задачу, такая негибкость выглядит архаично.

Где мои операционные системы?

Самый болезненный момент — полное отсутствие выбора операционных систем. В Yandex Cloud при создании ВМ можно выбрать из десятков образов ОС и тут же добавить продукты из маркетплейса. В AWS Marketplace вообще тысячи готовых AMI под любую задачу. А здесь? Тишина. Даже базового выбора между Ubuntu, CentOS и Windows Server нет в интерфейсе.

«Отсутствие выбора операционной системы при создании ВМ  — это даже не смешно. Где Ubuntu разных версий? Где CentOS, Rocky Linux, Debian? Где Windows Server для тех несчастных, кому он нужен? Где готовые образы с преднастроенным софтом?», — системный инженер, представитель банковской сферы

Цены? Какие цены?

Еще один критический недостаток — полное отсутствие информации о стоимости на этапе конфигурации ВМ. В Yandex Cloud, AWS и GCP калькулятор стоимости интегрирован прямо в мастер создания ресурсов. Ты видишь, сколько будет стоить твоя конфигурация в час, день, месяц. Здесь же — игра в угадайку. Для облачной платформы в 2025 году это неприемлемо.

Сетевые настройки: есть плюсы, но минусов больше

При настройке сети радует возможность резервирования статического внутреннего IP — критически важная функция для кластеров и баз данных. Приятно, что при создании новой сети она автоматически подключается к ВМ без выхода из мастера — хороший UX-момент.

Но дальше начинаются проблемы. По умолчанию ВМ создается без доступа из интернета — с точки зрения безопасности это правильно, но отсутствие опции «Assign public IP» прямо в мастере создания заставляет делать лишние телодвижения. В AWS, GCP и Yandex Cloud эта опция есть везде. Более того, полностью отсутствует информация о настройке Firewall в процессе создания ВМ.

Yandex Cloud позволяет прямо при создании включить DDoS-защиту и привязать группы безопасности. AWS предлагает выбрать Security Groups. Здесь же — ничего. Для доступа предлагаются только SSH-ключи, хотя тот же Yandex Cloud уже давно реализовал OS Login с SSH-сертификатами для централизованного управления доступом.

Диски: один тип для всех

Ситуация с дисками вызывает недоумение. Boot-диск можно создать размером от 10 GB до 16 TB, но тип диска жестко зафиксирован — только nbs-pl2. Серый замочек рядом с типом диска и пропускной способностью красноречиво намекает: выбора не будет.

Для сравнения: AWS EBS предлагает целый зоопарк типов дисков (gp3, io2, st1, sc1) с настраиваемыми IOPS и throughput. Google Cloud позволяет выбирать между standard, balanced и SSD persistent дисками с разными характеристиками производительности. Yandex Cloud предоставляет network-ssd и network-hdd диски с возможностью выбора производительности. А здесь — один тип на все случаи жизни.

Шифрование дисков и автоматическое резервное копирование? Забудьте. В AWS это базовые опции, доступные прямо в мастере создания. Здесь их просто нет.

Снимки (Snapshots) и Образы (Images)

Интерфейс элементарный, останавливаться тут не вижу смысла.

VPC (Preview): сеть уровня домашней лаборатории

Раздел VPC производит впечатление учебного проекта по сетевым технологиям. Да, можно создавать сети и подсети, управлять внешними IP-адресами. Firewall-правила настраиваются по классической схеме: направление (Ingress/Egress), действие (Allow/Deny), источник и назначение трафика, порты и протоколы. База есть, но этого катастрофически мало для production-использования.

MTU зафиксирован на уровне 1500 байт без возможности изменения. Для сравнения, в AWS можно настроить Jumbo Frames до 9000 байт для повышения производительности в определенных сценариях. DHCP-опции ограничены доменным именем и DNS-серверами — минимальный набор без возможности тонкой настройки.

Где мой NAT Gateway?

Самое болезненное — отсутствие NAT Gateway. В разделе маршрутов можно задать только имя, диапазон назначения и next hop. Создать полноценную таблицу маршрутизации как в AWS VPC? Забудьте. Настроить NAT для выхода приватных подсетей в интернет? Не предусмотрено. Визуализация топологии сети? Даже не мечтайте.

Для сравнения: AWS VPC предоставляет NAT Gateway, Internet Gateway, Transit Gateway, VPC Peering, VPN connections, Direct Connect. Google Cloud VPC имеет Cloud NAT, Cloud Router, VPC Peering, Cloud VPN. Yandex Cloud предлагает NAT-инстансы, VPN, пиринги между сетями. MWS в этом плане застряла где-то в 2010 году.

Вывод по VPC: Это не enterprise-ready сеть, это максимум песочница для разработки. Без NAT, нормальной маршрутизации, VPN и пирингов в production с этим делать нечего. Если вам нужна изоляция на уровне "чтобы было", то сойдет. Если нужна реальная сетевая инфраструктура —то это слабовато.

Object Storage: S3-совместимость без S3-функциональности

Объектное хранилище MWS производит впечатление типичной S3-совместимой системы на базе open source решения вроде MinIO или Ceph. Базовый функционал присутствует: создание бакетов, загрузка объектов до 5 GB, управление правами через IAM.

Приятно удивляет наличие версионирования и WORM-блокировки (Write Once Read Many) уже в preview-версии — многие молодые облачные платформы об этом даже не задумываются. Шифрование реализовано корректно: по умолчанию ключами провайдера, опционально — клиентскими через KMS. Есть поддержка CORS для веб-приложений и HMAC-ключи для программного доступа.

После создания бакета доступен богатый набор разделов: управление объектами, конфигурация, права доступа, защита данных, жизненный цикл, мониторинг, логирование и операции. Мониторинг показывает операции чтения/записи в секунду, входящий/исходящий трафик, занятое место и количество объектов — стандартный набор метрик. Логирование сохраняет информацию о всех операциях в указанный бакет — тоже полезная функция.

Критические недостатки

Но дьявол, как всегда, в деталях. Главная проблема — полное отсутствие классов хранения. В Amazon S3 есть Standard, Standard-IA, One Zone-IA, Glacier Instant, Glacier Flexible, Glacier Deep Archive. В Google Cloud Storage — Standard, Nearline, Coldline, Archive с автоматическим Autoclass. В Yandex Object Storage — стандартное, холодное и ледяное хранилище. Каждый класс оптимизирован под свой паттерн доступа и существенно влияет на TCO.

В MWS? Один класс для всех. Это означает, что вы платите одинаково за горячие данные, к которым обращаетесь каждую секунду, и за архивы пятилетней давности. Для любого серьезного проекта это прямой путь к неоправданным расходам.

Лимит загрузки в 5 GB за раз — это несерьезно. AWS S3 поддерживает multipart upload для объектов до 5 TB. Без этой функции загрузка больших бэкапов или датасетов для машинного обучения превращается в квест.

CDN (Preview): «Мы вам перезвоним»

CDN в MWS — это отдельная история. Сервис для быстрой доставки контента существует, но доступ к нему — только по заявке. Я заявку оставлять не стал. В эпоху, когда CloudFlare, Fastly, AWS CloudFront и даже Yandex CDN доступны в несколько кликов, ждать несколько дней одобрения для тестирования CDN — это перебор.

Certificate Manager: хранилка, а не менеджер

Сервис позиционируется как управление TLS/SSL-сертификатами, но по факту это просто хранилище. Можно загрузить сертификат, цепочку промежуточных сертификатов и приватный ключ в виде файла или текста. Всё.

Автоматический выпуск сертификатов через Let's Encrypt? Нет. Автообновление? Нет. DNS или HTTP валидация? Нет. Для сравнения: AWS Certificate Manager выпускает и автоматически обновляет сертификаты бесплатно. Google Cloud тоже. Yandex Certificate Manager поддерживает Let's Encrypt. А здесь — загрузил руками и следи за сроком действия сам.

Управление доступом (IAM): Основа основ, но…

«Три базовые роли — viewer, editor, admin — и всё? Это IAM для детского сада, а не для enterprise. В нашей компании 15 команд, у каждой свои проекты, свои окружения, свои требования к доступу. Мне нужны роли типа «может создавать ВМ только в конкретной подсети», «может читать логи, но не может изменять конфигурацию», «может управлять только своими ресурсами с определенными тегами». В AWS IAM я мог бы написать policy с точностью до конкретного API-вызова в определенное время суток с определенного IP. В Google Cloud есть custom roles с сотнями permissions. А здесь — каменный век RBAC» , — ИБ-инженер, ИТ-компания

Чего критически не хватает

Но база — это только начало. В AWS IAM можно создавать детальные JSON-политики с условиями, временными ограничениями, IP-фильтрами. Есть AWS Organizations для управления множеством аккаунтов, Service Control Policies для ограничений на уровне организации, временные credentials через STS, федерация через SAML/OIDC.

Google Cloud IAM предоставляет условные политики на языке CEL, Workload Identity Federation для безопасной интеграции с внешними системами, детальные роли на уровне ресурсов.

Yandex Cloud IAM имеет гибкую систему ролей с привязкой к каталогам и ресурсам, интеграцию с федеративными провайдерами, поддержку внешних IdP.

Вывод по IAM: Без гибких политик, условных правил, временных токенов и федерации это не готовая система управления доступом, а заготовка. Любая компания с требованиями к compliance просто не сможет использовать такую систему.

Artifact Registry: Docker-хранилище без security scanning

Реестр Docker-образов работает, и на том спасибо. Можно загружать образы, скачивать их, управлять доступом. Но отсутствие сканирования на уязвимости в 2025 году — это просто неприлично.

AWS ECR автоматически сканирует образы на уязвимости с помощью Amazon Inspector. Google Cloud Artifact Registry использует Container Analysis для поиска CVE. Yandex Container Registry тоже умеет сканировать образы. Даже Harbor, бесплатный open source registry, имеет встроенный сканер Trivy.

В MWS вы загружаете образ и молитесь, чтобы там не было критических уязвимостей. Для production-использования это неприемлемый риск.

Virtual Infrastructure: VMware спасает ситуацию

После парада preview-сервисов раздел Virtual Infrastructure выглядит как оазис в пустыне. Здесь предлагается полноценная инфраструктура VMware через интерфейс vCloud Director — проверенное годами enterprise-решение.

Сразу видна разница в подходе: есть прозрачный калькулятор стоимости, который показывает, сколько будет стоить виртуальный ЦОД с выбранными характеристиками. Доступны локации в Санкт-Петербурге (1 ЦОД), Москве (4 ЦОДа) и Новосибирске (1 ЦОД) — в целом неплохое географическое покрытие.

Модель оплаты гибкая: можно платить по созданным виртуальным машинам или по размеру виртуального дата-центра. Железо современное — AMD EPYC 9354 с частотой 3.25 ГГц, конфигурации от 1 до 80 vCPU и от 1 до 160 GB RAM.

Дисковая подсистема с градацией

В отличие от Compute, здесь есть нормальная градация дисков: Basic, Fast, Ultra, Ultra Plus с размерами от 50 до 4000 GB. Можно выбрать пропускную способность канала: 100, 250, 500 или 1000 Мбит/с. Это уже похоже на реальную облачную платформу.

После развертывания ЦОД вы переходите в отдельную панель vCloud Director через OIDC-аутентификацию. OIDC (OpenID Connect) — это современный протокол аутентификации поверх OAuth 2.0, позволяющий интегрироваться с корпоративными системами единого входа. Технически грамотное решение, но вам по сути придется работать в двух разных панелях.

Альтернатив VMware нет — про OpenStack или обычный KVM можно забыть. Для многих компаний, уже использующих VMware, это будет плюсом. Для тех, кто хочет альтернативы — минусом.

Биллинг: есть детализация, нет аналитики

Система биллинга предоставляет базовую детализацию по проектам, сервисам и позициям. Можно фильтровать по периодам, группировать по дням, месяцам и кварталам. Видна базовая стоимость, скидки и итоговая сумма к оплате. По позициям расписывается стоимость доступа в интернет, виртуальных процессоров, памяти, дисков, запросов к объектному хранилищу.

Это неплохо для начала, но до уровня AWS Cost Explorer или даже Yandex Cloud Billing здесь далеко. Нет прогнозирования расходов, нет алертов по превышению бюджета, нет рекомендаций по оптимизации, нет тегирования ресурсов для распределения затрат по проектам или департаментам. Для enterprise-компаний с требованиями к FinOps это критические недостатки.

Выводы

MWS Cloud Platform в текущем состоянии — это гибрид из облачных сервисов и вполне зрелого VMware-решения. Если вам нужен управляемый VMware vCloud Director с понятными ценами и локальным размещением — это может быть вашим вариантом. Если вы ищете полноценную облачную платформу уровня AWS, GCP или даже Yandex Cloud — как говорится, есть вопросики.

Отдельного упоминания заслуживает разрыв между новостями компании о запуске 1C на базе платформы и LLM. 

В личном кабинете платформы этого нет. Вообще. Ни намека на GPU-инстансы для ML-задач, ни managed-сервисов для обучения моделей, ни даже простого inference API для готовых LLM. Про интеграцию с 1С — вообще молчу. Создается ощущение, что кто-то в MWS решил: «Давайте сначала расскажем всем, какие мы инновационные, а потом как-нибудь это сделаем». 

Что реально работает и заслуживает похвалы:

• VMware Virtual Infrastructure с прозрачным ценообразованием и хорошим выбором конфигураций

• Базовое объектное хранилище с версионированием и WORM

• OIDC-аутентификация для корпоративной интеграции

• Географическое распределение ЦОДов по России

Что критически не хватает для production:

• Self-service регистрация и мгновенный доступ

• SLA на все сервисы

• Полноценный VPC с NAT, VPN, пирингами и нормальной маршрутизацией

• Выбор операционных систем и marketplace

• Гибкость в конфигурации дисков и производительности

• Классы хранения в Object Storage

• Автоматизация в Certificate Manager

• Security scanning в Artifact Registry

• Продвинутые IAM-политики и федерация

• FinOps-инструменты в биллинге

Сейчас MWS Cloud Platform — это хорошая витрина с VMware и набором демо-сервисов вокруг. Маскировать «базовый open source-стек» под «инновации» можно, но инженеров не обманешь. Когда появятся недостающие компоненты, нормальный self-service и SLA на все сервисы — с удовольствием вернусь и обновлю обзор. Пока же это скорее technology preview, чем готовая к использованию платформа.