ACA is terug op CloudBrew 2025 met een tweedaagse Deep Dive in Microsoft Azure

We zijn blij om te zien dat photobombing in 2025 nog steeds een ding is 😉

Het was dan ook passend dat onze partners van Microsoft, Wouter Gevaert en Jan Gezels, de aftrap gaven na de eerste keynote.

Azure Belgium Central en het cloud-native pad

De openingssessie was niet zomaar een overwinningsrondje voor het nieuwe datacenter. Het was een technische roadmap. Hoewel Azure Belgium Central (ABC) open is voor gebruik, gebeurt er achter de schermen nog veel werk om continu meer Azure-diensten beschikbaar te maken.

De grootste verandering zit in hoe we naar betrouwbaarheid kijken. We stappen af van het oude model met gepaarde regio’s en zetten volop in op moderne multi-region High Availability en Disaster Recovery Planning. Met meerdere Availability Zones nu dichtbij kunnen we eindelijk echte lokale dataresidentie aanbieden aan compliance-gevoelige klanten, zonder in te boeten op fouttolerantie.

• De belangrijkste inzichten?
  Beschikbaarheid correct controleren: Er is momenteel maar één betrouwbare manier om te zien welke diensten beschikbaar zijn in de ABC-regio: de Azure Pricing Calculator. Gebruik deze tool boven alle andere om beschikbaarheid te verifiëren.
• Latency en interconnectiviteit: De ABC-regio heeft een van de laagste latencyverbindingen met Europe-West (Amsterdam). Resources en workloads koppelen met die regio is geen probleem op vlak van latency.
• Omgaan met ontbrekende diensten: Diensten zoals Azure Databricks en Microsoft Fabric zijn nog niet beschikbaar in ABC. Technisch is dit wel beheersbaar. Je kan je primaire workload in ABC uitrollen en op netwerkniveau koppelen met Databricks- of Fabric-instances in een andere regio.

Gezonde apps, gelukkige gebruikers: slimmere monitoring met Azure Health Models

Met de infrastructuurbasis gelegd, trokken we naar de sessie van Massimo Crippa: “Healthy apps, happy users: smarter monitoring with Azure Health Models”.

Massimo legde de toekomst van monitoring uitstekend uit. We weten allemaal hoe moeilijk het is om monitoring alerts goed te configureren. Je moet voortdurend balanceren tussen welke alerts je instelt en welke drempelwaarden je gebruikt.

• Te laag: een alert triggeren bij 70 procent CPU-gebruik veroorzaakt vaak een stortvloed aan meldingen. Dat leidt tot alert fatigue en vergroot het risico dat kritieke issues gemist worden.
• Te hoog: ligt de drempel te hoog, dan is de omgeving vaak al aangetast tegen de tijd dat je een melding krijgt.

Daarnaast heeft traditionele alerting twee grote tekortkomingen:

• De stortvloed: Als één Azure-resource faalt, wordt je ticketsysteem meestal overspoeld met meerdere alerts voor dezelfde oorzaak, zoals beschikbaarheid, latency en CPU.
• Valse criticals: Niet-kritieke alerts worden vaak als kritisch gemarkeerd. Als bijvoorbeeld één node achter een load balancer uitvalt maar de andere nodes het verkeer opvangen, is de gebruikerservaring niet aangetast, maar de alert roept toch “Critical”.

Azure Health Models is geen wondermiddel, maar wel een grote stap vooruit. Het belangrijkste inzicht is dat alerts worden gebundeld op basis van het systeem. Als een App Service een CPU-piek heeft, krijg je één geconsolideerde alert in plaats van een stroom aan symptomen.

Daarnaast kan je onderscheid maken tussen “Critical” (impact op de gebruiker) en “Degraded” (backendprobleem zonder gebruikersimpact).

Samengevat bieden Azure Health Models deze voordelen:

• Het samenbrengen van zakelijke en technische perspectieven in één health model
• Snelle detectie van de algemene gezondheidstoestand van een systeem
• Het wegwerken van alert fatigue

Vibecoding: van coder naar operator

We beloven dat we deze blogpost niet hebben “vibewritten”, maar we hebben wel enorm genoten van de sessie van Sakari Nahi: “Let’s vibecode something.”

Dit was misschien wel de meest toekomstgerichte talk van het event. Sakari belichtte een strategische verschuiving die velen van ons al voelen: AI verandert de rol van de engineer van pure code-schrijver naar “operator van AI”.

De hele sessie was een live demonstratie van hoe je jezelf via vibecoding naar een volledig werkende multiplayer game kan brengen.

We leerden hoe je OpenSpec kan inzetten en waarom dit zo krachtig is. Kort samengevat is het een gespecialiseerde development toolkit voor AI-ondersteund coderen. Het focust op Spec-Driven Development, een workflow waarbij je eerst duidelijk definieert wat je wil, voordat een AI-agent zoals Claude of Cursor probeert code te schrijven.

Waarom is OpenSpec zo krachtig?

