Top-Thema der Woche: DeepSeek V4 Flash in Microsoft Foundry – Open-Source-Modelle werden zur echten Enterprise-Alternative

DeepSeek V4 Flash ist seit dem 1. Mai in Microsoft Foundry verfügbar, V4 Pro folgt in Kürze. Damit erweitert Microsoft sein Foundry Model Catalog um ein weiteres leistungsstarkes Open-Source-Modell – und der Zeitpunkt ist kein Zufall: Parallel kündigt Microsoft das Retirement von Prompt flow an (April 2027) und positioniert das Agent Framework als einzige Zukunft für AI-Workflows.

Die wichtigsten Neuerungen:

• DeepSeek V4 Flash: Optimiert auf Geschwindigkeit und Kosteneffizienz – ideal für latenz-sensitive Szenarien wie Echtzeit-Chat, Klassifikation und Routing in Multi-Agent-Architekturen. Das Modell bietet ein starkes Preis-Leistungs-Verhältnis gegenüber proprietären Alternativen
• DeepSeek V4 Pro: Kommt in Kürze als Quality-Tier – für Aufgaben, die tieferes Reasoning erfordern, etwa komplexe Dokumentenanalyse oder Code Generation. Zusammen bilden Flash und Pro ein abgestuftes Modell-Portfolio
• Enterprise-Governance inklusive: Beide Modelle laufen innerhalb von Foundrys Compliance-Framework mit Content Filtering, Managed Compute und regionaler Datenhaltung – das unterscheidet Foundry-Deployments von Self-Hosting
• Prompt flow wird retired (April 2027): Microsoft empfiehlt die Migration auf das Agent Framework. Bestehende Prompt flow-Nutzer haben 12 Monate, aber die Feature-Entwicklung ist eingestellt

Meine Einschätzung: Die Verfügbarkeit von DeepSeek V4 in Foundry zeigt, wie ernst Microsoft den Multi-Model-Ansatz nimmt. Für IT-Leiter ist das relevant, weil es die Abhängigkeit von einem einzigen Modell-Anbieter reduziert – GPT-5.5 für Frontier-Tasks, DeepSeek V4 Flash für kosteneffiziente Workloads, Kimi K2.6 für Open-Source-Szenarien. Gleichzeitig ist die Prompt flow Retirement ein klares Signal: Wer noch Prompt flow nutzt, sollte jetzt mit der Migrationsplanung beginnen – nicht erst in 6 Monaten. Das Agent Framework ist der einzige strategisch unterstützte Pfad für AI-Orchestrierung in Azure.

🔗 DeepSeek V4 in Foundry 🔗 Prompt flow Retirement

(Azure) AI

Azure SRE Agent – KI-gestütztes Incident Management wird real

Microsoft stellt den Azure SRE Agent vor – einen KI-Agenten, der Azure Monitor Alerts automatisch triagiert, kontextualisiert und Handlungsempfehlungen gibt. Statt Alert-Fatigue durch hunderte Low-Priority-Alerts analysiert der SRE Agent Korrelationen zwischen Metriken, Logs und Traces und liefert strukturierte Root-Cause-Analysen. Dazu kommt ein Plugin Marketplace, über den Teams eigene Skills (Runbooks, Policy Rules) und MCP Connectors (Deployment Tracker, CMDB) als wiederverwendbare Plugins bereitstellen.

🔗 Azure SRE Agent 🔗 SRE Agent Plugin Marketplace

LangChain-Azure-CosmosDB Connector – Eine Datenbank für RAG und Agents

Der neue LangChain + LangGraph Connector für Azure Cosmos DB vereint Vector Store, Chat History, Agent Checkpointer, Semantic Cache und Long-Term Memory in einer einzigen Datenbank. Statt sechs verschiedene Services zusammenzukleben, nutzen Teams Cosmos DB als universellen Backend für RAG-Pipelines und Agent State Management.

🔗 LangChain-Azure-CosmosDB

Voice Live API mit WebRTC Support (Preview)

Die Voice Live API unterstützt jetzt WebRTC – Low-Latency, bidirektionale Sprach-Interaktionen direkt aus Web- und Mobile-Clients. Relevant für Teams, die Voice Agents oder Echtzeit-Sprachassistenten bauen. Dazu: Post-Stream Refinement liefert höhere Transkriptionsgenauigkeit nach dem Streaming, ohne die Echtzeit-Latenz zu erhöhen.

🔗 Voice Live API WebRTC 🔗 Post-Stream Refinement

Agent Governance Toolkit – Shift-Left Security für AI Agents

