Облачные сервисы *

Мы в Геоинтеллекте любим геоданные и геоаналитику. Часто миксуем технологии. Вот, например, мы попробовали генерировать графики BI системы DataLens внутри платформы для Геоаналитики “Геоинтеллект”. Что из этого вышло, посмотрим на реальном кейсе, которая выполняла наша сотрудница. 

Задача

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

Привет, Хабр! Если представить ваш высоконагруженный сайт в виде оркестра, а пользователей — в виде слушателей по всему миру (Москва, Владивосток, Берлин), то ситуация, когда все «музыканты» играют в одном ЦОДе, напоминает концерт, который кто-то слушает вживую, а кто-то — по плохой телефонной линии. Пинг растёт, пакеты теряются, трафик упирается в потолок возможностей ЦОДа, и в случае его отказа наступает тишина.

Решение — вынести «сцены» ближе к «зрителям»: построить геораспределённую инфраструктуру и научиться направлять пользователей на ближайший живой узел. В этом материале, основанном на моём докладе для Saint HighLoad++ 2025, мы разберём, как комбинировать BGP Anycast, DNS и HTTP-балансировку, чтобы снизить RTT, переживать падение целых площадок и равномерно «кормить» мир контентом. 

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

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

Aspire отлично закрывает локальный цикл разработки, но как только дело доходит до AWS, начинается вечная развилка: «или пишем отдельный IaC и живём с двойной правдой», или «деплоим руками и платим временем и деньгами». В этой статье показан рабочий компромисс: один Aspire Host, который в локальном режиме поднимает LocalStack и контейнеры, а в publish-режиме передаёт управление AWS CDK и разворачивает полноценный serverless-стек (VPC, Aurora, DynamoDB, Lambda, API Gateway) — оставаясь в C# и без зоопарка YAML-файлов.

Можно получить идеальные 60 FPS и зелёные метрики — и всё равно услышать от пользователей «невозможно работать». Потому что мозг прощает “мыло”, но не прощает задержку: курсор начинает жить своей жизнью, клики “не туда”, печать с запозданием.

В этой части разбираю Input Channel, Cursor Channel и round-trip latency: почему SPICE таскает курсор отдельным каналом, откуда берётся эффект «курсор на резинке», чем отличается server mouse mode от client mouse mode, и почему без usb-tablet / vdagent всё быстро превращается в квест.

Третья статья серии — про то, что реально определяет UX в VDI: не картинка, а отклик.

Представьте себе такую картину: пятничным вечером вы нажимаете кнопку воспроизведения видео на Netflix. Не проходит и нескольких секунд, как в ответ на это в недрах системы оживают сотни контейнеров. Обеспечение эффективной работы большого количества контейнеров в Netflix — это один из краеугольных камней обеспечения качественного потокового видео для миллионов пользователей со всего мира. Для того чтобы обеспечить высокую скорость реакции системы таких масштабов, мы модернизировали нашу среду выполнения контейнеров (контейнерный рантайм, container runtime), но, сделав это, мы столкнулись с неприятной неожиданностью, сдерживающей рост нашей системы. Это — архитектура процессоров.

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

Мы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.

Речь не про «сгенерировать YAML» или «написать Helm-чарт», а про полноценную операцию:

Мне довольно часто приходится работать с только что созданными VPS — будь то развёртывание нового проекта, подготовка тестового окружения или эксперименты с инфраструктурой. Практически каждый такой сервер после создания находится в «сыром» состоянии и требует базовой первичной настройки.

Как правило, эта настройка включает:

Парадокс: SPICE отлично справляется с рабочим столом, но спотыкается на видео. Статичный документ — чёткий, быстрый, экономный по трафику. Включили ролик на YouTube — и всё поплыло.

Display Channel — это два разных мира в одном канале. Image Mode: независимое сжатие каждой изменившейся области, умное кэширование, глобальный словарь для повторяющихся элементов интерфейса. Stream Mode: попытка поймать видеопоток и пережать его на лету.

Детекция видео по косвенным признакам. MJPEG из 2009 года как дефолт. GStreamer как путь к H.264. И вечный компромисс между «красиво» и «быстро».

Разбираю анатомию Display Channel — от QXL-команд до финального рендеринга. Вторая статья серии.

В 2007 году инженеры Qumranet приняли решение, которое определило судьбу протокола на следующие 17 лет: только TCP, никакого UDP. Простота победила производительность.

SPICE — протокол, который доставляет рабочий стол от виртуальной машины до пользователя. Открытый, бесплатный, дефолтный для всего Linux VDI. И при этом удивительно мало кто понимает, как он устроен внутри.

Почему курсор передаётся отдельным каналом? Зачем нужен глобальный словарь в GLZ? Как современные композитные менеджеры сломали красивую идею 2D-команд QXL?

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

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

Год назад мы начали амбициозный проект — строительство собственных дата-центров в Московской области. Сегодня подводим итоги: что обещали, что построили и куда движемся дальше.

Мы запустили h3llo cloud — IaaS/PaaS‑облако на современном железе и собственной платформе. Идея простая: вы запускаете инфраструктуру, а не проходите квест «найди нужную галочку и дождись согласования».

Если вам нужна мощность и гибкость облака, но хочется, чтобы всё было понятно, прозрачно и под вашим контролем — вы по адресу. На слайдах в галерее покажем, что вы получаете на старте и как быстро потестить h3llo cloud.

В целом для запуска домашней лаборатории достаточно взять любой Linux-дистрибутив по нраву. Понадобилось поработать с NAS-сервером — выбрал Unraid; захотелось чего-то для встраиваемых систем — обратился к Alpine. Селф-хостинг позволяет опробовать разное, даже экспериментальное программное обеспечение. Сегодня мы в Beeline Cloud рассмотрим несколько интересных альтернатив.

Мы строили-строили и наконец-то построили последнее коммерческое облако в РФ.

Почему последнее — потому что теперь конкурировать с крупными корпоратами из-за кучи ограничений, экономики, высокого порога входа по бюрократии и теперь ещё цене железа (из-за улетевшей в космос по цене оперативки) почти нереально. Возможно, года через 3–4 появится ещё кто-то, кто сможет бросить вызов Яндексу, Сберу, Селектелу и ещё паре игроков, но пока тут только мы.

И мы ненавидим корпоративный подход.

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

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

Но, возможно, вам всё это не очень интересно, а интересна халява. Поэтому перехожу сразу к ней.

Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.

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

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

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

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

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

Итак, вы назначили на сервер оба IP-адреса, корректно прописали настройки сети, но работает только один канал связи. Запросы уходят через один интернет-канал, хотя активны оба. 

Дело в том, что в Linux-системах может быть только один маршрут по умолчанию (default gateway). Если у сервера несколько внешних интерфейсов с разными подсетями, то ответы на запросы, пришедшие через второй интерфейс, сервер попытается отправить через основной шлюз таблицы маршрутов. Это приведет к асимметричной маршрутизации и отбрасыванию пакетов. 

Привет, Хабр! Меня зовут Саломея Яковлева, я специалист продуктовой поддержки в Selectel. В этой статье мы разберемся, как избежать такой проблемы с помощью механизма policy-based routing (PBR) на базе iproute2: создадим отдельные таблицы маршрутов и правила, направляющие трафик через правильный шлюз. 

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

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

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