• Eén bron van waarheid: AI-agents hallucineren vaak of missen vereisten wanneer instructies verstopt zitten in een lange chatgeschiedenis. OpenSpec dwingt een “Source of Truth”-bestand af dat de AI moet volgen, wat fouten en “luie” code vermindert.
• Ideaal voor bestaande code: In tegenstelling tot sommige AI-starterkits die enkel werken voor nieuwe projecten, is OpenSpec ontworpen om wijzigingen in bestaande complexe codebases te beheren. Het volgt veranderingen in plaats van volledige bestanden opnieuw te genereren.
• Agent-agnostisch: Het is geen op zichzelf staande AI, maar een protocol. Je kan het gebruiken met Cursor, Claude Code, GitHub Copilot of eender welke LLM die bestanden kan lezen. Er zijn geen eigen API-sleutels nodig.

We weten allemaal dat AI soms onvoorspelbaar kan zijn. Hoewel de multiplayer game aan het einde van de sessie niet volledig werkte, waren we geïnspireerd.

Zo geïnspireerd zelfs dat we diezelfde avond bij ons thuis Antigravity van Google opstartten. We volgden de principes van OpenSpec en wat we overdag hadden geleerd.

Met verwondering zagen we hoe Antigravity met enkele prompts en iteraties een volledige top-down space shooter creëerde. In vijftien minuten hadden we een lokale space invaders game, met graphics, levels, highscores en alle toeters en bellen.

Dat is de kracht van OpenSpec en vibecoding.

Dag twee: de governance reality check

Als dag één over de toekomst ging, draaide dag twee om de concrete realiteit van alles beheren.

We begonnen met een prikkelende titel: “Azure Tags are Dead. Meet Their Weird Cousin: Service Groups”, door Stijn Depril en Tim Verbist.

Eerlijk is eerlijk, Azure tagging moest orde brengen in de chaos. In de praktijk zorgen inconsistente, ontbrekende of niet-afgedwongen tags er vaak voor dat FinOps een nachtmerrie wordt. Stijn en Tim introduceerden Service Groups als de ontbrekende schakel.

De live demo was een echte eyeopener en toonde hoe Service Groups kosteninzicht en verantwoordelijkheid kunnen bieden waar traditionele tagging steeds tekortschiet. Je kan dit zien als een virtuele container die Azure-resources van overal binnen de tenant kan bevatten, over verschillende subscriptions heen.

Dit laat toe dat verschillende teams binnen je organisatie een ander overzicht krijgen. Zo kan een Product Owner één Service Group hebben met alle resources voor een specifieke applicatie, ongeacht of die zich in een productie- of ontwikkelsubscription bevinden.

Hoewel Service Groups nog in preview zijn, suggereerde de sessie dat ze op termijn tags zouden kunnen vervangen, en misschien zelfs Management Groups als primaire manier om policies toe te wijzen en resources te groeperen. Bij ACA zijn we nog niet overtuigd dat ze alles zullen vervangen, maar het potentieel is onmiskenbaar.

Level up security

De namiddag nam een interessante wending met de sessie van Roland Guijt: “Level Up Your Security: OpenID Connect/OAuth update”.

Met de release van OAuth 2.1 lichtte Roland drie belangrijke protocolverbeteringen toe:

• PKCE vereist voor authorization code flow
• Dit werkt als een bijpassend digitaal ticketstubje. Het zorgt ervoor dat de app die je login start ook dezelfde is die hem afrondt, waardoor het bijna onmogelijk wordt voor een hacker om het proces onderweg te onderscheppen.
• Implicit en resource owner password grant geschrapt
• Verouderde loginmethodes die apps toelieten je echte wachtwoord te zien of makkelijk te misleiden waren, worden uitgefaseerd. Hierdoor komen apps nooit rechtstreeks in aanraking met je credentials, wat je beschermt tegen datalekken en phishing.
• Refresh tokens voor public clients moeten sender-constrained zijn of eenmalig gebruikt worden
• Dit zet als het ware een zelfvernietigingsmechanisme of slot op de digitale sleutels die je ingelogd houden. Als een aanvaller zo’n sleutel zou stelen, kan die er niets mee aanvangen omdat hij ongeldig is of meteen vervalt.

Conclusie: volle vaart richting 2026

CloudBrew 2025 zit erop en liet ons achter met heel wat om over na te denken en mee aan de slag te gaan.

Met Azure Belgium Central officieel open is datasoevereiniteit geen modewoord meer, maar een basisvereiste. Security is verplicht, AI wordt geïntegreerd in alle workflows en governance krijgt eindelijk de tools die het nodig heeft.

Samen met onze klanten en partners is ACA klaar om deze inzichten om te zetten in actie. Tegen de tijd dat CloudBrew 2026 eraan komt, verwachten we dat het landschap opnieuw veranderd zal zijn, en wij zullen er klaar voor zijn.

Tot de volgende keer!

Benieuwd hoe we je kunnen helpen meer uit je cloudoplossingen te halen?