CLOUD & MANAGED SERVICES
18/12/2025 • Patrik Söderström

ACA is back at CloudBrew 2025 with a two day Deep Dive into Microsoft Azure

CloudBrew has always been a highlight on our calendar, but the 2025 edition felt different. Perhaps it was the timing. Just the month prior, November 2025, the Azure Belgium Central region finally opened its doors. ACA has always operated from the heart of Europe, so seeing this massive national milestone go live just before the conference added a layer of excitement.


We are happy to see that photobombing is still a concept in 2025 😉

It was fitting, then, that our partners from Microsoft, Wouter Gevaert and Jan Gezels, kicked things off after the initial key note.

Azure Belgium Central and the Cloud-Native Path

The opening session wasn't just a victory lap for the new datacenter; it was a technical roadmap. Even though Azure Belgium Central (ABC) is open for business, there is much work in the background to continuously bring more Azure services live.

The biggest shift is how we think about reliability. We are moving away from the old model of paired regions and leaning hard into modern multi-region High Availability (HA) and Disaster Recovery Planning. With multiple Availability Zones now in our backyard, we can finally offer true local data residency to our compliance-sensitive clients without sacrificing fault tolerance.

The biggest takeaways?

  • Check availability correctly: There is currently only one reliable way to see which services are available in the ABC region: the Azure Pricing Calculator. Use this tool above all others to verify service availability.
  • Latency & interconnectivity: The ABC region has one of the lowest latency connections to Europe-West (Amsterdam). Interconnecting resources and workloads with that region is not an issue, latency-wise.
  • Handling missing services: Services such as Azure Databricks and Microsoft Fabric are not yet available in ABC. Technically, this is manageable: you can deploy your primary workload in ABC while interconnecting at the network level to instances of Databricks or Fabric in another region.

Healthy apps, happy users: smarter monitoring with Azure Health Models

With the infrastructure foundation set, we headed to Massimo Crippa’s session on "Healthy apps, happy users: smarter monitoring with Azure Health Models"

Massimo did a great job explaining the future of monitoring. We are all painfully aware that monitoring alerts are incredibly hard to get right. You constantly have to balance which alerts to configure and what thresholds to set.

  • Too low: Triggering an alert if CPU usage hits 70% often causes a flood of notifications. This leads to alert fatigue, increasing the risk of missing critical issues.
  • Too high: If the threshold is too high, the environment may already be impacted by the time you are notified.

Additionally, traditional alerting has two major flaws:

  • The flood: If one Azure resource fails, your ticketing system is usually flooded with multiple alerts (availability, latency, CPU) for the same root cause.
  • False criticals: Non-critical alerts are often flagged as critical. For example, if one node behind a load balancer goes down but others handle the traffic, the user experience isn't impacted, yet the alert screams "Critical."

Azure Health Models isn't a silver bullet, but it is a massive improvement. The main takeaway is that alerts are bundled depending on the system. If an App Service spikes in CPU, you receive one consolidated alert rather than a flood of symptoms.

Secondly, you can distinguish between "Critical" (user impact) and "Degraded" (backend issue, no user impact) statuses.

To summarize, Azure Health Models provide these benefits:

  • Bring together business and technical viewpoints of a health model
  • Quick detection of a system's overall health status
  • Elimination of alert fatigue

Vibecoding: From coder to operator

We promise we didn't "vibewrite" this blog post, but we certainly enjoyed Sakari Nahi’s session: "Let's vibecode something."

This was arguably the most forward-looking talk of the event. Sakari highlighted a strategic shift that many of us are already feeling: AI is changing the engineer’s role from a simple writer of code to an "operator of AI."

The entire session was a live demonstration on how you can vibecode yourself into a fully working multiplayer game.

We learned how to leverage OpenSpec and why this is incredibly powerful. In short, it’s a specialized development toolkit designed for AI assisted coding. It focuses on Spec-Driven Development (SDD) - a workflow where you clearly define what you want before an AI agent like Claude or Cursor attempts to write the code.

Why is OpenSpec powerful?

  • AI agents often hallucinate or miss requirements when instructions are buried in a long chat history. OpenSpec forces a "Source of Truth" file that the AI must follow, reducing errors and "lazy" coding.
  • Great for Existing Code: Unlike some AI starter kits that only work for new projects (0→1), OpenSpec is designed to manage changes in existing complex codebases (1→N). It tracks "deltas" (changes) rather than just generating whole files.
  • Agent agnostic: It is not a standalone AI; it is a protocol. You can use it with Cursor, Claude Code, GitHub Copilot, or any LLM that can read files. It doesn't require its own API keys.

We all know that AI can be a bit unpredictable at times. While the multiplayer game did not fully work at the end of the session, we were inspired.

So inspired, that late the same evening in our own home we fired up Antigravity from Google. We followed the principles of OpenSpec and what we had learned in the session during the day.

With awe, we saw a complete space top down shooter game being created by Antigravity with a couple of prompts and iterations. In 15 minutes we had a local space invaders games, with graphics, levels, highscore and all the bells and whistles.

That’s the power of OpenSpec and vibe coding!

Day Two: The Governance Reality Check

If day one was about the future, day two was about the nitty-gritty reality of managing it all.

We started with a provocative title: "Azure Tags are Dead. Meet Their Weird Cousin: Service Groups," by Stijn Depril and Tim Verbist.

Let’s be honest, Azure tagging was supposed to bring order to chaos. In reality, inconsistent, missing, or unenforced tags often turn FinOps into a nightmare. Stijn and Tim introduced Service Groups as the "missing link."

The live demo was an eye opener, showing how Service Groups can provide the cost visibility and accountability that traditional tagging constantly struggles to deliver. This can be thought of as just a virtual container which can contain Azure resources from anywhere within the tenant, across subscriptions.

This allows different teams in your organization to have a different view. For example, a Product Owner may have one Service Group with all the resources for a specific application regardless if it’s in a production or development subscription.

While Service Groups are still in preview, the session suggested they might eventually replace tags, and perhaps even Management Groups as the primary way to assign policies and group resources. At ACA, we aren't convinced they will replace everything just yet, but the potential is undeniable.

Level Up Security

The afternoon took an interesting turn with the session from Roland Guijt “Level Up Your Security: OpenID Connect/OAuth update”.

With the release of OAuth 2.1, Roland highlighted three major protocol improvements:

  • PKCE (Proof Key for Code Exchange) required for authorization code flow
    • It acts like a matching digital ticket stub. It ensures the app that started your login is the same one finishing it, making it nearly impossible for a hacker to intercept the process mid-way.
  • Implicit and resource owner password grant omitted
    • It retires outdated login methods that allowed apps to see your actual password or were easy to trick. This ensures apps never touch your credentials directly, protecting you from leaks and phishing
  • Refresh tokens for public clients must either be sender-constrained or for one-time use
    • It puts a "self-destruct" or "lock" on the digital keys that keep you logged in. If a thief manages to steal one of these keys, they can’t use it to access your account because it will either be invalid or expire immediately.

Conclusion: Full speed ahead to 2026

CloudBrew 2025 is in the books, and it left us with plenty to do and consider.

With Azure Belgium Central officially open, data sovereignty is no longer a buzzword, it’s a baseline. Security is mandatory, AI is becoming integrated in all workflows and governance is finally getting the tools it needs.

Together with our customers and partners, ACA is ready to turn these insights into action. By the time CloudBrew 2026 rolls around, we expect the landscape to have shifted again, and we’ll be ready for it.

Until next time!

Curious how we can help you get more out of your cloud solutions? Get in touch!