Teil 2 der AGT-Serie: Neben Runtime-Governance (Policy Engine, Zero-Trust Identity, Execution Sandboxing) zeigt Microsoft jetzt, wie man Governance-Violations bereits in der Entwicklung erkennt – bevor Agents in Produktion gehen. Ergänzt durch PyRIT, Microsofts Red-Teaming-Framework für AI Agents.

🔗 Agent Governance Toolkit 🔗 PyRIT Red Teaming

📋 Azure Core Updates

Hybrid & Modern Work

OIDC Federation für Terraform Pipelines – Schluss mit langlebigen Secrets

Ein Praxis-Blogpost, der genau den wunden Punkt trifft: Die meisten Terraform-Pipelines authentifizieren sich noch mit langlebigen ARM_CLIENT_SECRET-Werten. OIDC Workload Identity Federation ersetzt diese durch kurzlebige Tokens – für GitHub Actions und Azure DevOps. Der Artikel liefert komplette Setup-Anleitungen für beide Plattformen inklusive Entra ID App Registration mit Federated Credentials.

🔗 OIDC für Terraform Pipelines

Azure Governance mit EPAC automatisieren

Enterprise Policy as Code (EPAC) ermöglicht die vollstaendige Automatisierung von Azure Policy Assignments, Exemptions und Initiatives über Git-basierte Workflows. Der Beitrag zeigt, wie Teams Policy-Drift eliminieren und Governance-Entscheidungen als Pull Requests abbilden – relevant für Multi-Subscription-Umgebungen.

🔗 Azure Governance mit EPAC

Azure Infra Summit 2026 – Termin vormerken

Microsofts Azure Infra Summit findet am 19.-21. Mai statt – kostenlos, virtuell, mit L300-L400-Sessions. Keine Marketing-Slides, sondern Engineering-fokussierte Sessions zu Architektur, Gotchas und Production Stories.

🔗 Azure Infra Summit Registration

Security & Identity

• Microsoft Sentinel April 2026 – Umfangreiche Updates: Cost Limit Enforcement verhindert unkontrollierte Query-Kosten, neue Connectors für CrowdStrike und Imperva, A365 Observability Connector bringt AI-Agent-Telemetrie in den Sentinel Data Lake. Dazu: Neues Cost Estimation Tool mit 3-Jahres-Projektion und Graph Tool Collection für visuelle Analyse von Identity-Beziehungen
• WAF Default Ruleset DRS 2.2 GA: Aktualisierte Regeln gegen neue Angriffsvektoren bei gleichzeitig reduzierten False Positives. Upgrade-Empfehlung für alle Application Gateway und Front Door WAF-Konfigurationen
• Confidential Computing für Event Hubs Dedicated: Schutz von Streaming-Daten während der Verarbeitung – relevant für regulierte Branchen (Finance, Healthcare, Government), die bisher nur Data-at-Rest und Data-in-Transit verschluesselt haben
• Bastion Managed Identity für Session Recording (Preview): Graphische Session-Aufzeichnung nutzt jetzt Managed Identity statt Storage Account Keys – eliminiert die Notwendigkeit, Zugriffsschluessel zu rotieren
• RC4 Hardening Guide: Definitive Anleitung zur Verwaltung der RC4-Haertung in Kerberos-Umgebungen – technische Fortsetzung der RC4-Deprecation-Serie
• Kata microVM Isolation für AKS: Container-Escape-Mitigation durch Hardware-isolierte microVMs – demonstriert am Beispiel von OpenClaw, einem autonomen AI-Agenten

🔗 Sentinel April 2026 🔗 WAF DRS 2.2 🔗 Event Hubs Confidential Computing 🔗 RC4 Hardening

⚠️ Abkündigungen & Retirements

ACHTUNG: Prompt flow Retirement ist angekündigt – auch wenn die Deadline erst April 2027 ist, solltet ihr jetzt evaluieren, welche Workflows betroffen sind. Die Feature-Entwicklung ist bereits eingestellt. Näher liegende Deadlines: AKS Ubuntu 22.04 und Flatcar Linux enden im Juni 2026 – Node Pool Migrationen jetzt planen. Und: Die Compute API-Aenderung (non-null securityType) kann Breaking Changes in Automatisierungen verursachen, die auf null-Prüfungen basieren.

FinOps-Tipp der Woche: Sentinel Cost Estimation Tool – Kosten prognostizieren statt überrascht werden

Microsoft hat ein neues Cost Estimation Tool für Sentinel vorgestellt – ein geführtes, meter-level Schätzungstool mit integrierter 3-Jahres-Kostenprojektion. Relevant für alle, die Sentinel einsetzen oder evaluieren und die Kosten nicht erst nach dem ersten Billing Cycle verstehen wollen.

