⚡️ 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, что даёт управляемый доступ к данным и ИИ прямо в рабочих процессах. Цель партнерства — привязать ИИ к проверенным корпоративным данным.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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, что даёт управляемый доступ к данным и ИИ прямо в рабочих процессах. Цель партнерства — привязать ИИ к проверенным корпоративным данным.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft
Databricks and Microsoft expand partnership to help enterprises bring business context to enterprise AI
REDMOND, Wash., and SAN FRANCISCO — July 23, 2026 — Microsoft Corp. and Databricks on Wednesday announced an expansion of their decade-long strategic partnership, extending into the 2030s. Databricks will deepen its use of Azure Databricks to run core business…
⚡️ AKS без гипервизора: Microsoft запускает Kubernetes прямо на «голом железе»
Microsoft развернула Azure Kubernetes Service напрямую на физическом оборудовании — без слоя гипервизора. Новый вариант объединяет платформу Azure Local Small Form Factor и AKS Arc на Linux и автоматически подключается к Azure Arc для централизованного управления.
Отказ от виртуализации отдаёт все ресурсы под рабочие нагрузки, сохраняя привычный опыт Azure — портал, Bicep, политики, мониторинг и GitOps.
Как отмечает Томас Маурер, решение создано для периферии — ритейла, производства, полевых объектов, — а также суверенных дата-центров и сценариев, где важна максимальная производительность. Один и тот же Kubernetes и единый интерфейс теперь работают всюду: от облака до края сети.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft развернула Azure Kubernetes Service напрямую на физическом оборудовании — без слоя гипервизора. Новый вариант объединяет платформу Azure Local Small Form Factor и AKS Arc на Linux и автоматически подключается к Azure Arc для централизованного управления.
Отказ от виртуализации отдаёт все ресурсы под рабочие нагрузки, сохраняя привычный опыт Azure — портал, Bicep, политики, мониторинг и GitOps.
Как отмечает Томас Маурер, решение создано для периферии — ритейла, производства, полевых объектов, — а также суверенных дата-центров и сценариев, где важна максимальная производительность. Один и тот же Kubernetes и единый интерфейс теперь работают всюду: от облака до края сети.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Thomas Maurer
Azure Kubernetes Service (AKS) on Bare Metal
Many organizations need to run Kubernetes on-premises, at the edge, or in sovereign environments, while still benefiting from the simplicity and consistency of Azure. That's exactly where Azure Kubernetes Service (AKS) on bare metal comes in. In this post…
❤3👍2
⚡️ Azure сам проверит безопасность ваших Linux-машин по стандарту CIS
Microsoft добавила в Azure встроенную проверку Linux-серверов на соответствие стандартам безопасности CIS Benchmark — функция уже доступна всем. Она работает в Azure и Azure Arc через Azure Machine Configuration и постоянно сверяет настройки Linux-систем с признанными во всём мире требованиями CIS.
Azure теперь сам находит слабые места в конфигурации, показывает отклонения от нужных настроек и готовит отчёты о соответствии через Azure Policy; правила можно настраивать под себя и задавать исключения.
Раньше для этого нужны были отдельные инструменты или ручные проверки — теперь всё встроено, и командам безопасности проще навести порядок и подтвердить соответствие требованиям регуляторов сразу на множестве серверов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft добавила в Azure встроенную проверку Linux-серверов на соответствие стандартам безопасности CIS Benchmark — функция уже доступна всем. Она работает в Azure и Azure Arc через Azure Machine Configuration и постоянно сверяет настройки Linux-систем с признанными во всём мире требованиями CIS.
Azure теперь сам находит слабые места в конфигурации, показывает отклонения от нужных настроек и готовит отчёты о соответствии через Azure Policy; правила можно настраивать под себя и задавать исключения.
Раньше для этого нужны были отдельные инструменты или ручные проверки — теперь всё встроено, и командам безопасности проще навести порядок и подтвердить соответствие требованиям регуляторов сразу на множестве серверов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Petri IT Knowledgebase
Microsoft Brings Native CIS Benchmark Auditing to Linux in Azure
Microsoft adds native CIS Benchmark auditing for Linux in Azure and Azure Arc, helping organizations assess compliance and security posture.
❤2👍2
⚡️ 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Марк Руссинович, технический директор Microsoft Azure, в свободное время запустил классический DOOM внутри Microsoft Paint и выложил исходный код проекта DoomPaint на GitHub.
Проект выдаёт 35 кадров в секунду в разрешении 320×200 или 640×400. Отдельная «фишка» — отмена смерти: по Ctrl+Z можно отматывать кадры назад и, по сути, отыгрывать время после гибели персонажа.
Эксперимент продолжает давнюю традицию сообщества запускать DOOM на чём угодно — от тестовых полосок и калькуляторов до кассовых аппаратов и холодильников; теперь в этот список попал и стандартный Paint.
👉🏻 Канал | 💬 Чат | 📕 Каталог
❤4🎉2
⚡️ 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 и структура аккаунтов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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 и структура аккаунтов.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Tech Insider
AWS Control Tower vs Azure Landing Zone vs GCP 2026
AWS Control Tower vs Azure Landing Zone vs Google Cloud landing zones compared: pricing, guardrails, deployment time, and IaC support for 2026.
👍7❤3
⚡️ Две зоны или три: почему «три везде» — это не ответ, а рефлекс
Марк Руссинович с коллегами разобрал самый частый рефлекс в проектировании Azure: на вопрос, сколько availability zones нужно проду, большинство архитекторов отвечает «три». Позиция авторов: это правило большого пальца вместо решения, и стоит оно денег, ёмкости и лишней сложности.
Правильный вопрос не «сколько зон», а «сколько зон нужно каждому компоненту, чтобы пережить потерю одной». Решение принимается покомпонентно, по трём критериям: выдержит ли оставшаяся зона нужное состояние после отказа, зависит ли корректность от третьего домена отказа, и как распределяется резерв ёмкости. Stateless-компоненты и активно-пассивные пары закрываются двумя зонами. Три нужны там, где есть кворум, консенсус или выборы лидера, либо где тройная репликация требуется для заявленной durability. Отдельно подчёркнуто: три реплики не равны трём доменам отказа. Разложите кворумную систему по двум зонам, и потеря зоны с большинством убьёт кворум.
И различие, которое часто смазывают: zone-redundant ресурсы Azure раскладывает сам и сам отвечает за отказоустойчивость, а zonal вы прибиваете к конкретной зоне, и маршрутизация, репликация, детект отказа и восстановление остаются на вас. Если недоступны сразу две зоны в регионе, это уже не задача ворклоада, а disaster recovery.
А у вас сколько зон под прод и почему именно столько?
👉🏻 Канал | 💬 Чат | 📕 Каталог
Марк Руссинович с коллегами разобрал самый частый рефлекс в проектировании Azure: на вопрос, сколько availability zones нужно проду, большинство архитекторов отвечает «три». Позиция авторов: это правило большого пальца вместо решения, и стоит оно денег, ёмкости и лишней сложности.
Правильный вопрос не «сколько зон», а «сколько зон нужно каждому компоненту, чтобы пережить потерю одной». Решение принимается покомпонентно, по трём критериям: выдержит ли оставшаяся зона нужное состояние после отказа, зависит ли корректность от третьего домена отказа, и как распределяется резерв ёмкости. Stateless-компоненты и активно-пассивные пары закрываются двумя зонами. Три нужны там, где есть кворум, консенсус или выборы лидера, либо где тройная репликация требуется для заявленной durability. Отдельно подчёркнуто: три реплики не равны трём доменам отказа. Разложите кворумную систему по двум зонам, и потеря зоны с большинством убьёт кворум.
И различие, которое часто смазывают: zone-redundant ресурсы Azure раскладывает сам и сам отвечает за отказоустойчивость, а zonal вы прибиваете к конкретной зоне, и маршрутизация, репликация, детект отказа и восстановление остаются на вас. Если недоступны сразу две зоны в регионе, это уже не задача ворклоада, а disaster recovery.
А у вас сколько зон под прод и почему именно столько?
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
Two zones or three? A design framework for zone-resilient Azure workloads
Learn how to design zone-resilient Azure workloads by choosing the right availability zone strategy for each component, balancing reliability, cost, and operational complexity.
👍3
⚡️ 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 через провайдера посередине.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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 через провайдера посередине.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
Introducing Azure Multicloud Interconnect for AWS
Learn how Azure Multicloud Interconnect helps organizations simplify Azure and AWS connectivity, support AI workloads, and build scalable multicloud architectures through an open, cloud-native networking experience.
👍8❤1
⚡️ 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
👍16❤3
⚡️ 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 стоит только там, где приложение действительно переживёт пропажу диска на время. Для всех остальных это тихое изменение поведения в момент инцидента, о котором лучше узнать заранее.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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 стоит только там, где приложение действительно переживёт пропажу диска на время. Для всех остальных это тихое изменение поведения в момент инцидента, о котором лучше узнать заранее.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
The future of infrastructure resiliency starts with modernization
Learn how Azure can help assess resiliency posture, identify gaps, and increase uptime with recommendations, operational guidance, and more.
👍4
⚡️ 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 — ломать текущий трафик это не должно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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 — ломать текущий трафик это не должно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft
Azure updates | Microsoft Azure
Subscribe to Microsoft Azure today for service updates, all in one place. Check out the new Cloud Platform roadmap to see our latest product plans.
👍12❤3
⚡️ 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
У продакшен-агентов другая архитектура, чем у классического запрос-ответ приложения: им нужна отдельная исполняемая среда с ограниченными правами, а не общий пул инфраструктуры, где один взбесившийся агент утягивает за собой всех соседей. 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
Designing agent-first platforms: What changes when agents do the work
Learn how you can design your platform for software that acts using Microsoft Foundry and Azure Container Apps Sandboxes.
⚡️ 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 на рутине может выйти дешевле на порядок, даже если у неё цена за токен не самая низкая на рынке.
👉🏻 Канал | 💬 Чат | 📕 Каталог
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 на рутине может выйти дешевле на порядок, даже если у неё цена за токен не самая низкая на рынке.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
GPT-6 Astra, Sol, and Luna: For production agents in Microsoft Foundry
Explore GPT-6 Astra, Sol, and GPT-6 Luna in Microsoft Foundry, with scalable model options for production AI agents, complex workflows, and high-volume tasks.
👍2
⚡️ Microsoft раскрыла архитектуру Maia 300
Microsoft впервые подробно рассказала, как устроен Maia 300, её ИИ-ускоритель третьего поколения, который будет обслуживать Copilot, GitHub Copilot и Foundry. Чип собран из нескольких чиплетов на TSMC N2P, получил 288 ГБ памяти HBM4 и научился считать в форматах точности ниже 3 бит.
Такая архитектура позволит решению от Microsoft обрабатывать больше одновременных запросов и выполнять более масштабные задачи, повышая общую мощность дата-центра.
Если прошлые поколения Maia не смогли полноценно заменить системы NVIDIA, то теперь Microsoft планирует масштабировать инфраструктуру Azure с Maia 300 до нескольких гигаватт, начиная с 2027 года, сделав новинки основной платформой для инференса в продуктах и сервисах компании.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft впервые подробно рассказала, как устроен Maia 300, её ИИ-ускоритель третьего поколения, который будет обслуживать Copilot, GitHub Copilot и Foundry. Чип собран из нескольких чиплетов на TSMC N2P, получил 288 ГБ памяти HBM4 и научился считать в форматах точности ниже 3 бит.
Такая архитектура позволит решению от Microsoft обрабатывать больше одновременных запросов и выполнять более масштабные задачи, повышая общую мощность дата-центра.
Если прошлые поколения Maia не смогли полноценно заменить системы NVIDIA, то теперь Microsoft планирует масштабировать инфраструктуру Azure с Maia 300 до нескольких гигаватт, начиная с 2027 года, сделав новинки основной платформой для инференса в продуктах и сервисах компании.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft News
Deep dive into Azure Maia 300 architecture
Learn how Maia 300 is helping us move toward making advanced AI capabilities more accessible, affordable, and useful.
❤1
⚡️ 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-версией — ничего не изменится, пока не поднимете версию; это как раз тот случай, когда поднимать стоит осознанно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Для новых 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-версией — ничего не изменится, пока не поднимете версию; это как раз тот случай, когда поднимать стоит осознанно.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Microsoft
Azure updates | Microsoft Azure
Subscribe to Microsoft Azure today for service updates, all in one place. Check out the new Cloud Platform roadmap to see our latest product plans.
⚡️ 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 (пока в превью). Перед запуском разработчик видит отчёт с найденными зависимостями и планом замены и может поправить его вручную.
Функция уже работает в восьми регионах 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 (пока в превью). Перед запуском разработчик видит отчёт с найденными зависимостями и планом замены и может поправить его вручную.
Функция уже работает в восьми регионах AWS, включая Франкфурт и Лондон.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Amazon
AWS Transform announces Azure-to-AWS cloud-native code conversion - AWS
Discover more about what's new at AWS with AWS Transform announces Azure-to-AWS cloud-native code conversion
❤1👍1
⚡️ 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
В 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.
👉🏻 Канал | 💬 Чат | 📕 Каталог
⚡️ 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 — и что он успел натворить?
👉🏻 Канал | 💬 Чат | 📕 Каталог
Вышла стабильная 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 — и что он успел натворить?
👉🏻 Канал | 💬 Чат | 📕 Каталог
⚡️ Красота уходит в облако: 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 это ещё один крупный клиент из мира люкса и ритейла, далёкого от технологий.
👉🏻 Канал | 💬 Чат | 📕 Каталог
Косметический гигант 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 это ещё один крупный клиент из мира люкса и ритейла, далёкого от технологий.
👉🏻 Канал | 💬 Чат | 📕 Каталог