В сентябре2025 на просторах Хабра была опубликована статья «Облачные сервисы на Tcl/Tk». Спустя полчаса после опубликования появился комментарий от CloudTk-JeffSmith , который приятно удивил меня:
Статья носит юмористический характер. Автор не пропагандирует азартные игры. Слово "казино" используется исключительно как метафора случайности процессов генерации.
На первый взгляд может показаться, что игрок у рулетки и хипстер с подпиской на Midjourney - это разные люди. Однако: оба они молятся Богу Рандома, оба тратят деньги и оба надеются, что в этот раз "выпадет красиво".
Возьмём типичную IT-компанию со штатом в 100 человек. Как думаете, сколько учётных записей существует в их облачной инфраструктуре? 150? 200?
В действительности — около 2000.
И самое удивительное, что только десятая часть из них принадлежит реальным людям. Остальные — это боты, сервисные аккаунты, API-ключи, агенты ИИ, токены CI/CD систем. Они работают 24/7, имеют доступ к критичным данным и почти никогда не попадают в фокус отделов безопасности.
Пока CISO требует от сотрудников двухфакторку и регулярную смену паролей, в том же облаке живёт сервисный токен с правами администратора, созданный три года назад разработчиком, который давно уволился. Никто о нём не помнит. Но он продолжает «работать».
Несколько цифр:
2025 год стал для компании МУЛЬТИФАКТОР временем комплексных изменений. Вместо точечных доработок мы сосредоточились на развитии продуктовой системы в целом: полностью переработали логику аутентификации и запустили новый облачный сервис для внешнего мониторинга доступности.
В этой статье мы собрали ключевые обновления продуктов МУЛЬТИФАКТОР за год.
Мы в Геоинтеллекте любим геоданные и геоаналитику. Часто миксуем технологии. Вот, например, мы попробовали генерировать графики 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-инфраструктуру и переработали подходы к безопасности, чтобы итоговые изменения были ощутимы именно для пользователей.
Ниже — наши итоги года по ключевым направлениям: платформе, продуктам, инфраструктуре, безопасности и рынку. А еще — немного про планы, но обо всем по порядку.