Warum das relevant ist: Sentinel-Kosten sind notorisch schwer vorherzusagen. Die Abrechnung basiert auf Ingestion-Volumen, und Log-Quellen wie Entra ID, Defender oder Firewall-Logs können schnell skalieren. Das neue Tool hilft, Kosten auf Meter-Ebene zu schätzen und böse Überraschungen zu vermeiden.

Konkrete Umsetzung:

bash

# Aktuelle Sentinel-Ingestion pro Tabelle analysieren
az monitor log-analytics workspace table list \
  --resource-group rg-sentinel \
  --workspace-name law-sentinel-prod \
  --query "[?totalRetentionInDays>0].{Table:name, RetentionDays:totalRetentionInDays, Plan:plan}" \
  -o table
# Top-Tabellen nach Ingestion-Volumen (letzte 30 Tage)
# Im Log Analytics Workspace ausfuehren:
# Usage
# | where TimeGenerated > ago(30d)
# | summarize GB=sum(Quantity)/1024 by DataType
# | sort by GB desc
# | take 10
# Cost Limit setzen (Preview) - verhindert Runaway-Kosten
# Azure Portal -> Sentinel -> Settings -> Cost Management
# Daily Cap konfigurieren basierend auf eurem durchschnittlichen Tagesvolumen + 20% Buffer

Zusätzlich beachten: Sentinel bietet jetzt Cost Limit Enforcement – ihr könnt ein tägliches Ingestion-Cap setzen, um unkontrollierte Kosten zu verhindern. Kombiniert mit dem Cost Estimation Tool ergibt das eine solide FinOps-Grundlage für Sentinel-Deployments.

🔗 Sentinel April 2026 Updates 🔗 Sentinel Pricing

💡 Deep Dive: Azure Monitor SLI/SLO – Service Level endlich nativ messen

Azure Monitor bekommt mit Service Level Indicators (SLI) und Service Level Objectives (SLO) ein Feature, das Cloud-Architekten seit Jahren fordern: native Messung der Servicequalitaet aus Kundenperspektive, direkt in der Azure-Plattform. Das Feature ist ab sofort als Public Preview verfügbar.

Das Problem: SLAs ohne Messgrundlage

Die meisten Teams definieren SLAs mit Kunden oder internen Stakeholdern, messen die Einhaltung aber mit selbstgebauten Dashboards, manuellen KQL-Queries oder externen Tools. Das fuehrt zu drei typischen Problemen: Keine standardisierte Berechnung (jedes Team misst anders), keine proaktive Warnung bei Error Budget-Verbrauch, und keine historische Trendanalyse über Quartale hinweg. Azure Monitor SLI/SLO löst genau diese Lücke.

Was Azure Monitor SLI/SLO bietet:

SLIs sind quantitative Messungen der Servicequalitaet. Azure Monitor unterstützt zwei primaere SLI-Typen:

1. Availability SLI: Verhaeltnis erfolgreicher Requests zu Gesamtanfragen – basierend auf HTTP-Statuscodes, Custom Metrics oder Log-Queries
2. Latency SLI: Anteil der Requests, die unter einem definierten Schwellenwert liegen – etwa P95 < 200ms

SLOs definieren das Zielniveau: „99.9% Availability über 30 Tage“ oder „95% der Requests unter 200ms“.

Architektur und Datenquellen:

Azure Monitor SLI/SLO integriert sich mit bestehenden Datenquellen:

Setup am Beispiel einer Web-Anwendung:

bash

# Voraussetzung: Application Insights mit aktiver Telemetrie
# SLI/SLO werden über Azure Monitor konfiguriert
# 1. Aktuellen Availability Baseline ermitteln (KQL in Log Analytics)
# requests
# | where timestamp > ago(30d)
# | summarize
#     TotalRequests = count(),
#     SuccessfulRequests = countif(resultCode startswith "2" or resultCode startswith "3"),
#     FailedRequests = countif(resultCode startswith "5")
# | extend AvailabilityPct = round(100.0 * SuccessfulRequests / TotalRequests, 3)
# 2. Latenz-Baseline prüfen
# requests
# | where timestamp > ago(30d)
# | summarize
#     P50 = percentile(duration, 50),
#     P95 = percentile(duration, 95),
#     P99 = percentile(duration, 99)
# 3. SLI/SLO im Portal konfigurieren:
# Azure Monitor -> Service Level Objectives (Preview) -> Create
# - Name: "api-availability-slo"
# - SLI Type: Availability
# - Data Source: Application Insights
# - Good Events: resultCode < 500
# - Total Events: All requests
# - SLO Target: 99.9%
# - Evaluation Window: 30 days (rolling)
# - Alert: Trigger bei Error Budget < 25%

