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

Очень часто в проектах необходимо использовать передачу сообщений между компонентами распределенной системы по определенным правилам. И перед разработчиком встает вопрос — какой инструмент наиболее эффективно можно использовать для этого? И сегодня мы рассмотрим брокер сообщений, который позволяет это делать «прямо из коробки» и это будет RabbitMQ.

RabbitMQ — это популярный брокер сообщений, который реализует стандарт AMQP и который позволяет эффективно управлять коммуникацией между сервисами через очереди. И в этой статье мы разберем основные типы обменников (exchange): Direct, Topic, Headers и Fanout, которые напрямую участвуют в процессе маршрутизации, а также приведем примеры их настройки в Spring Boot.

За 10 лет, что существует Serverless‑подход, бессерверные функции стали для многих разработчиков чем‑то привычным и удобным. С их помощью можно быстро написать несколько строк кода для реализации конкретной бизнес‑логики и задеплоить, не думая о развёртывании, настройке и обслуживании инфраструктуры. Нужный код запустится автоматически при срабатывании триггера, как это принято в событийно‑ориентированной архитектуре. Но если таких функций в приложении потребуется очень много — что поможет сохранить нужную скорость работы и другие преимущества Serverless?

Меня зовут Сергей Ненашев, последний год я разрабатываю в Yandex Cloud сервис бессерверных функций Cloud Functions. В нашем облаке с ним можно запускать код в виде функции без создания и обслуживания виртуальных машин.

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

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

Как мы построили DevOps в локальном облаке без AWS и managed-сервисов: GitLab CI, Kubernetes, PostgreSQL, мониторинг на Prometheus и Grafana. 10 000 TPS в пике, 12 минут на деплой, 2 минуты на восстановление — и всё это в проде.

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

Привет! Сегодня поговорим о Nextcloud. Вы наверняка слышали об этом мощном решении для хранения, совместной работы и обмена файлами. В статье разберём, как развернуть Nextcloud в высокодоступной конфигурации с балансировщиком нагрузки, реплицируемой базой данных, отказоустойчивым хранилищем и полнотекстовым поиском.

Привет! Я Андрей Квапил (или kvaps) и в этой статье я опишу наш путь организации доставки приложений в Kubernetes, объясню недостатки классического GitOps в локальной разработке и покажу, как новая утилита cozypkg решает эти проблемы. Материал рассчитан на разработчиков, знакомых с Helm и Flux.

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

Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.

Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной.

Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?

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

Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.

Мы сделали визуальную карту, на которой можно не просто увидеть ресурсы, но и настроить их расположение как в реальной жизни: сгруппировать, пояснить, добавить связи и комментарии. Это не просто картинка — это инструмент, который помогает понимать, как всё устроено, и быстрее находить проблемы.

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

За последний год AI встраивается буквально во всё. Ещё недавно его приходилось отдельно запускать. Теперь он встроен везде. Даже те, кто не ставил себе отдельные плагины, уже взаимодействуют с AI каждый день. Он вшит в SaaS-продукты и работает в фоне. Иногда так, что пользователь об этом вообще не знает.

Вот здесь и появляется первый важный вопрос: Что происходит с твоими данными?

Только один телескоп LSST за ночь может собрать более 15 ТБ данных — это как 30 тысяч фильмов в HD. Без ИИ астрономы просто тонут в научных данных. Студенты МФТИ придумали решение: их ML-система «Страж» может ускорить поиск новых объектов в 5 раз — и с точностью до 98%. 

На днях АиФ, ТАСС и другие СМИ опубликовали новости о «Страже», но только мы знаем, как все начиналось, как работает решение «под капотом» и почему проект поддержал Yandex Cloud. Об этом и рассказываем в статье.

Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков.

Привет! Продолжаем понемногу рассказывать о том, как мы строим собственные ЦОД. Под катом — коротко о том, что мы сделали за минувший месяц.

Привет! Меня зовут Андрей Квапил (или kvaps). Я CEO в Ænix, и мы делаем Open Source-платформу и фреймворк Cozystack, с которым очень удобно строить облака.

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

Одна из самых популярных услуг на рынке хостинга — аренда виртуального дата-центра (ВДЦ). ВДЦ представляет собой полноценную замену физической инфраструктуре, предоставляя клиенту сервис-провайдера все необходимые компоненты: вычислительные мощности, сетевые ресурсы и ресурсы для хранения данных. В отличие от традиционного ЦОД он не требует капитальных затрат на оборудование и может масштабироваться по требованию.

В версии BILLmanager 6.118 мы добавили обработчик для VMware vCloud Director (NSX-T). Эта интеграция позволяет клиентам заказывать и управлять виртуальными дата-центрами на базе VMware vCloud Director 10.6.

Теперь с помощью BILLmanager клиенты могут заказывать услуги виртуального дата-центра и управлять ими, управлять объектами внутри ВДЦ — ВМ, сетями, маршрутизаторами, IP-адресами и другими ресурсами, настраивать тарификацию.

Интеграция состоит из двух этапов: настройка обработчика услуг и создание тарифов. В этой статье подробно рассказали, как это сделать.

Привет! Меня зовут Алексей Баранов, я руковожу направлением Data Storage Systems в облаке MWS Cloud Platform. Мы начинаем серию статей, в которой расскажем, как устроены наши системы хранения, почему мы их делаем так и почему именно такие.

В этой статье расскажу, как мы подошли к выбору технологий для object storage новой облачной платформы. Обсудим плюсы и минусы популярных на рынке решений вроде Ceph RGW, какие требования мы предъявляли к системе, и какая архитектура в итоге получилась.

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

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

Безусловно, сценариев использования VMmanager намного больше, однако сегодня речь пойдет о виртуальных сетях на базе VxLAN — технологии, которая обеспечивает создание виртуальных сред, изолированных друг от друга и физического оборудования.

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

Привет! Меня зовут Игорь Михалюк, я Tech Lead команды IAM в MWS Сloud Platform. Сегодня поговорим, как мы делаем Identity and Access Management для нашего нового публичного облака.

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

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

Грамотная стратегия мониторинга решает три ключевые проблемы: