Разработка публичных облаков *

Добрый день! Меня зовут Роман Помазанов, я руковожу командой Global Network Fabric в MWS Cloud Platform. Сегодня я хочу рассказать о  фундаменте, который обычно остаётся в тени, когда говорят об облачных платформах. Речь пойдёт не о виртуальных машинах, контейнерах или системах хранения, а о том, что заставляет всю эту сложную машинерию работать как единое целое, — о сети.

Если представить облако как живой организм, то сеть — это его кровеносная система. Это та самая инфраструктура, которая связывает вычислительные ресурсы, системы хранения, сервисы безопасности и подключает всё это к внешнему миру — к интернету. Без её бесперебойной и предсказуемой работы ни один сервис, ни одна виртуальная машина просто не смогут функционировать. Хотя я, конечно, лукавлю — функционировать-то сможет, но только диск будет в read-only режиме, он же сетевой :) 

В этой статье я подробно расскажу об Underlay-сети — том самом физическом фундаменте нового облака MWS. Мы разберём, почему мы приняли стратегическое решение спроектировать её с чистого листа, отказавшись от следования традиционным, зачастую излишне сложным вендорским подходам. Поговорим о принципах, которые легли в основу архитектуры: простоте, отказоустойчивости и масштабируемости. И наконец, заглянем «под капот»: посмотрим на leaf-spine фабрику, на протоколы BGP и IPv6, которые стали её нервной системой, и на то, как мы управляем этой сложной распределённой системой с помощью автоматизации и мониторинга.

Этот материал — попытка объяснить сложные инженерные решения без излишнего упрощения, но и без «магии». Важно помнить, что надёжное облако начинается с правильно спроектированной сети. Ок, давайте начнём с самого главного вопроса: почему мы не стали копировать проверенную на практике сетевую архитектуру, а пошли своим путём?

Привет! Меня зовут Дима Веселов, уже три года я развиваю облачные технологии в команде Evolution App Services как техлид. Мой путь начинался с классической backend-разработки на Python, но со временем я все глубже погружался в то, как работает инфраструктура, сетевые протоколы, Kubernetes. Сегодня я хочу рассказать, как eBPF буквально в два присеста позволяет делать то, что раньше требовало невероятных усилий.

Кому будет полезен этот материал? В первую очередь разработчикам PaaS-платформ, DevOps-инженерам и архитекторам, которым тесно в рамках классического HTTP-only serverless. Расскажу, как обеспечить масштабирование с нуля для любых TCP-приложений без переписывания их кода.

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

Некоторое время назад я заметил, что #архитектура создаваемых решений сама собой структурируетcя в конвейер-пайплайн, например что-то вроде. Термин, кстати, идёт от БЭСМ-6.

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

Сейчас я переживаю бурный месяц в клауде. И с клаудами связан один интересный вопрос. Ресурсы в веб-консоли управления собраны по типам: базы, контейнеры, функции, джобы/флоу, бакеты/их фолдеры, и т. п. И возникает проблема навигации среди них. Целый день щёлкаешь по табочкам, ищешь объекты по спискам… (Кстати, надо будет перечитать что-нибудь вроде этого).

В сентябре2025 на просторах Хабра была опубликована статья «Облачные сервисы на Tcl/Tk». Спустя полчаса после опубликования появился комментарий от CloudTk-JeffSmith  , который приятно удивил меня:

Workflow Automation be like

Сегодня пост для тех, кто не наигрался в пошаговые стратегии: о Yandex Cloud Serverless Integration Workflows. Нетрудно догадаться, что это представитель обширнейшего поля Workflow Automation Tools, eg OSS: Apache Airflow/Hop, n8n to name a few. Но YC Wokflows не Open Source, конечно же. Окей, ближайший аналог, скажем, AWS Step Functions.

Одна из его характерных особенностей — использование JQ как одного из краеугольных камней. Прямо скажем, не Yandex's vibe 🚲 ⛔. Не могу сказать, что было легко с JQ, нахлынули какие-то воспоминания об XSLT (не кликайте, не надо!). В целом, конечно, работает, но у любой абстракции существует критическая точка взаимодействия с реальным миром: по отдельности $global, Foreach и сложные шаги, например, работают замечательно, но их комбинация пока является крайним случаем, где всё не совсем очевидно.

Рассмотрим пример простого вызова языковой модели:

Зачем это обывателю?

Кейсов на самом деле не мало, как минимум это бесплатно и дает возможность запускать AI без облака, чтобы ничего не отправлялось в интернет (приватность, скорость), 

ну и на случай если упадет интернет как например у нас было в Испании когда все электричество пропало, хорошо бы иметь умного ИИ с которым можно будет пообщаться)

Еще можно использовать как офлайн переводчик или объяснялку без интернета, помощника по учебе и изучения чего либо.

