devdigest // azure
前往频道在 Telegram
Про Microsoft Azure и облачные технологии. Все каналы проекта: https://t.me/devdigestplatform/163
显示更多1 016
订阅者
无数据24 小时
-27 天
+230 天
帖子存档
1 016
⚡️ Красота уходит в облако: Estée Lauder доверила Microsoft данные 150 стран и 14 000 сотрудников
Косметический гигант The Estée Lauder Companies объявил о стратегическом партнёрстве с Microsoft. Облако Microsoft станет основой для единой платформы данных, которая соединит информацию о потребителях и продуктах всех брендов холдинга, от Clinique и M·A·C до La Mer и Tom Ford, в 150 странах. На этой базе компания хочет точнее подбирать покупателям продукты и предложения, встроить ИИ в цепочку от идеи продукта до производства и автоматизировать рутину в офисах. Доступ к Microsoft Copilot уже получили более 14 000 сотрудников, которые теперь экспериментируют с агентами под конкретные роли. Для Estée Lauder сделка является частью стратегии Beauty Reimagined и должна помочь расширить маржу, а для Microsoft это ещё один крупный клиент из мира люкса и ритейла, далёкого от технологий.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Azure MCP Server 3.0 stable: Terraform, Backup, SRE Agent и ресурсы, которые создаются закрытыми по умолчанию
Вышла стабильная 3.0 Azure MCP Server — после 50 бета-итераций. Запуск: npx -y @azure/mcp@3.0.0 server start --read-only; нужны Node.js LTS, Azure CLI и az login. Клиенты — VS Code, Visual Studio, IntelliJ, Cursor, Claude, GitHub Copilot CLI и self-hosted remote.
Новые тулсеты: Azure Backup (только Recovery Services vault), Resilience Management, SRE Agent (55 команд), Terraform (документация AzureRM/AzAPI, Azure Verified Modules, aztfexport, conftest), Advisor (apply возвращает правила, живые ресурсы не трогает), оптимизация затрат, Monitor с Basic/Auxiliary-таблицами, Cosmos DB с выводом схемы и векторным поиском, IoT Hub, Managed Lustre.
Самое важное — безопасные дефолты для ресурсов, которые создаёт агент: storage account без Shared Key, Event Hubs без local auth, Recovery Services vault без публичной сети, NFS с RootSquash и шифрованием в транзите. Существующие ресурсы при апгрейде не трогаются. Ломающие изменения тоже есть: azmcp resilience → resiliency, конфиг переезжает в appsettings.json под MicrosoftMcp, создание VM требует --image, запросы к MySQL и PostgreSQL помечены как деструктивные и выпадают из read-only, а протокол 2026-07-28 требует заголовки Mcp-Method и Mcp-Name на каждом POST. Старт для точечных команд ускорился примерно на 39%.
Кто уже пускает агента в подписку не в read-only — и что он успел натворить?
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Durable Functions исполняют DAG, который LLM написала один раз: до −93% токенов и −95% задержки
В Azure Functions Hosted Skills появились Dynamic Workflows (public preview): модель один раз описывает план как DAG, а дальше его исполняет Durable Functions — вне цикла вызовов LLM. Пять встроенных инструментов: start_workflow (fire-and-forget, возвращает workflow_id), get_workflow_status, list_workflows, cancel_workflow, terminate_workflow.
Бенчмарк Microsoft на gpt-5.4-mini в Foundry, медианы трёх прогонов: при одном сервисе токенов на 56% меньше, при десяти — на 93.1% (99 097 против 6 781); задержка падает с 38.6–247.1 с до 7.1–12.7 с, то есть на 77–95%; выходных токенов на десяти сервисах 655 вместо 23 621. Все 24 результата совпали с эталоном.
DAG умеет depends_on, подстановку ${node.result.path}, for_each, условие when (только equals и not_equals), retry и таймаут на попытку, continue_on_error, sub_agent и wait на Durable-таймерах от 30 секунд до 24 часов. Лимиты жёсткие: 50 узлов, 10 параллельных задач, 10 активных workflow на сессию, до 5 ретраев, 10 минут на попытку. Инструменты workflow — только Python (@workflow_tool, один dict на вход), MCP-инструменты нужно оборачивать или вызывать через sub agent одного уровня. Нужны Python 3.13+, Core Tools v4, Azurite и бэкенд Azure Storage или Durable Task Scheduler.
Идея правильная: планирование дорого, исполнение плана дёшево, и незачем гонять модель на каждом шаге. Что это меняет для самих агентов — разберём в //data science.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ AWS выпустила инструмент для автоматического переноса .NET-приложений с Azure на AWS
Amazon сделала общедоступной новую функцию AWS Transform, которая сама переписывает .NET-приложения, написанные под Azure, на сервисы AWS. Агент модернизации находит в коде вызовы Azure SDK и заменяет их на эквиваленты из AWS SDK: Azure Functions превращаются в AWS Lambda, Blob Storage в Amazon S3, Queue Storage в Amazon SQS, а Cosmos DB в DynamoDB (пока в превью). Перед запуском разработчик видит отчёт с найденными зависимостями и планом замены и может поправить его вручную. По сути, Amazon предлагает клиентам Microsoft готовый путь миграции, снимая главный барьер на переход в другое облако: необходимость переписывать код руками. Функция уже работает в восьми регионах AWS, включая Франкфурт и Лондон.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ AKS по умолчанию создаёт NAT Gateway StandardV2: zone-redundant, с IPv6 и без даунгрейда
Для новых AKS-кластеров с managed VNet и outboundType managedNATGateway сервис теперь создаёт NAT Gateway SKU StandardV2 — это GA и дефолт в поддерживаемых регионах (список регионов в анонсе не назван). StandardV2 zone-redundant из коробки, поддерживает IPv6 и обещает большую пропускную способность — цифр Microsoft не приводит.
Детали из документации. Дефолт срабатывает с API-версии 2026-06-01; на старых версиях остаётся Standard, а там, где StandardV2 недоступен, AKS молча откатывается на Standard. Превью-версии 2026-01-02 … 2026-05-02 использовали отдельный outboundType managedNATGatewayV2 — его примут ещё около года, потом нужно перейти на managedNATGateway с явным sku. Апгрейд Standard → StandardV2 есть, даунгрейда нет. StandardV2 требует public IP и префиксы того же SKU — адреса Standard несовместимы; модель исходящих адресов (Azure-managed или свои) фиксируется при создании и не переключается. А балансировщик для Service type LoadBalancer по-прежнему хочет Standard IP — планируйте два SKU в одном кластере.
Общие лимиты NAT не менялись: до 64 512 исходящих TCP/UDP-потоков на IP, максимум 16 IP. Цен ни в анонсе, ни в документации нет. Если кластеры создаются из Bicep или Terraform с зафиксированной старой API-версией — ничего не изменится, пока не поднимете версию; это как раз тот случай, когда поднимать стоит осознанно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Microsoft раскрыла архитектуру Maia 300
Microsoft впервые подробно рассказала, как устроен Maia 300, её ИИ-ускоритель третьего поколения, который будет обслуживать Copilot, GitHub Copilot и Foundry. Чип собран из нескольких чиплетов на TSMC N2P, получил 288 ГБ памяти HBM4 и научился считать в форматах точности ниже 3 бит. Такая архитектура позволит решению от Microsoft обрабатывать больше одновременных запросов и выполнять более масштабные задачи, повышая общую мощность дата-центра. И если прошлые поколения Maia не смогли полноценно заменить системы NVIDIA, то теперь Microsoft планирует масштабировать инфраструктуру Azure с Maia 300 до нескольких гигаватт, начиная с 2027 года, сделав новинки основной платформой для инференса в продуктах и сервисах компании.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ GPT-6 Astra, Sol и Luna пришли в Microsoft Foundry — от $0.10 за миллион токенов
Microsoft Foundry получил сразу три модели GPT-6 под разные задачи: Astra — для сложного reasoning, software engineering и computer use, тратит меньше, но более «дорогих» токенов на сложную работу; Sol — рабочая лошадка для агентов, кодинга и multi-step задач на замену GPT-5.6 Sol; Luna — маленькая и быстрая, под извлечение данных, суммаризацию, роутинг запросов и рутинные обращения, где глубокий reasoning не нужен.
Цены (Global Standard, за миллион токенов): Astra — $10–20 вход / $50–75 выход; Sol — $2–4 / $10–15; Luna — $0.10–0.20 / $0.50–0.75. Доступны в 28 регионах плюс US/EU Data Zones, для части моделей — Provisioned Throughput и Priority Processing.
Смысл в том, чтобы не выбирать модель по цене за токен, а считать cost per task: Luna на рутине может выйти дешевле на порядок, даже если у неё цена за токен не самая низкая на рынке.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Azure Container Apps Sandboxes: изолированная microVM для агента за секунды
У продакшен-агентов другая архитектура, чем у классического запрос-ответ приложения: им нужна отдельная исполняемая среда с ограниченными правами, а не общий пул инфраструктуры, где один взбесившийся агент утягивает за собой всех соседей. Azure Container Apps Sandboxes закрывает именно это: полностью изолированное окружение на hardware-isolated microVM, которое создаётся за секунды и исчезает, как только работа сделана — сильная изоляция и субсекундный старт одновременно, а не то и другое по очереди.
На этой инфраструктуре уже стоят GitHub Copilot, Copilot Studio, Security Copilot, Foundry Agent Service и Azure SRE Agent — в сумме больше миллиона sandbox-запусков в день по всему Microsoft. Из внешних кейсов: у KPMG Digital Gateway одновременно крутится больше 30 000 sandbox'ов для налоговой работы с клиентами, каждый со своей изоляцией данных по конкретному engagement; южноавстралийский EdChat обслуживает 60 000 учеников и 40 000+ сотрудников и благодаря sandbox-модели убрал почти 50 000 строк кода, которые раньше вручную управляли состоянием custom code interpreter'а.
Если пишете агентов на C# через Agent Framework и AG-UI SDK (см. на этой неделе //dot net) — вопрос «куда деть выполнение произвольного кода от агента» здесь уже решён на уровне платформы, а не самодельным Docker-in-Docker.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Application Gateway получил HTTP/3 поверх QUIC — пока в превью
Azure Application Gateway начал поддерживать HTTP/3 поверх QUIC в публичном превью — это следующая версия протокола после HTTP/2, которая переезжает с TCP на UDP.
Главный эффект — более быстрое установление соединения (QUIC совмещает TCP- и TLS-handshake в один round-trip) и меньше задержек на нестабильных сетях: потерянный пакет в HTTP/3 не блокирует остальные потоки внутри соединения, как это происходит в HTTP/2 из-за TCP head-of-line blocking. Для мобильных клиентов и API с частыми короткими запросами разница заметна уже на переключении между Wi-Fi и мобильной сетью — QUIC переживает смену IP без пересоздания соединения.
Включается на уровне listener'а, клиенты без поддержки HTTP/3 продолжают ходить по HTTP/2 — ломать текущий трафик это не должно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Per-disk resiliency в Azure: виртуалка переживает потерю одного data-диска
Azure добавил per-disk resiliency для managed disks, пока public preview в отдельных регионах. Раньше при длительной потере связи виртуальной машины с подключённым диском Azure восстанавливал саму VM после возврата связности. Теперь платформа временно отключает только пострадавший data-диск, а машина и остальные её диски продолжают работать; когда связность возвращается, диск переподключается автоматически.
Это полезно ровно тем нагрузкам, которые честно переживут временное исчезновение одного диска: кластерные приложения, вспомогательные диски, часть контейнерных архитектур. Смысл в том, чтобы уменьшить радиус поражения изолированного сбоя хранилища, а не поднимать всю VM целиком.
Рядом анонсирован Azure Infrastructure Resiliency Manager: он оценивает соответствие нагрузок целям отказоустойчивости на уровне приложения, показывает разрывы и выдаёт рекомендации, а через resiliency agent в Azure Copilot умеет генерировать шаблоны развёртывания. Проверять план восстановления предлагают через Chaos Studio: отказ зоны, failover базы, сбои DNS и Entra под контролем.
Практический вывод один: включать per-disk resiliency стоит только там, где приложение действительно переживёт пропажу диска на время. Для всех остальных это тихое изменение поведения в момент инцидента, о котором лучше узнать заранее.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Azure Connector Namespace хостит MCP-серверы для SRE Agent без своей инфраструктуры
Azure SRE Agent умеет расследовать инциденты и предлагать remediation, но полезен ровно настолько, насколько у него есть доступ к мониторингу, репозиториям и трекеру. Команда Azure SDK показала, как отдать ему инструменты через MCP, не поднимая ни одного контейнера.
Azure Connector Namespace — managed-сервис для хостинга коннекторов и MCP-серверов: деплой, HTTPS, аутентификация, секреты, масштабирование и health-мониторинг на стороне платформы. В каталоге уже есть серверы для Azure SQL, Cosmos DB, GitLab, Jira и PagerDuty; bring-your-own image — в разработке. Пример из поста разворачивается через azd up из sql-server-samples, затем в портале SRE Agent добавляется MCP-коннектор по URI с Managed Identity и scope apihub.azure.com/.default. Сервис в public preview с Build 2026, GA обещают к концу года; регионы пока West Central US, Central US, East Asia и North Europe.
Если у вас уже есть внутренние MCP-серверы для агентов — это самый короткий путь отдать их SRE Agent без отдельного App Service. Подвох в регионах: для EU-данных остаётся только North Europe.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Azure и AWS запустили общий Multicloud Interconnect: приватный канал до 100 Гбит/с
❌ #6691 отклонён
4 / 8
📋 Пост #6685 — Azure — англ: Azure and AWS launch Multicloud Interconnect: private connectivity up to 100 Gbps
⚡️ Azure и AWS запустили общий Multicloud Interconnect: приватный канал до 100 Гбит/с
Microsoft и AWS вместе анонсировали Azure Multicloud Interconnect for AWS — стандартизированную приватную связность между двумя облаками. Заявленная пропускная способность с первого дня GA — до 100 Gbps с динамическим расширением по мере роста нагрузки.
Сервис построен на открытых API-спецификациях сетевой интероперабельности: на стороне AWS это «AWS Interconnect – multicloud», на стороне Microsoft — Azure Multicloud Interconnect. Интеграция с Azure Private Link даёт end-to-end приватный путь между облаками, минуя публичный интернет. В Azure Updates за 31 августа фича значится как Public Preview. Регионы, цены и пошаговая настройка в анонсе не раскрыты — отсылают к Microsoft Learn и отдельному техническому посту.
Редкий случай, когда два гиперскейлера договорились о совместном сетевом сервисе, а не оставили клиента собирать ExpressRoute и Direct Connect через провайдера посередине.
👉🏻 Канал | 💬 Чат | 📕 Каталог
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Две зоны или три: почему «три везде» — это не ответ, а рефлекс
Марк Руссинович с коллегами разобрал самый частый рефлекс в проектировании Azure: на вопрос, сколько availability zones нужно проду, большинство архитекторов отвечает «три». Позиция авторов: это правило большого пальца вместо решения, и стоит оно денег, ёмкости и лишней сложности.
Правильный вопрос не «сколько зон», а «сколько зон нужно каждому компоненту, чтобы пережить потерю одной». Решение принимается покомпонентно, по трём критериям: выдержит ли оставшаяся зона нужное состояние после отказа, зависит ли корректность от третьего домена отказа, и как распределяется резерв ёмкости. Stateless-компоненты и активно-пассивные пары закрываются двумя зонами. Три нужны там, где есть кворум, консенсус или выборы лидера, либо где тройная репликация требуется для заявленной durability. Отдельно подчёркнуто: три реплики не равны трём доменам отказа. Разложите кворумную систему по двум зонам, и потеря зоны с большинством убьёт кворум.
И различие, которое часто смазывают: zone-redundant ресурсы Azure раскладывает сам и сам отвечает за отказоустойчивость, а zonal вы прибиваете к конкретной зоне, и маршрутизация, репликация, детект отказа и восстановление остаются на вас. Если недоступны сразу две зоны в регионе, это уже не задача ворклоада, а disaster recovery.
А у вас сколько зон под прод и почему именно столько?
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ AWS Control Tower против Azure Landing Zone и Google Cloud: сравнение подходов к управлению облаком в 2026
Tech Insider сравнил три эталонные архитектуры для управления мультиаккаунтными облачными средами в 2026 году — AWS Control Tower, Azure Landing Zone на базе акселератора Enterprise-Scale и подход Google Cloud на Organization Policies и Terraform. Ни один из них не берёт плату за лицензию, но реальные счета различаются кардинально. Главный вывод — «бесплатное» управление скрывает стоимость инфраструктуры: минимальный сетевой хаб Azure с Azure Firewall Standard обходится примерно в $913 в месяц ещё до запуска нагрузок, тогда как сопоставимая связка из 10 аккаунтов на AWS стоит около $150–400, а на Google Cloud — $100–300. Автор разбирает и различия в guardrails: у AWS более 750 готовых контролей, Azure делает ставку на композируемые политики через Azure Policy, а Google — на жёсткие Organization Policies плюс детект через Security Command Center. Также сравниваются время развёртывания, интеграция с IaC и структура аккаунтов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ CTO Azure запустил DOOM в Microsoft Paint — 35 FPS и «отмена смерти» по Ctrl+Z
Марк Руссинович, технический директор Microsoft Azure, в свободное время запустил классический DOOM внутри Microsoft Paint и выложил исходный код проекта DoomPaint на GitHub. Проект выдаёт 35 кадров в секунду в разрешении 320×200 или 640×400. Отдельная «фишка» — отмена смерти: по Ctrl+Z можно отматывать кадры назад и, по сути, отыгрывать время после гибели персонажа. Эксперимент продолжает давнюю традицию сообщества запускать DOOM на чём угодно — от тестовых полосок и калькуляторов до кассовых аппаратов и холодильников; теперь в этот список попал и стандартный Paint.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Azure сам проверит безопасность ваших Linux-машин по стандарту CIS
Microsoft добавила в Azure встроенную проверку Linux-серверов на соответствие стандартам безопасности CIS Benchmark — функция уже доступна всем. Она работает в Azure и Azure Arc через Azure Machine Configuration и постоянно сверяет настройки Linux-систем с признанными во всём мире требованиями CIS. Azure сам находит слабые места в конфигурации, показывает отклонения от нужных настроек и готовит отчёты о соответствии через Azure Policy; правила можно настраивать под себя и задавать исключения. Раньше для этого нужны были отдельные инструменты или ручные проверки — теперь всё встроено, и командам безопасности проще навести порядок и подтвердить соответствие требованиям регуляторов сразу на множестве серверов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ AKS без гипервизора: Microsoft запускает Kubernetes прямо на «голом железе»
Microsoft развернула Azure Kubernetes Service напрямую на физическом оборудовании — без слоя гипервизора. Новый вариант объединяет платформу Azure Local Small Form Factor и AKS Arc на Linux и автоматически подключается к Azure Arc для централизованного управления. Отказ от виртуализации отдаёт все ресурсы под рабочие нагрузки, сохраняя привычный опыт Azure — портал, Bicep, политики, мониторинг и GitOps. Как отмечает Томас Маурер, решение создано для периферии — ритейла, производства, полевых объектов, — а также суверенных дата-центров и сценариев, где важна максимальная производительность. Один и тот же Kubernetes и единый интерфейс теперь работают всюду: от облака до края сети.
👉🏻 Канал | 💬 Чат | 📕 Каталог
1 016
⚡️ Databricks переведёт бизнес на Azure и интегрирует Genie с экосистемой Microsoft
Microsoft и Databricks продлили стратегическое партнёрство до 2030-х и углубили интеграцию облачной инфраструктуры и ИИ, чтобы помочь компаниям строить ИИ на основе собственных данных и бизнес-процессов. Databricks переведёт свои ключевые операции на Azure Databricks и расширит использование Arm-инфраструктуры Azure Cobalt, включая новое поколение Cobalt 200 (до 50% выше производительность и шифрование памяти по умолчанию). Ассистент Databricks Genie и Unity AI Gateway получат нативную интеграцию с экосистемой Microsoft — Entra, OneLake, Power BI, Purview, Microsoft 365, Teams и Copilot, что даёт управляемый доступ к данным и ИИ прямо в рабочих процессах. Цель — привязать ИИ к проверенным корпоративным знаниям и контролировать издержки. Azure Databricks уже используют тысячи компаний, среди них Unilever, Electrolux и SMBC.
👉🏻 Канал | 💬 Чат | 📕 Каталог