Error Budget als Steuerungsinstrument:

Der eigentliche Mehrwert liegt im Error Budget. Bei einem 99.9% SLO über 30 Tage duerfen insgesamt 43.2 Minuten Downtime auftreten. Azure Monitor trackt den Verbrauch dieses Budgets in Echtzeit und kann Alerts ausloesen, bevor das Budget erschoepft ist.

Error Budget = 1 - SLO Target
Bei 99.9% SLO: Error Budget = 0.1%
Über 30 Tage: 30 * 24 * 60 * 0.001 = 43.2 Minuten
Burn Rate Alert:
- Wenn die aktuelle Fehlerrate das Budget in weniger als 3 Tagen aufbrauchen wuerde
- -> Sofortige Benachrichtigung an das Operations-Team

Einschränkungen der Preview:

• Nur über Azure Portal konfigurierbar – keine CLI/Bicep/Terraform-Unterstützung in der Preview
• Maximale Evaluation Windows sind begrenzt (Details in der Dokumentation)
• Composite SLOs (mehrere SLIs in einem SLO) sind noch nicht unterstützt
• Keine native Integration mit Azure DevOps Work Items für automatische Incident-Erstellung
• Kosten: In der Preview kostenfrei, Pricing für GA noch nicht angekündigt

Meine Einschätzung: SLI/SLO in Azure Monitor schließt eine kritische Lücke. Bisher mussten Teams entweder teure Third-Party-Tools (Datadog SLOs, Nobl9) nutzen oder eigene KQL-basierte Lösungen bauen. Die native Integration in Azure Monitor bedeutet: gleiche Datenquelle, kein zusätzliches Tooling, und das Error-Budget-Konzept wird von Google SRE-Practices in die Azure-Welt übertragen. Für IT-Leiter ist das ein gutes Argument in SLA-Verhandlungen mit internen Kunden – ihr könnt jetzt objektiv und nachvollziehbar messen, ob eure Services die vereinbarten Levels einhalten. Mein Rat: In der Preview-Phase mit einer unkritischen Anwendung testen, Baseline-Daten sammeln und das Konzept im Team etablieren, bevor ihr es für produktionskritische Services ausrollt.

🔗 Azure Monitor SLI/SLO 🔗 Azure Monitor Dokumentation 🔗 Google SRE – SLIs and SLOs

✅ Eine Maßnahme für diese Woche

Prompt flow Inventur durchfuehren und Azure Monitor SLI/SLO testen

bash

# 1. Prompt flow Inventur - welche Workflows sind betroffen?
# Azure Portal -> Microsoft Foundry -> Prompt flow
# Alle aktiven Flows dokumentieren und Migrationsprioritaet festlegen
# Empfehlung: Agent Framework als Zielplattform evaluieren
# 2. AKS Node Pools prüfen - Ubuntu 22.04 und Flatcar Deadlines nah
az aks nodepool list \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod \
  --query "[].{Name:name, OsType:osType, OsSku:osSku, K8sVersion:currentOrchestratorVersion}" \
  -o table
# 3. Compute API Breaking Change - securityType null-Checks identifizieren
# In IaC-Templates nach Logik suchen, die securityType == null prüft
# grep -r "securityType" --include="*.bicep" --include="*.tf" --include="*.json"
# 4. Azure Monitor SLI/SLO testen (Preview)
# Azure Monitor -> Service Level Objectives -> Create
# Startet mit einer Anwendung, die bereits Application Insights nutzt
# Baseline: 30-Tage Availability und P95 Latency ermitteln
# 5. WAF DRS 2.2 Upgrade evaluieren
az network application-gateway waf-config show \
  --resource-group rg-waf \
  --gateway-name agw-prod \
  --query "{RuleSetType:ruleSetType, RuleSetVersion:ruleSetVersion}" \
  -o table

Prompt flow Inventur hat strategische Prioritaet – die Migration wird aufwendig und sollte frueh geplant werden. Parallel: AKS Node Pool OS-Versionen prüfen (Ubuntu 22.04 Deadline Juni) und die neue WAF DRS 2.2 Ruleset-Version testen. Azure Monitor SLI/SLO ist ein Quick Win – die Preview ist kostenlos und liefert sofort Mehrwert für SLA-Reporting.

🔗 Agent Framework Migration 🔗 AKS Supported OS