Привет, Хабр! На связи команда Рег.облака. Для нас 2025 год стал одновременно годом разделения и большой сборки. Облако окончательно перестало быть просто еще одним сервисом в линейке крупной технологической компании и сформировалось как самостоятельная экосистема — с собственным сайтом и доменом, витриной продуктов, командой, продуктовой стратегией и набором проектов.

Если перефразировать известную фразу из одного супергеройского фильма, в 2025 году к нам действительно пришла «большая сила» — в виде новых возможностей, масштабов и ожиданий со стороны рынка. Но вместе с этим пришла и большая ответственность перед клиентами. Мы постарались использовать этот ресурс взвешенно: вложились в развитие облачной платформы, расширили линейку сервисов, усилили IT-инфраструктуру и переработали подходы к безопасности, чтобы итоговые изменения были ощутимы именно для пользователей. 

Ниже — наши итоги года по ключевым направлениям: платформе, продуктам, инфраструктуре, безопасности и рынку. А еще — немного про планы, но обо всем по порядку. 

Стартапы гордятся своей свободой и отсутствием жёстких правил. В свою очередь, чем крупнее становится компания, тем больше она нуждается в корпоративной культуре и правилах работы. Из первичного бульона хаоса, устных договорённостей и личных связей неизбежно формируются рельсы рабочих процессов в виде событийно-ролевой модели и рабочих артефактов. Другими словами, субъекты и объекты трудовых будней компании. 

Меня зовут Евгений Иванов, я Agile Cluster Lead кластера Облачные технологии в компании MWS Cloud — команды, которая создала MWS Cloud Platform. И в этой статье я расскажу, почему мы считаем наш кластер анклавом процессных практик и какие плюшки и сложности мы с этого имеем. На тему наших процессов мой коллега Саша Стерлигов уже написал подробную статью. Почитайте.

Всем привет. Я — Дмитрий Шапошников, Tech Lead в команде Object Storage в MWS Cloud Platform. Сегодня мы поговорим о том, как устроено наше объектное хранилище.

В этой статье я объясню, что такое Object Storage, и поделюсь нашим опытом создания сервиса. Расскажу о преимуществах и недостатках работы с Ceph, на котором базировалась предыдущая версия нашего объектника, и подробно опишу архитектуру нового сервиса Object Storage, его масштабируемость и надёжность.

В предыдущей статье мы говорили о текстовом поиске, а в сегодняшней я расскажу о векторном (семантическом) поиске.

Итак, если мы используем OpenSearch, в Yandex Cloud представляется логичным использовать модели вложений этого же облака.

Этот код можно запустить как Python Cloud Function. Написан он исходя из того, что в каталоге сервисного аккаунта, под которым запускается функция, доступна модель вложений (embedding). Детали подключения к кластеру описаны в документации.

Рассмотрим один крайний случай: если мы подключаемся, указывая FQDN DATA-узлов, у которых не включен публичный доступ, то функция должна запускаться в сети кластера OpenSearch, иначе они будут недоступны. Альтернативные варианты: подключаться через «Особый FQDN» или узел DASHBOARD с публичным доступом.   

Код создаёт тестовый индекс с текстовым и векторным полем, явно вызывает embedding model через REST API, создавая векторы вложений для документов и запроса, и выполняет векторный поиск, демонстрируя способ интеграции. Обратите внимание на способ выбора разных моделей для документов и запросов.  

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

Сегодня предлагаю обсудить Managed OpenSearch Yandex Cloud. Поговорим о том, как автоматизировать управление кластером, чтобы сократить расходы на разработку, и как улучшить качество поиска на русском языке, используя доступные в сервисе инструменты морфологии.

Привет! Меня зовут Александр, я ведущий разработчик VK Tech в команде, которая занимается сервисом Kubernetes в нашем публичном облаке. Все чаще провайдеры отказываются от модели, где пользователь получает полный контроль над кластером и всеми управляющими компонентами, в пользу управляемых (managed) решений. В такой архитектуре вы остаетесь администратором внутри своего кластера — создаете неймспейсы, деплоите приложения, настраиваете RBAC, — но инфраструктура, control plane и системные компоненты полностью управляются провайдером и скрыты от глаз пользователя. 

В начале декабря наша команда выпустила новый сервис managed-k8s, в котором как раз реализован такой подход. Я расскажу вам про то, как выглядит наш Kubernetes с точки зрения архитектуры и каким образом Gatekeeper делает архитектуру безопасной.

В этом посте хочется поделиться 20-летним личным опытом в тестировании и приходу к частичному отказу от тестовой модели с использованием тестовых кейсов. Переход был плавным. Не планировала загружать статью сложными метриками и цифрами, но хотела показать постепенную эволюцию сквозь призму личного опыта в стиле некоторого ревью. Для многих мой опыт наверняка окажется созвучным с их личной практикой, но также допускаю, что есть ситуации, компании или продукты, где стоит использовать классические подходы. Так или иначе, кто-то подкрепит свои догадки и сложившиеся подходы, а кому-то будет интересно почитать, как оно все происходит у других, и почему они выбрали именно такой подход.

Привет! Я Эмиль Ибрагимов — старший Go-разработчик команды Development Platform в MWS Cloud Platform. В этой статье расскажу о том, как мы создали облачную CLI на Go и что из этого вышло. Спойлер: получилось реализовать утилиту и поддерживать её силами небольшой команды внутри Development Platform.

Привет, Хабр! На связи команда облачной платформы MWS Cloud Platform. Мы разрабатывали облако с нуля с 2024 года и теперь готовы анонсировать выход платформы в паблик. Сегодня мы открываем доступ для всех желающих: сервисы IaaS готовы к коммерческой эксплуатации, ещё появились новые PaaS-сервисы в режиме превью.

Если интересно скорее посмотреть, что у нас вышло — приходите на сайт платформы. В честь запуска раздаём приветственные гранты до 10 000 рублей — хорошая возможность протестировать новое облако.

А если хочется подробнее почитать, с каким набором функциональности мы запустились и почему, о наших планах на будущее — статья как раз об этом.

Привет! Меня зовут Юрий Гуз, я ведущий разработчик команды IAM в MWS Cloud Platform. Мы продолжаем цикл статей о том, как устроен IAM в нашем облаке. Сегодня поговорим о технологии, которая стирает границы между вашей корпоративной IT-инфраструктурой и MWS, — о федерации доступов или просто федерации.

Мы уже рассказывали в статье, как мы делаем IAM для облака MWS. И описали там один из способов зайти в наше облако — использование MTS ID. Способ надёжный и удобный, если MTS ID у вас, конечно, есть. А что, если ваш провайдер удостоверений — это ваш корпоративный Active Directory, Google Workspace или Keycloak? Вам ведь не хочется заводить каждому сотруднику ещё один аккаунт, плодить лишние пароли и ломать уже выстроенные процессы с двухфакторной аутентификацией и ролевой моделью.

На этот случай у нас есть ответ — наша новая фича «Федерация». Она позволяет сотрудникам заходить в MWS с помощью их привычных рабочих учётных записей. Давайте разберёмся, как это работает и зачем нужно.

Привет, Хабр. Меня зовут Дмитрий Куколев. Я руководитель VK SOC. В этой статье я расскажу о мерах обеспечения надежности и защиты VK Cloud, о собственных ИБ-продуктах и новых сервисах безопасности для пользователей нашего облака.

Привет, Хабр! На связи Тимур Парфёнов, директор департамента эксплуатации Рунити. Сегодня поговорим о Kubernetes. Точнее — о том, почему он стал стандартом де-факто для оркестрации контейнеров и зачем большинству проектов нужен Kubernetes как сервис (KaaS). Статья будет особенно интересна тем, кто еще не знаком с K8s или только планирует его использовать в разработке. Ну, а старичков приглашаю тоже — присоединиться к обсуждению болей и радостей этой технологии.

За более чем 10 лет работы в облачной индустрии я видел немало историй, когда команды вкладывали месяцы и даже годы в разработку продукта, но в итоге все упиралось не в технологии, а в цену. Продукт может быть удобным, быстрым, технологически безупречным. Но если компания не понимает, сколько и за что готов платить клиент, то даже самая инновационная идея рискует превратиться в игрушку для амбиций команды или продакта, так и не найдя своего места на рынке.

Привет, Хабр! С вами Александр Гришин, руководитель по развитию продуктов хранения данных Selectel: облачных баз данных и S3. Сегодня мы разберем пять ключевых принципов из книги Мадхавана Рамануджама и Георга Таке «Monetizing Innovation», но не ограничимся теорией. Каждый принцип я постараюсь показать на конкретных примерах из AWS, Google Cloud, MongoDB, Elastic/OpenSearch. Где это возможно, добавлю наблюдения из практики и цифры.

Эта статья будет полезна прежде всего тем продакт-менеджерам и продакт-оунерам которые не ограничивают свой мир крутыми фичами из бэклога. Тем, кто хочет понять, как превратить технологию в бизнес, и так или иначе сталкивается с монетизацией в IT.

Привет, Хабр! На связи Евгений Мартынов, CIO Рег.облака. Сегодня мы подключили вторую зону доступности облака в Москве на базе дата-центра «Медведково-2» . И вместе с новым запуском провели значительный апгрейд  технологический базы: пересобрали сетевую архитектуру, ушли от большого L2, навели порядок в изоляции трафика и перевели API на BGP-анонсы. В статье расскажу про конкретные решения — как и что мы пробовали, какие процессы отложили и к каким выводам пришли.