Multicloud.is

The Articulation Advantage

Thu, 16 Apr 2026 12:00:00 +0000

The Articulation Advantage

Over the last few months, I (like everyone) have been hard at work first creating innumerable tools, then consolidating them, then reimagining them, and basically iterating over and over again with the ebb and flow of progress that is so powerfully permeating the world of AI today. While this is true in both my work and personal life and has been transformational in both contexts, it’s in the personal context that I’m going to start, mostly because I can talk about tangible outcomes publicly there.

I started off as many do, by building small tools to fulfil specific tasks. After all, this is what I’d have done without AI - identify a challenge that I can solve with technology, and solve for it with a bit of code, or by implementing someone’s passion GitHub project, or whatever it may be. The first tool I built with Claude was something I’d wanted for years - a widget on my phone which could turn on or off our RF controlled gas fire. I had all the pieces to enable this through my existing HomeAssistant setup, but the RF blaster I had found which worked with this fire, had no HA integration. So barring developing an integration myself, I was at the mercy of someone in the community having the same challenge as me, and sadly it was not to be. The problem wasn’t hard, the activation energy to solve it just never quite made sense against everything else competing for my evenings.

It’s not an exaggeration to say that within 30 minutes of kicking off this project, I had a working prototype, and another half hour later I had a fully functional Android app with prompt-free widget which would control the fire, at home or remote. Over the next few months I built other tools to solve unique challenges that I had but weren’t solved in the community, always focused on individual tools (and sometimes HA plugins) rather than a more consolidated approach. This was borne of my experience not just building tools, but supporting the codebase into the long term. I didn’t want to build anything unwieldy that I’d come back to in six months or a year, and think ‘what the hell was I thinking here?’

In January 2026, as we were approaching my wife’s 40th birthday, I decided I’d take on a pretty mammoth coding challenge to gift her something unique. With Zelda being her favourite game franchise, and it also being Zelda’s 40th birthday this year, and with the Ocarina of Time decomp project starting to gain some traction, I decided to change all the signs in Kokiri forest to be birthday messages from her extended friends and family - despite extensive experience in C dating back to the ’90s, I figured that was about as far as I’d get, being unfamiliar with the codebase, and given its status as a decomp and not well documented or signposted.

With Claude Code I had that piece knocked out in around 20 minutes - it took way longer to get the messages than to implement them - and suddenly found myself with loads of time to implement way more. So little by little, I started writing feature requests, refining them, and working with Claude to document and implement them. In the end there was a new functional game, using the child Zelda character model (did you know she has 16 points of articulation to Link’s 18, and isn’t in any way designed to be playable?) as the player model, changing a load of interactions, adding the Triforce as a collectible item, and even adding a whole sub-quest to retrieve the Happy Birhday song, and play it on the ocarina of time to enter the Chamber of Sages and retrieve a final reward. I even managed to get the whole thing loaded on an N64 Cartridge and running on the Analog 3d, to provide that true N64 experience. It was awesome.

All of this took around two weeks of evenings and weekends. I won’t say it was flawless, there was a lot of manual effort I still had to do, but the speed at which I was able to get to grips with a large and unfamiliar codebase was insane, and the quality of documentation we generated as we went made the whole process significantly easier.

With all this said and done, I revisited a lot of my assumptions and process for building my own tools - maybe maintaining and operating a large codebase in the long term as an individual hobbiest wouldn’t be a bad idea any more. Little by little I took all of my tools, and first integrated them into a bespoke Android app which did everything I wanted, attuned just to me, and then over the last few weeks, I’ve been pulling everything together into a single coherent multi-agent system that I can actually grow and maintain over the long haul.

The pattern across all of this, looking back at it, isn’t really about the code. The code is the easy part now. The hard part, the bit that actually determined whether I got something useful or something I’d throw away in a week, was how clearly I could describe what I wanted before I asked for it. And the more I’ve worked across both this personal context and the day job, the more I’ve become convinced that this observation generalises far beyond hobby projects.

The Real Differentiator

There’s a quiet assumption running through most conversations about AI and the future of work. It goes something like this: the people who understand technology the best will benefit the most. Engineers, developers, data scientists. The deeply technical, the people closest to the metal.

I think that’s incomplete.

The real differentiator in AI-driven workflows isn’t technical depth. It’s the ability to clearly and succinctly articulate what you want to achieve. The people who get the best outcomes aren’t necessarily the ones who understand transformers or can hand-write CUDA kernels. They’re the ones who can collapse the ambiguity in their own thinking into a clear, constrained, well-structured request.

That’s a communication skill. And it changes everything about who gets to build things.

The Spec Is the Product

Consider two people asking an AI to build them a dashboard. Person A says “make me a dashboard.” Person B says “I need a single-page view showing weekly trend lines for three KPIs, with a date range toggle, aimed at a non-technical audience who will glance at this for thirty seconds in a Monday morning meeting.”

Person B gets something usable on the first pass. Person A burns five rounds of back-and-forth, five times the token spend, and arrives at roughly the same place. The gap between them isn’t technical knowledge, it’s precision of thought, expressed through language.

And that token spend matters more than people tend to acknowledge. Every round of “no, not like that, more like this” is real money, real compute, real latency. The person who nails the spec on the first pass isn’t just faster, they’re running at a fraction of the cost of the person who iterates their way to the same outcome. At individual scale, that’s the difference between a few pounds and a few tens of pounds. At organisational scale, across hundreds of engineers and thousands of requests a day, that compounds into something that shows up on the balance sheet.

This maps closely to a skill that has always mattered in engineering but never got enough credit: requirements gathering. The people who were good at writing specs, defining acceptance criteria, and decomposing vague goals into concrete deliverables were always disproportionately effective. AI just makes that leverage ratio visible, measurable, and immediate.

In a spec-driven development workflow, the spec isn’t a document that gets handed to someone else for interpretation. It IS the build instruction. The person who writes the spec is, in a very real sense, building the product. AI is just the translation layer between intent and implementation.

Phenomenal Cosmic Power, Limited Imagination

There’s another side to the articulation coin that’s uncomfortable to address as well - being able to clearly describe what you want is only half the battle. You also have to be able to imagine what’s worth wanting in the first place.

When Hal Jordan first got a Green Lantern ring, a mystical object able to create literally anything he can imagine and has the will to create, all he could create were things he already knew, like cars and similar. Phenomenal cosmic power is irrelevant without the imagination to use it. The ring will render whatever you can hold in your head, at full fidelity, instantly. But if your head is full of yesterday’s solutions, that’s all you’ll ever build.

AI is the ring. It’ll happily build you exactly what you ask for. The constraint isn’t capability any more, it’s the size and shape of the space you’re willing to imagine within. The person who says “build me a better version of our ticketing system” gets a better ticketing system. The person who says “what if we didn’t need tickets at all, and the system just noticed and fixed these issues itself” gets something categorically different.

This is where the real asymmetry opens up. Articulate but unimaginative people will use AI to build faster versions of what already exists. Imaginative but inarticulate people will have vivid ideas that never quite materialise, because they can’t collapse them into a form the ring can render. The people who do both, who can imagine beyond the current shape of a thing AND describe that imagined thing with enough precision to build it, are the ones who’ll define what the next decade of software actually looks like.

The Technical PM as Product Builder

If articulation is the core skill, then technical product managers might be among the best-placed people to become product builders in this new era. They are one of the roles that sits at exactly the right intersection. They understand the solution space well enough to know what’s possible and what’s a hand-wave over enormous complexity, and they’ve spent years, sometimes decades, refining the skill of turning fuzzy intent into structured, actionable requirements.

What makes this work is that the traditional handoff starts to collapse. The old model was: PM writes spec, engineer interprets spec, engineer builds product, PM reviews product, refinement ensues, and everyone argues about what “done” means. When the spec becomes the direct input to AI-driven development, that entire interpretation gap disappears. Fewer misunderstandings, fewer “that’s not what I meant” cycles, faster iteration, and far less token burn along the way.

The “technical” part of technical PM still matters, though. You need enough engineering intuition to write specs that are implementable. A non-technical PM writing specs for AI would hit the same walls they hit with human engineers, just faster and with less patience from the other side.

The people who thrive will be the ones who combine domain knowledge with expressive precision.

What Happens to Engineering?

This is the uncomfortable question, and I think the honest answer is that a large portion of traditional engineering roles will shrink through natural attrition over time. Not a dramatic cliff, not mass layoffs, just a gradual shift where, as people leave or retire or move on, fewer roles get backfilled at the same level. The work doesn’t disappear, it gets absorbed differently.

What survives and even grows in value is the work at the extremes. At one end, deep systems engineering: the people who understand why your cluster is dropping packets, or how to squeeze latency out of a hot path. AI is not good at that kind of reasoning today. At the other end, architect-level thinkers who can hold an entire system in their heads and make the structural decisions that determine whether something scales or falls over at ten times the load.

The middle layer, the “take this well-defined ticket and implement it” work, is exactly where AI is strongest. And that’s where attrition bites hardest.

The Lifecycle Problem Nobody Is Talking About

This is where things get somewhat trickier, and where most of the current AI enthusiasm skips a step. You can define a spec today, point it at a model, and launch a working product. That’s real, that works. But what does the development and support lifecycle look like for the next five years?

The model you use to build the next feature request might be completely different from the one that built the original implementation. Different architecture, different training data, different opinions about error handling, state management, code structure. It’s like handing your codebase to a new engineer for every update, except worse, because a new human engineer at least has consistent training, shared conventions from their career, and the social pressure of code review to keep them aligned with what already exists.

A different model generation has none of that. It might satisfy your spec perfectly while producing an implementation that clashes with everything already in the codebase. Not bugs, exactly, but architectural drift. The kind of creeping inconsistency that makes a codebase increasingly expensive to work with over time. Technical debt by default rather than by neglect.

And here’s the compounding cost nobody’s pricing in yet: that drift makes every subsequent request more expensive. The model has to reconcile more conflicting patterns, the spec has to specify more to constrain it, and the refinement cycles grow longer as the codebase becomes harder to reason about. A product built without long-term coherence in mind doesn’t just cost more to maintain in human terms, it costs more to maintain in tokens, on every single interaction, for the rest of its life.

The Constitution as the Most Important Artefact

This is where the concept of a project constitution becomes not just useful but utterly vital.

In a spec-driven development workflow, you typically have two layers of instruction. The spec defines what you’re building right now. The constitution defines how everything should be built, always. Coding patterns, error handling conventions, state management approaches, naming standards. The architectural guardrails that keep a codebase feeling like it was written by one consistent team, even if ten different models touched it over five years.

Think about what the constitution is actually doing. It’s encoding the kind of architectural judgement that normally lives half in documentation and half in the accumulated instincts of the senior people on a team. “We always handle errors this way. We structure state like this. We never do X.” Good teams try to write this down already, but it tends to exist as fragments scattered across ADRs, wiki pages, and the comments on old pull requests. The constitution gathers it into one place and commits to keeping it current, because any model in any generation is going to consult it before touching the codebase.

Without a strong constitution, you get the patchwork problem. Module A uses one pattern, module B uses another, and the seams between them accumulate subtle inconsistencies that compound over time. With a strong constitution, you get continuity. The spec can change, the model can change, but the soul of the codebase stays consistent. And every interaction with that codebase, from the first feature to the thousandth, runs more cheaply than it would in a codebase without that scaffolding, because the model has less to reconcile and the human has less to correct.

The spec defines what you’re building now. The constitution defines how everything should be built, always.

The Constitution Author

All of which raises the obvious question: who actually writes this thing, and who maintains it over the long term as the organisation, the codebase, and the models themselves evolve?

This is, I think, the highest-leverage technical role into the near and foreseeable future (though admittedly I don’t see that far), and it’s a genuinely new one. It isn’t quite the traditional software architect, who makes structural decisions about a specific system. A constitution author works one level up from that, codifying the organisation’s principled commitments about how any system should be built, in a form durable against model churn. An architect designs the building. A constitution author writes the building code that every future architect has to design against.

It isn’t quite the deep systems expert either, though it’s adjacent. The systems person knows why your cluster is dropping packets, which is diagnostic and reactive, working from symptoms back to cause. The constitution author is prescriptive and prospective, working from principles forward to prevent whole classes of problems from ever entering the codebase in the first place.

What a good constitution captures isn’t the stuff that already gets written down. Any competent engineering team documents its APIs, its runbooks, its architectural decision records. Tribal knowledge is correctly treated as a liability and ruthlessly written out of existence wherever it’s found. The constitution targets something harder: the accumulated judgement about why the team does things the way it does, the trade-offs that were considered and rejected, the patterns that have proven robust across dozens of features. That judgement has historically been difficult to extract from the people who hold it, not because teams don’t try, but because it’s tacit, context-dependent, and most easily transmitted through code review and conversation. The constitution forces it into an explicit, durable form, because the “reviewer” is now a model with no memory of last quarter’s debates and no social context for “we tried that in 2023 and it didn’t work.”

The person who does this well needs three things that rarely combine in one human: deep technical judgement to know what the right patterns actually are, strong architectural instinct to know which decisions matter in the long term versus which are just preferences, and the articulation skill this whole piece is about, to encode all of it in a document precise enough to constrain model behaviour but flexible enough to live for a decade. That last part is what makes this a genuinely new role rather than a rebadged principal engineer. The skills are ancient, the job isn’t.

A New Shape for Software Teams

If you follow these threads to their logical conclusion, the shape of a software team starts to look very different. The highest-value roles aren’t writing code. They’re writing constitutions, defining architectural principles, curating codebases for coherence, and articulating product intent with enough precision that AI can execute on it reliably.

The compounding effects are what make this so stark. The articulate, technically grounded, product-centric person with a long-term view doesn’t just build a product that survives its passage between owners and models. They build one that costs less to operate, iteration after iteration, because every request lands cleaner, every refinement cycle is shorter, and every model handoff is smoother. The difference between them and someone iterating their way through ambiguity isn’t incremental. It compounds.

Software has been trending this way for a long time. The industry has spent the last decade or more taking soft skills seriously, elevating communication as a hiring criterion, investing in the craft of writing specs and RFCs and architectural decision records. What AI does is take that trend and sharpen it to a point. Articulation stops being a career enhancer and starts being the actual mechanism of production. And imagination stops being a nice-to-have attribute of creative people and becomes the ceiling on what any individual can build.

The people who will build the future aren’t the ones who can write the most code. They’re the ones who can imagine something worth building, succinctly articulate it, and in so doing, make it reality.

Push the boundaries of your imagination. Create something new and exciting, with as little back-and-forth as possible. Conserve those tokens, and build something awesome.

The AI Cold War Goes Operational

Sat, 11 Apr 2026 19:00:00 +0000

The AI Cold War Goes Operational

For three years, the Frontier Model Forum has been a place where AI labs go to make safety pledges and appear responsible in front of regulators. On April 6, 2026, it became something else entirely: a coordinated threat-intelligence operation against a named external adversary.

OpenAI, Anthropic, and Google announced they are now sharing attack pattern data through the Forum to detect and block what security researchers call adversarial distillation - a technique by which Chinese AI companies have allegedly been systematically stealing the capability of Western frontier models at industrial scale.

That three companies who compete as intensely as these three are doing this openly is, by itself, a signal worth paying attention to.

What Is Adversarial Distillation?

The technique is straightforward and, if the allegations are accurate, remarkably effective. Rather than building a frontier model from scratch (which requires years of research investment and hundreds of millions of dollars in compute), you create tens of thousands of fake accounts, flood your competitor’s API with carefully engineered queries, collect the responses, and train your own model on the outputs. The target lab’s years of RLHF, safety training, and capability development become your training dataset. You pay API fees instead of GPU clusters.

Anthropic says it documented 16 million such exchanges from three Chinese companies (DeepSeek, Moonshot AI, and MiniMax) running through approximately 24,000 fraudulently created accounts. OpenAI has made separate allegations that DeepSeek used “new, obfuscated methods” to distill its models, and submitted a formal memo to the House Select Committee on China making that case. US officials estimate the practice costs American AI labs billions annually.

For context: the catalyst for all of this traces to early 2025, when DeepSeek released its R1 reasoning model. The release triggered immediate panic across the US AI industry because R1 performed at or near frontier levels at a fraction of the expected cost. What we now know is that investigations into how that was achieved have been building quietly ever since, and what started as separate internal detection efforts has now consolidated into coordinated cross-lab intelligence sharing.

Why This Matters Beyond the Headlines

The obvious frame here is geopolitical: US vs China, IP theft, technology competition. That frame is accurate but incomplete. For enterprises building on AI infrastructure, there are a few more practical implications.

The frontier is now contested territory. If the API surface of Claude, ChatGPT, and Gemini is actively being weaponised as a training data pipeline, then the model quality you pay for today has partially funded your future competitors’ capabilities. That’s not a reason to stop using these services, but it does add texture to what “investing in AI” means at a national level.

Model capability is increasingly geopolitically entangled. The Frontier Model Forum was co-founded with Microsoft in 2023. Its original mandate was safety coordination: responsible scaling policies, red-teaming standards, that kind of thing. The fact that it has now pivoted to active threat-intelligence operations means the governance infrastructure around frontier AI is doing something it was never designed for. Microsoft, as a co-founder and the company that has bet most aggressively on OpenAI’s models through Azure, has a significant stake in how this plays out.

The open/closed divide just got more complex. This week also saw Zhipu AI release GLM-5.1, a 744-billion parameter open-weight model under the MIT license that reportedly beats Opus 4.6 and GPT-5.4 on real-world software engineering benchmarks. The irony is sharp: if the allegations against Zhipu’s associates are accurate, open-weight releases from that ecosystem become a policy problem as much as a technical one. You can’t un-release a model under MIT.

The Practitioner Question

For those of us running hybrid infrastructure and making decisions about which AI services to build on, the question this raises isn’t whether to use AI APIs. It’s about the stability and predictability of the services you’re relying on.

The measures the three labs are now taking to detect and block distillation attempts include tighter query pattern analysis, account behaviour monitoring, and coordinated blocklists. The practical effect is that API behaviour may become more restrictive over time, and novel query patterns (including legitimate agentic workloads) may occasionally trigger false positives. If you’re running automated pipelines against these APIs at scale, it’s worth keeping an eye on how the detection systems evolve.

More broadly: the fact that the three biggest AI labs have moved from competition to coordination on this issue suggests they view the threat as existential enough to override commercial interests. That’s a calibration signal. If they’re treating it that seriously, the scale of what’s been happening is probably larger than the public disclosures suggest.

A Note on the Forum Itself

The Frontier Model Forum’s first two years were characterised by critics as largely performative, a vehicle for appearing cooperative on safety while continuing to race on capability. Whether that characterisation was fair or not, this activation as an operational threat-intelligence body is a material change in function. It’s now doing something concrete, with named adversaries, documented evidence, and active countermeasures.

The question worth watching is whether this coordination extends beyond distillation defence into other areas, and what it means for the regulatory posture of AI labs globally when the three biggest players are explicitly framing their cooperation as a response to a state-affiliated threat.

This is no longer theoretical AI governance. It’s infrastructure security at civilisational scale.

Sources: Bloomberg, April 6 2026 | RoboRhythms analysis | WhatLLM April 2026 model roundup

Claude Mythos and the Cybersecurity Reckoning

Fri, 10 Apr 2026 19:00:00 +0000

Claude Mythos and the Cybersecurity Reckoning

There’s a new AI model that Anthropic says is more capable than anything they’ve built before. It sits above Opus in their model hierarchy - a whole new tier called Mythos. And you can’t use it.

That’s not an accident. Anthropic has made a deliberate decision not to release Claude Mythos publicly. Their reason: the model is so capable at finding and exploiting software vulnerabilities that giving it general availability would be irresponsible. Let that land for a second.

What Mythos Can Do

The numbers from Anthropic’s technical report are striking. Compared to Opus 4.6:

SWE-Bench Verified: 80.8% → 93.9% (+13 points)
SWE-Bench Pro: 53.4% → 77.8% (+24 points)
USAMO (math olympiad): 42.3% → 97.6% (+55 points)
Humanity’s Last Exam: +17 points, without tools

Across the board benchmark jumps that would normally be enough to generate a wave of launch blog posts and product announcements. But the cybersecurity findings are what forced Anthropic’s hand.

During internal testing over the past month, Mythos Preview autonomously identified thousands of previously unknown zero-day vulnerabilities. Not across a handful of niche codebases - across every major operating system (Linux, Windows, FreeBSD, OpenBSD) and every major web browser. The oldest vulnerability it found was a 27-year-old bug in OpenBSD - a system with a reputation for security that borders on paranoid.

The exploits it generates aren’t simple either. In one documented case, Mythos wrote a browser exploit that chained four separate vulnerabilities together, executing a JIT heap spray that escaped both the renderer and OS sandboxes. It autonomously constructed privilege escalation exploits on Linux via subtle race conditions and KASLR bypasses. It wrote a remote code execution exploit against FreeBSD’s NFS server using a 20-gadget ROP chain split across multiple packets - granting unauthenticated root access.

This isn’t theoretical AI capability. This is a model that, when pointed at real production software, finds real exploits faster than most human security researchers. Over 99% of the vulnerabilities found remain unpatched, which is why Anthropic is saying very little about specifics right now.

Project Glasswing

Rather than a general release, Anthropic launched Project Glasswing - a controlled consortium of more than 40 organisations with access to Mythos Preview exclusively for defensive security work. The initial partners include Apple, Google, Microsoft, Nvidia, Amazon Web Services, CrowdStrike, Palo Alto Networks, Cisco, JPMorgan, and the Linux Foundation.

The idea is to use Mythos to find and patch vulnerabilities before attackers can discover and weaponise them. Anthropic is backing this with $100 million in usage credits for the initiative and $4 million in direct donations to open-source security projects.

Dario Amodei framed it bluntly: “The dangers of getting this wrong are obvious, but if we get it right, there is a real opportunity to create a fundamentally more secure internet and world than we had before the advent of AI-powered cyber capabilities.”

Why This Matters Beyond Anthropic

A few things are worth sitting with here.

The model was leaked before it was announced. Fortune discovered references to Mythos in a publicly accessible Anthropic data cache in late March. Cybersecurity stocks fell on the news, before Anthropic had said anything officially. That’s a signal of how seriously the market is taking AI’s offensive security potential.

The “safety lab” framing is being stress-tested. Anthropic built its identity around being the careful, responsible frontier lab. The same week they announced Project Glasswing, they were also dealing with public fallout from a court ruling about their relationship with the Pentagon. Whether the Glasswing announcement is good PR management or genuine responsible deployment - and it can be both - is a reasonable question. The technical report reads as sincere. The capabilities it describes are real.

This changes the threat model for everyone who runs software. If a model with these capabilities can be accessed by 40+ partner organisations, it cannot be long before similar capabilities are accessible more widely - through adversarial development, jailbreaks, or competing labs who don’t apply the same restraint. Glasswing is Anthropic’s attempt to get defenders ahead of that curve. The question is whether six months, or a year, of coordinated patching is enough of a head start.

The Practitioner Angle

For those of us running infrastructure - whether that’s Azure Local clusters, cloud workloads, or hybrid environments - the immediate takeaway is that the vulnerability surface you thought you understood is larger than you knew. Bugs that have existed undetected for a decade or more are being found by automated systems, at scale.

The coordinated disclosure process Anthropic is running through Glasswing means patches will come, but the timeline is uncertain, and the breadth of affected software is wide. It’s a good time to ensure your patching cadence is tight, your network segmentation is real rather than theoretical, and your incident response runbooks are current.

It’s also worth noting that the organisations in the Glasswing consortium include the major cloud providers. If Microsoft is using Mythos to scan Azure infrastructure, that’s material to anyone relying on Azure as part of their hybrid architecture. The patching won’t be visible to you directly, but the outcome should be a measurably more secure platform over the next 12 months.

A Closing Thought

The thing that sticks with me is the deliberate choice not to release. Every AI lab in the world is under commercial pressure to ship. Anthropic sat on a model that would generate enormous revenue and attention, and decided the risk was too high. That’s not a marketing decision. Whether you think their caution is calibrated correctly or not, the underlying reality - that this model’s capabilities represent a genuine inflection point for software security - appears to be the consensus view across the security community.

We’ve been talking about AI changing cybersecurity for years. Mythos is the first concrete demonstration that the change has already arrived.

Sources: Anthropic Project Glasswing | Anthropic Red Team Report | CNBC | NextBigFuture

Azure Local 2603: From Cloud-Connected to Cloud-Operated

Sun, 05 Apr 2026 00:00:00 +0100

Azure Local 2603: From Cloud-Connected to Cloud-Operated

The March 2026 release of Azure Local - version 12.2603.1002.15 - landed quietly enough. A new OS baseline (26100.32522), .NET 8.0.25, updated Kubernetes versions for AKS Arc (1.31 through 1.33, with 1.30 dropped), KMS v2 migration guidance. Nothing that would make headlines on its own.

But there’s a more interesting story underneath the release notes, and it’s one that matters if you’re deploying or planning Azure Local in an enterprise environment: Microsoft is quietly but deliberately shifting Azure Local from a cloud-connected platform to a cloud-operated one.

That distinction might sound like marketing language. It’s not.

What Cloud-Connected Meant

For most of Azure Stack HCI’s life - through 23H2 and into the early 24H2 releases - “cloud-connected” was accurate. The platform ran on your hardware, in your datacentre, and used Azure for a defined set of functions: registration, billing, monitoring extension delivery, and portal visibility. The operational centre of gravity was local. You’d SSH into nodes, run PowerShell on the cluster, manage updates through local tooling with Azure providing the plumbing.

This was a significant improvement over traditional on-premises HCI. The Arc-based management model brought Azure consistency to local infrastructure in a way that older approaches never managed. But the fundamental assumption was that local infrastructure was administered locally.

What Cloud-Operated Means

The 2603 release - and honestly, the direction of travel over the past several release cycles - tells a different story. Microsoft is increasingly building Azure Local to be managed from Azure by default, with local administration as the secondary model.

Look at the 2603 feature emphasis: cloud-based deployment and updates, cloud-based monitoring, simplified VM management through the Azure portal. Each of these points in the same direction: the control plane is Azure, and local tooling is for edge cases.

This isn’t a surprise if you’ve been watching the product closely. Each release has tightened the operational dependency on Azure. Deployment now happens through the Azure portal using the Arc-based flow. Updates are orchestrated through the Lifecycle Manager, itself a cloud-managed service. Monitoring telemetry flows through Azure Monitor. The VM management experience in the Azure portal has improved to the point where it’s a credible primary interface for day-to-day operations.

The 2603 OS update - moving every deployment, new and existing, to 26100.32522 - reinforces this. There’s now a single OS baseline across the platform, managed and distributed through Azure. The OEM path for integrated systems (download from the Azure portal, work with your OEM on drivers) formalises this operational model.

Why This Matters for Enterprise Deployments

The shift to cloud-operated isn’t just an architectural preference. It has real operational consequences.

It reduces the local skills burden. Managing Azure Local through the Azure portal, Azure Monitor, and Azure Policy is substantially more accessible than the equivalent PowerShell and WAC workflows. Teams that are already Azure-fluent can operate the platform without deep HCI-specific knowledge.

It changes the dependency model. A cloud-operated platform needs reliable cloud connectivity. For deployments where internet connectivity is intermittent or restricted, this creates friction. Microsoft has addressed this with the disconnected operations model for sovereignty scenarios, but most enterprise deployments in regional offices and secondary datacentres need to think carefully about what happens to management workflows when the Azure connection is slow or unavailable.

It tightens the support story. When deployment, updates, and monitoring all flow through Azure, Microsoft has much better visibility into what’s running and where problems are occurring. That’s good for support outcomes, but it also means your cluster’s operational state is increasingly visible to Microsoft as a matter of function rather than opt-in telemetry.

It accelerates the pace of feature delivery. Decoupling features from OS updates - a design principle established in 23H2 - means Microsoft can ship capabilities through Arc Extensions without requiring OS updates. The cloud-operated model extends this: Microsoft can update the management plane, improve monitoring capabilities, and adjust deployment workflows without customers needing to do anything.

The AKS Picture

The Kubernetes updates in 2603 are worth noting separately. Supporting Kubernetes versions 1.31 through 1.33 keeps the platform current with upstream Kubernetes, and the addition of version 1.33 - which reached GA upstream in early 2026 - suggests Microsoft’s alignment with the Kubernetes release cycle is improving.

The KMS v2 migration is significant for anyone running AKS workloads at scale. KMS v1 provided encryption key management for Kubernetes secrets, but v2 is the current standard with better performance and security characteristics. The guidance to redeploy clusters using KMS v2 is operationally disruptive - this is a redeploy, not an upgrade - but it’s the right move. If you’re running AKS on Azure Local, this should be on your planning horizon now.

The deprecation of Windows Server 2019 node pools is less surprising. The focus for Windows containers on Azure Local has been Windows Server 2022, and that’s where enterprise workloads should be targeting.

What 23H2 End of Support Means

A separate but related point: Azure Stack HCI, version 23H2 OS reaches end of support in April 2026 - now. If you’re still on 23H2, the window has closed.

The 23H2 feature release train ended with the October 2025 release (version 11.2510). The 24H2 OS baseline has been the active development target for several releases. If you haven’t completed the upgrade planning work, this is now urgent rather than optional.

The upgrade path from 23H2 to 24H2 is documented and tested, but it requires planning. Start there.

The Honest Assessment

Azure Local 2603 is a maintenance release with strategic weight behind it. On its own, the feature list is incremental. In the context of where the platform has come from and where it’s going, it’s another step in a deliberate march toward a cloud-operated infrastructure model.

For operators, this is largely good news. The platform is getting simpler to manage, more consistent in behaviour, and better integrated with the Azure toolchain. For architects, it requires honest thinking about connectivity, dependency, and what cloud-operated means for your specific environment.

The platform that existed when I first wrote about Azure Stack HCI 23H2 in 2024 looked like on-premises infrastructure with cloud integration bolted on. What exists now in 2026 looks like cloud infrastructure that happens to run in your datacentre. That’s a meaningful shift, and 2603 is another confirmation of the direction.

Deploying Azure Local on Dell AX hardware? The Dell Solution Builder Extension handles update orchestration and maintains solution-level validation through each release cycle. Worth understanding if you’re planning your 2603 update cycle.

The State of Azure Local in 2026

Thu, 12 Mar 2026 00:00:00 +0000

The State of Azure Local in 2026

Two years ago this month, I wrote my first post on this blog about what Azure Stack HCI is in 2024 . At that time, Azure Stack HCI 23H2 had just launched, the Arc Resource Bridge was new, and the Premier Solution category had been freshly announced. The platform was a cloud-connected operating system that was in the process of becoming something much more.

Looking at where we are now in March 2026, the transformation has been nothing short of remarkable. It feels like the right moment to take stock.

The Journey

Let me trace the arc of the past two years, because the speed and direction of change is the story.

In early 2024, Azure Stack HCI 23H2 was a hyperconverged infrastructure solution running on up to 16 nodes, with an Arc Resource Bridge providing Azure connectivity, and Azure Arc Extensions delivering features. It was impressive for what it was, but it was still fundamentally an HCI platform.

The Broadcom acquisition of VMware in late 2023 and the subsequent licensing upheaval through 2024 created a market disruption that accelerated adoption and interest in alternatives. Azure Stack HCI, and then Azure Local, was a primary beneficiary of that disruption.

Windows Server 2025 landed in November 2024, bringing a new kernel generation and features like native NVMe and hotpatching that strengthened the foundation.

The rebrand to Azure Local at Ignite 2024 signalled a strategic repositioning. No longer an HCI product, but cloud infrastructure for distributed locations. The new versioning model with the 2411 release made the update cadence cleaner and more predictable.

Through 2025, the platform expanded in every direction. AKS matured for on-premises Kubernetes. GPU support enabled AI workloads at the edge. Dell AX achieved Premier Solution status . Sovereign cloud became a primary use case. Hotpatching reduced operational overhead. PowerFlex and then PowerStore brought enterprise storage options.

And then Ignite 2025 blew the doors open. Multi-rack scale to hundreds of servers. SAN support. Blackwell GPUs. M365 Local . Disconnected operations . The platform went from an HCI solution to a comprehensive private and sovereign cloud platform in the space of two years.

Where We Are Now

In March 2026, Azure Local is:

A multi-scale platform. From single node edge deployments to 16-node HCI clusters to multi-rack deployments with hundreds of servers. The deployment models now cover everything from a branch office closet to a full data centre floor.

A multi-storage platform. Storage Spaces Direct for HCI, PowerFlex for disaggregated software-defined storage, PowerStore and other vendors for SAN connectivity. The “one size fits all” storage story is gone, replaced by choice and flexibility.

An AI-ready platform. NVIDIA GPU support from professional RTX cards to Blackwell Server Edition, with support for thousands of AI models running locally. Sovereign AI is a real and growing use case.

A sovereign cloud platform. Connected, intermittently connected, or fully disconnected. M365 Local for productivity workloads. Disconnected AKS for containers. The full spectrum of connectivity modes is now supported.

An Azure platform. Managed through Azure, billed through Azure, governed through Azure Policy, monitored through Azure Monitor, secured through Azure security services. For connected deployments, the consistency with public Azure is genuine and meaningful.

The Dell AX Perspective

Dell’s position in the Azure Local ecosystem has strengthened considerably over these two years. The AX system portfolio covers the full range of deployment scenarios, from compact edge nodes to high-performance data centre systems. Premier Solution status provides the validation framework that enterprise customers require. And the expanding storage portfolio, with PowerFlex for software-defined storage and PowerStore for enterprise SAN, gives customers genuine choice in how they architect their environments.

The Dell AX system has a clear and straightforward go-to-market story. It’s Dell’s premier hardware system for Azure Local, and that simplicity in positioning reflects the maturity of the solution.

The integrated support experience between Dell and Microsoft, the CI/CD validated updates through the Solution Builder Extension, and the expanding hardware portfolio position Dell AX well for whatever comes next.

What’s Next

Predicting the future is always a fool’s errand, but there are a few directions that seem probable.

Scale will continue to expand. The multi-rack architecture introduced at Ignite 2025 is the beginning, not the end. Expect larger deployments, more sophisticated resource management, and better tooling for managing large estates of Azure Local instances.

Storage integration will deepen. SAN support is Fiber Channel first, but other protocols are on the roadmap. The integration between Azure Local management and storage lifecycle management will tighten. Expect a more unified operational experience across compute and storage.

AI workloads will grow. As models get smaller and more efficient, and as inference hardware gets more capable, the percentage of AI workloads running on-premises will increase. Azure Local’s GPU support and disconnected AI capabilities position it well for this trend.

Sovereign cloud will become mainstream. What’s niche today will be normal tomorrow. Sovereignty requirements are expanding beyond government and defence into regulated industries more broadly. Azure Local’s ability to operate across the connectivity spectrum gives it a structural advantage here.

The ecosystem will mature. More ISVs will certify their applications for Azure Local. More Azure services will be available locally. The gap between “Azure in the cloud” and “Azure in your data centre” will continue to narrow.

Reflections

When I started this blog, I wanted to explore the multicloud ecosystem from a practical, grounded perspective. The past two years have been a fascinating time to be doing that. The evolution of Azure Stack HCI into Azure Local has been one of the most significant infrastructure transformations I’ve witnessed in my career, and it’s happened at a pace that’s been challenging to keep up with even from the inside.

What’s most impressive to me is not any individual feature or announcement, but the coherence of the overall strategy. Every piece, from the Arc integration to the OEM partnership model to the sovereign cloud capabilities, fits together into a vision for how on-premises infrastructure should work in a cloud-first world. Not as a separate thing that happens to connect to the cloud, but as a genuine extension of the cloud to wherever you need it.

Whether you’re running a single node at a remote edge location or hundreds of servers in a sovereign data centre, the platform is designed to serve you. And with Dell AX providing the hardware foundation, the full stack from silicon to cloud is validated, supported, and continuously improving.

It’s been quite a ride. I’m looking forward to seeing where the next two years take us.

Disconnected Azure Local: Truly Sovereign Infrastructure

Thu, 19 Feb 2026 00:00:00 +0000

Disconnected Azure Local: Truly Sovereign Infrastructure

Earlier this week, Microsoft published an update on their Sovereign Cloud strategy, announcing enhancements to governance, productivity, and support for large AI models running in fully disconnected environments. This builds on the disconnected operations GA announced at Ignite 2025 , and it’s worth taking stock of what’s now possible with Azure Local when there is absolutely no connection to the internet.

Because let’s be honest, “disconnected” has been a word thrown around loosely in the hybrid infrastructure world for a long time. Most platforms that claim disconnected or edge capability still require some level of periodic connectivity for updates, licensing validation, or management operations. Azure Local’s disconnected operations capability is genuinely air-gapped. No network connectivity to Azure, no phone-home requirements, no dependency on external services for day-to-day operation.

What Disconnected Operations Looks Like

In a fully disconnected Azure Local deployment, everything that normally flows through Azure has to be handled locally.

Deployment is performed using local tooling and offline media. The Azure Local OS image, the Arc Resource Bridge components, and the Solution Builder Extension are all installed from local sources. There’s no Arc registration with Azure, because there’s no Azure to register with.

Management is performed through local management tools rather than the Azure portal. This is the most significant operational difference from a connected deployment. You lose the Azure portal experience, Azure Policy, Azure Monitor, and the other Azure management services that connected deployments rely on. In exchange, you get complete independence from any external service.

Updates are applied through an offline process. Microsoft provides update packages that can be transferred to the air-gapped environment through approved media transfer processes (the specifics of which will depend on the security requirements of the environment). Dell’s Solution Builder Extension similarly provides offline update packages for firmware and driver updates.

Lifecycle management works, but it requires more manual orchestration than in a connected environment. The automated, Azure-driven update process that connected deployments enjoy is replaced by a locally-driven process that requires more operational involvement.

Who Needs This

I touched on the target audience in my M365 Local post last month, and the customer base for disconnected Azure Local overlaps significantly.

Defence and intelligence organisations are the most obvious consumers. Classified environments are air-gapped by mandate, and the compute and storage requirements within those environments are growing as AI, analytics, and modern applications move into classified spaces.

Critical national infrastructure operators in energy, water, transportation, and telecommunications increasingly need modern compute infrastructure in environments that are deliberately isolated from the internet for security reasons. SCADA and ICS environments have historically run on legacy infrastructure precisely because modern alternatives required internet connectivity.

Diplomatic and forward-deployed operations need compute and collaboration capability in locations where reliable internet connectivity doesn’t exist. Military deployments, embassy operations, scientific research stations, disaster response, all of these scenarios benefit from modern infrastructure that works without connectivity.

Regulated industries in specific jurisdictions face requirements that mandate not just data residency, but operational isolation. The data must stay local, the management plane must stay local, and there can be no external dependency.

The AI Dimension

One of the more recent additions to the disconnected story is support for running large AI models locally. Microsoft’s February announcement specifically called out support for AI models in disconnected environments, building on the NVIDIA GPU support that’s been maturing on Azure Local.

This is significant because AI workloads in sovereign environments are one of the fastest growing use cases. Defence organisations want to run AI models against classified data. Healthcare providers want to run diagnostic AI against patient data that can’t leave the facility. Financial institutions want to run fraud detection models against transaction data that’s subject to strict handling requirements.

The combination of Azure Local’s disconnected operations, NVIDIA GPU hardware, and the ability to deploy AI models locally creates a sovereign AI platform that addresses requirements that were previously unmet. You can train models in a connected environment (or acquire pre-trained models), transfer them to the air-gapped environment through approved processes, and run inference locally against sensitive data that never leaves the secure boundary.

The Dell Perspective

For disconnected deployments, the hardware partner matters even more than in connected scenarios. When you can’t phone home for support, when you can’t download firmware updates from the internet, when you can’t open a remote support session, the reliability and supportability of the hardware becomes critical.

Dell AX nodes are designed with these scenarios in mind. The Premier Solution validation means the hardware, firmware, and drivers have been tested against the Azure Local software before it reaches you. The offline SBE update process provides a validated, repeatable mechanism for applying hardware updates without internet connectivity. And Dell’s support organisation has experience supporting air-gapped environments in defence and government contexts.

The supply chain is also a consideration. For classified environments, hardware procurement often involves specific supply chain requirements around country of origin, handling, and chain of custody. Dell’s manufacturing and logistics capabilities can accommodate these requirements, which is an important practical consideration that’s easy to overlook when evaluating platforms on features alone.

The Trade-offs

I want to be straightforward about the trade-offs of running disconnected. You lose a lot.

You lose the Azure portal experience. You lose Azure Policy. You lose Azure Monitor. You lose the automated update pipeline. You lose the ability to quickly spin up new Azure services. You lose the hybrid cloud story entirely, because there’s no cloud to be hybrid with.

What you get in return is sovereignty, independence, and security isolation. For the environments that need this, there’s no substitute. But for environments that don’t strictly require disconnected operation, the connected or intermittently connected deployment models provide a much richer operational experience.

The decision to go fully disconnected should be driven by genuine requirements, not by a vague sense that “disconnected is more secure.” Connected Azure Local deployments are secured by Azure’s security infrastructure, which is formidable. Disconnected deployments trade that security investment for isolation, and that trade-off should be made with eyes wide open.

Where We Are

Fully disconnected Azure Local with M365 Local, AI workloads, and enterprise storage is a platform that simply didn’t exist two years ago. The pace at which Microsoft and Dell have brought this capability to market is impressive, and it addresses a set of customer requirements that have been underserved for far too long.

If you’re in one of the sectors or scenarios where disconnected operation is a requirement, this is the most capable platform available for running modern workloads in an air-gapped environment. It’s not perfect, the operational overhead is real, and the feature set is necessarily narrower than connected deployments. But it’s functional, it’s supported, and it’s here. That’s a significant milestone.

Microsoft 365 Local: Running Exchange and SharePoint On Your Terms

Thu, 15 Jan 2026 00:00:00 +0000

Microsoft 365 Local

If you’d told me five years ago that Microsoft would be shipping Exchange Server and SharePoint Server to run on on-premises infrastructure managed through Azure, I’d have questioned your sanity. The entire Microsoft strategy for the better part of a decade has been to move productivity workloads to the cloud. Microsoft 365, Teams, Exchange Online, SharePoint Online, the trajectory has been consistently and emphatically cloudward.

And yet here we are. Microsoft 365 Local is now generally available, running core M365 server workloads natively on Azure Local. Exchange Server, SharePoint Server, and Skype for Business Server can be deployed on your Azure Local cluster, in your building, under your control. Connected mode is available now, with disconnected mode for fully air-gapped environments expected in early 2026.

This isn’t Microsoft admitting that the cloud strategy was wrong. It’s Microsoft acknowledging that for certain customers, in certain environments, with certain regulatory and sovereignty requirements, the cloud isn’t an option. And for those customers, having no path to modern productivity workloads running locally is an unacceptable gap.

Who This Is For

Let me be clear about the target audience here, because M365 Local is not for everyone, and isn’t intended to be.

Government and defence organisations that operate in classified or sovereign environments are the primary target. These organisations often have strict data residency requirements that prohibit any data, including email and documents, from leaving national jurisdiction or specific network boundaries. Many of these organisations have been stuck on ageing, unsupported versions of Exchange and SharePoint because there was no path to modernise without moving to the cloud.

Critical national infrastructure operators, including energy, telecommunications, and transportation, often have similar constraints. The control systems and operational technology environments in these sectors frequently require isolation from the public internet, and the personnel working in those environments still need email and collaboration tools.

Healthcare and financial services in certain jurisdictions face data handling regulations that make cloud-hosted productivity tools complicated at best and prohibited at worst. While many organisations in these sectors have found ways to use cloud M365 compliantly, there are edge cases where local deployment is the only viable path.

How It Works

M365 Local runs on Azure Local as a set of managed workloads. The server components (Exchange, SharePoint, Skype for Business) are deployed as VMs on your Azure Local cluster, managed through Azure in connected mode, or through local management tooling in disconnected mode.

The key differentiator from just “installing Exchange on a server” is that M365 Local is delivered as a managed experience through the Azure Local platform. Microsoft provides the deployment automation, the update mechanism, and the management tooling. You provide the infrastructure (Azure Local on Dell AX or other validated hardware) and the operational environment.

In connected mode, your M365 Local deployment is managed through the Azure portal, receives updates through the Azure Local lifecycle management process, and can integrate with other Azure services. Monitoring flows to Azure Monitor, policies can be applied through Azure Policy, and the overall management experience is consistent with the rest of your Azure Local environment.

In disconnected mode, which is the configuration that most sovereign customers will need, the management experience is local. Updates are applied through an offline process, and monitoring and management are handled through local tooling. This is more operationally intensive than connected mode, but it’s the only option for air-gapped environments.

The Dell AX Fit

Running M365 Local on Dell AX nodes is a natural fit. The compute requirements for Exchange and SharePoint servers are well understood, and Dell AX node configurations can be sized appropriately for the expected user populations.

For sovereign deployments specifically, Dell’s ability to provide hardware through secure supply chains, with validated configurations and offline-capable lifecycle management through the Solution Builder Extension, aligns with the requirements of the customer base that M365 Local is targeting.

The storage requirements for Exchange and SharePoint are worth paying attention to. Email stores and document libraries can grow substantially, and the storage performance characteristics matter for user experience. For smaller deployments, Storage Spaces Direct on the Azure Local cluster will be sufficient. For larger deployments, the PowerStore integration or PowerFlex with the AX-4520c provide additional storage scale and performance.

Is This a Step Backwards?

I think this is a question worth addressing directly. Is running Exchange and SharePoint on-premises in 2026 a step backwards? My answer is no, but with nuance.

For the majority of organisations, Microsoft 365 in the cloud is and should remain the default. The scale, feature velocity, security investment, and operational simplicity of cloud M365 is difficult to replicate on-premises. If you can use cloud M365, you should.

But “can use” is doing a lot of heavy lifting in that sentence. For organisations that genuinely cannot, for legal, regulatory, security, or sovereignty reasons, the previous answer was “tough luck, you’re stuck on old software.” M365 Local replaces that with a modern, managed, supported path to current productivity workloads running locally. That’s not a step backwards. That’s extending the reach of a modern platform to customers who were previously excluded from it.

The fact that M365 Local runs on Azure Local rather than on standalone Windows Server installations is also important. It means these deployments benefit from the same Azure management, monitoring, and lifecycle management that all Azure Local workloads receive. It’s not a throwback to the old days of racking Exchange servers and manually patching them. It’s a managed experience on modern infrastructure.

Looking Ahead

The disconnected mode availability is the next milestone to watch. For many of the target customers, connected mode is a nice starting point for testing and evaluation, but production deployment will require disconnected operation. I’ll be watching closely as this matures and will share practical experiences as they become available.

M365 Local is a niche product for niche requirements. But for the customers who need it, it fills a gap that’s been open for years. And its delivery through Azure Local reinforces the platform’s positioning as comprehensive cloud infrastructure for distributed and sovereign locations.

Dell Private Cloud and PowerStore: Azure Local's Enterprise Storage Future

Thu, 11 Dec 2025 00:00:00 +0000

Dell Private Cloud and PowerStore: Azure Local’s Enterprise Storage Future

Last month at Ignite 2025 , I covered the breadth of announcements for Azure Local, including the new SAN support capability. I mentioned that the Dell announcements specifically deserved their own post, because the story goes beyond just “Dell storage works with Azure Local now.” What Dell and Microsoft announced is a new integration between Azure Local, Dell Private Cloud, and Dell PowerStore that represents a fundamentally different approach to how these platforms work together. Let me unpack it.

The Announcement

Dell Technologies announced at Ignite 2025 that Azure Local is being integrated with Dell Private Cloud and Dell PowerStore. This isn’t just SAN connectivity, although that’s part of it. It’s a deeper integration that brings Azure Local’s management plane, lifecycle management, and Azure services to Dell’s private cloud infrastructure.

The integration is expected to enter early access in spring 2026, so what I’m discussing here is based on the announced direction rather than hands-on experience. I’ll update with practical details as the early access progresses.

What Dell Private Cloud Is

For those not familiar with the broader Dell private cloud portfolio, a brief bit of context. Dell Private Cloud is the evolution of Dell’s converged and hyperconverged infrastructure platforms. It provides a turnkey private cloud experience with Dell hardware, Dell management software, and integration with various hypervisor and cloud management platforms.

The integration of Azure Local with Dell Private Cloud means that customers deploying Dell Private Cloud can now use Azure Local as the management and orchestration layer. Azure becomes the control plane for your Dell Private Cloud, bringing the same Azure portal experience, Azure APIs, Azure Policy, and Azure Arc management capabilities that Azure Local customers already use.

PowerStore Integration

Dell PowerStore is Dell’s modern midrange storage platform, providing block, file, and vVols storage with NVMe performance, inline data reduction, and active-active controller architecture. It’s one of the most widely deployed enterprise storage platforms in the market.

The integration of PowerStore with Azure Local builds on the SAN support capability announced at Ignite. Azure Local clusters can connect to PowerStore arrays over Fiber Channel, using PowerStore as the primary workload storage while Storage Spaces Direct handles infrastructure storage.

What makes the PowerStore integration interesting beyond raw SAN connectivity is the lifecycle management story. Dell’s goal is to bring PowerStore lifecycle management into the same Azure-based management experience that handles the compute infrastructure. Rather than managing your storage array through a separate management console, the vision is to have it managed alongside your Azure Local cluster through the Azure portal and through Dell’s integration tooling.

Why This Matters

There are a few reasons this integration is significant.

Existing PowerStore customers can adopt Azure Local without abandoning their storage investment. This has been one of the most common objections I’ve heard from enterprise customers evaluating Azure Local. “We’ve just deployed PowerStore across our data centre, we’re not going to rip it out to use Storage Spaces Direct.” Fair enough. Now you don’t have to.

Performance characteristics change. PowerStore with NVMe-oF connectivity provides storage performance that’s in a different class from what most HCI deployments deliver. For workloads like large databases, analytics platforms, or high-frequency transaction processing that need the lowest possible storage latency, external PowerStore storage provides a path that S2D alone can’t match.

Operational consistency across the Dell portfolio. If you’re a Dell shop running PowerStore alongside Dell servers, the ability to manage the whole stack through a consistent set of tools is valuable. The Azure Local integration brings Azure management to the compute side, while Dell’s integration tooling brings the storage management alongside it.

Scale flexibility. Just as I discussed with PowerFlex and the AX-4520c , PowerStore integration enables independent scaling of compute and storage. But where PowerFlex is software-defined storage running on Dell servers, PowerStore is a purpose-built storage array. Different products, different price points, different sweet spots.

PowerFlex vs PowerStore: When to Choose What

With both PowerFlex and PowerStore now integrating with Azure Local, a natural question is which one to choose. The answer depends on your requirements.

PowerFlex is software-defined, scales linearly, and is designed for environments that need massive scale and performance. It runs on Dell servers (including the AX-4520c), and is ideal for large scale block storage requirements where linear scalability is paramount. Think large database estates, VDI at scale, or environments where storage growth is unpredictable and elastic scaling is needed.

PowerStore is a purpose-built storage array, with a smaller footprint, simpler deployment, and built-in data services like snapshots, replication, inline compression, and deduplication. It’s ideal for mixed workload environments where you need a combination of block and file storage, where data efficiency matters, and where you want a simple, appliance-based storage model alongside your Azure Local compute.

For many customers, the choice will be driven by what they already have. If you’ve got PowerStore deployed, use PowerStore. If you’ve got PowerFlex, use PowerFlex. If you’re starting fresh, the workload requirements and scale expectations should guide the decision.

Looking Forward

The spring 2026 early access for the Dell Private Cloud and PowerStore integration with Azure Local is something I’m genuinely looking forward to getting hands on with. The combination of Azure management, Dell compute hardware through the AX system, and Dell enterprise storage through PowerStore or PowerFlex provides a level of flexibility and capability that wasn’t available even a year ago.

Dell’s partnership with Microsoft continues to deepen, and the Dell AX system’s Premier Solution status provides the validation framework to ensure these integrations are tested and supported end to end. I’ll be writing about the practical experience once early access begins. Watch this space.

Ignite 2025: Azure Local Goes Big

Thu, 20 Nov 2025 00:00:00 +0000

Ignite 2025: Azure Local Goes Big

I’ve been to my fair share of Microsoft Ignite events over the years, and while each one has its share of announcements, some years just land differently. Ignite 2025 in San Francisco is one of those years, at least from an Azure Local perspective. The volume and significance of announcements this week is unlike anything I’ve seen for this platform since its original launch. Let me walk through what matters and why.

Azure Local at Scale: Hundreds of Servers

This is the headline, and it’s a big one. Azure Local has supported single clusters of up to 16 physical servers since inception. That’s been sufficient for many deployments, but it’s been a hard blocker for large enterprise data centre scenarios. Managing dozens of separate 16-node clusters to cover a large environment is operationally painful and architecturally limiting.

At Ignite, Microsoft announced that Azure Local can now scale to hundreds of servers using multi-rack deployments. This is not an incremental change. The architecture underpinning this capability is fundamentally different from what came before.

Multi-rack Azure Local uses separate aggregation racks for network and storage, and compute racks where the workloads run. The compute nodes are exposed as bare-metal machines, which are first-class Azure resources. And here’s the really interesting part: the infrastructure runs on Azure Linux rather than the Windows-based Azure Stack HCI OS, and uses a Kubernetes-based orchestration model instead of the traditional Failover Cluster and Hyper-V approach.

If this architecture sounds familiar, it should. It bears a striking resemblance to Azure Operator Nexus, which was Microsoft’s large-scale infrastructure platform targeted at telecommunications operators. It appears that the engineering investment in Nexus is now being brought to the broader Azure Local customer base.

For enterprise customers who have been limited by the 16-node boundary, this opens up entirely new deployment models. Large scale private cloud, big data workloads, dense container environments, all become achievable within a single Azure Local deployment rather than requiring federation across multiple small clusters.

SAN Support

The second major announcement is SAN support for Azure Local. This is something that enterprise customers have been requesting for years.

Azure Local now supports Fiber Channel connectivity to external SAN storage from leading vendors including Dell, Pure Storage, NetApp, Lenovo, HPE, and Hitachi. This means customers can connect their existing, trusted SAN infrastructure to Azure Local clusters and use it for workload storage.

A few important details: this is Fiber Channel first, with additional storage protocols on the roadmap. It’s currently supported for greenfield deployments only, you can’t attach a SAN to an existing Azure Local instance yet. And you still need Storage Spaces Direct alongside SAN, it’s not a SAN-only deployment model. S2D handles the infrastructure storage, while SAN provides additional capacity for workloads.

For Dell customers specifically, this means PowerStore and other Dell storage platforms can now be connected to Azure Local clusters. I’ll be writing more about the Dell PowerStore integration specifically in a follow-up post, because there’s a broader Dell Private Cloud story here that deserves its own treatment.

The enterprise significance of this cannot be overstated. Many large organisations have invested millions in SAN infrastructure over decades. Telling them they need to abandon that investment to adopt Azure Local was a non-starter. Now they can bring their existing storage with them.

NVIDIA RTX PRO 6000 Blackwell Server Edition

Microsoft announced support for NVIDIA’s latest RTX PRO 6000 Blackwell Server Edition GPU on Azure Local. This GPU is purpose-built for high performance AI workloads in on-premises and sovereign environments.

The capability claim is impressive: support for running over 1,000 AI models including GPT OSS, DeepSeek-V3, Mistral NeMo, and Llama 4 Maverick. For organisations building sovereign AI capabilities where data and models must remain on-premises, this is a significant enablement.

Combined with the GPU support that’s been maturing on Azure Local over the past year, the Blackwell GPU support positions Azure Local as a serious platform for on-premises AI workloads. This is no longer a future roadmap item, it’s a current capability.

Microsoft 365 Local

Microsoft announced general availability of Microsoft 365 Local, bringing core M365 server workloads to Azure Local. Exchange Server, SharePoint Server, and Skype for Business Server can now run natively on Azure Local in a connected mode, with a disconnected option for complete isolation coming early 2026.

This is fascinating from multiple angles. Microsoft spent the better part of a decade moving customers from on-premises Exchange and SharePoint to Microsoft 365 in the cloud. Now they’re providing a path to run those same workloads back on-premises. The driver isn’t a change of heart about cloud, it’s sovereignty. Government, defence, and regulated industry customers need these productivity workloads but can’t always consume them from a public cloud service.

Disconnected Operations GA

Disconnected operations for Azure Local have reached general availability. This means Azure Local can now operate in fully air-gapped environments with no connectivity to Azure. Deployment, management, and lifecycle operations can all be performed locally.

For sovereign and classified environments, this has been the missing piece. Azure Local now supports the full spectrum from fully connected to completely disconnected, with various levels of intermittent connectivity in between.

Dell at Ignite

Dell’s announcements at Ignite complement the Azure Local news. The integration of Azure Local with Dell Private Cloud and Dell PowerStore was announced, representing a new chapter in the Dell and Microsoft partnership. Dell AX nodes are validated for the new SAN support capability, and Dell is working with NVIDIA on validated GPU configurations for the Blackwell GPUs on AX hardware.

I’ll be covering the Dell Private Cloud and PowerStore story in detail in my next post. There’s a lot to unpack there, and it deserves focused attention.

The Big Picture

What strikes me about the totality of the Ignite 2025 announcements is the ambition. Eighteen months ago, Azure Stack HCI was a hyperconverged infrastructure platform for small to medium clusters. Today, Azure Local is a comprehensive private and sovereign cloud platform that can scale to hundreds of servers, integrate with enterprise SAN storage, run cutting edge AI workloads on the latest NVIDIA GPUs, host Microsoft 365 workloads, and operate fully disconnected from the internet.

The pace of evolution is remarkable, and it shows no signs of slowing down. If you’re in the hybrid infrastructure space, this is the most exciting time to be working in it that I can remember.

Multicloud in 2025: Comparing Hybrid Infrastructure Approaches

Thu, 09 Oct 2025 00:00:00 +0100

Multicloud in 2025: Comparing Hybrid Infrastructure Approaches

This blog is called multicloud.is, and while I’ve spent the past year and a half primarily writing about Azure Local and the Dell ecosystem around it, it feels overdue to step back and look at the broader hybrid infrastructure landscape. What are the options? How do they compare? Where does Azure Local fit relative to the alternatives? I’ll try to be as balanced as I can here, while being transparent about where my experience and perspective lie.

The Landscape

The major hybrid infrastructure offerings from the big three cloud providers, plus the independent players, give customers more choice than at any point in the past decade.

Azure Local (formerly Azure Stack HCI) is Microsoft’s hybrid infrastructure platform. It runs on validated hardware from OEMs like Dell, and projects on-premises infrastructure into Azure through Azure Arc. The management plane is Azure, the APIs are Azure, and the operational experience is designed to be consistent with Azure public cloud. It supports VMs, AKS, Azure Virtual Desktop, and an expanding set of Azure services running locally.

AWS Outposts is Amazon’s equivalent. Outposts brings AWS hardware and services into your data centre, running AWS compute and storage locally with a connection back to the AWS region for management and control plane operations. It comes in rack and server form factors, and supports EC2 instances, EBS storage, and a growing set of AWS services locally.

Google Distributed Cloud (GDC) is Google’s offering, available in connected, edge, and air-gapped variants. GDC runs on certified hardware and brings GKE (Google Kubernetes Engine), Anthos, and selected Google Cloud services to on-premises and edge locations.

Nutanix Cloud Platform is the primary independent player. It provides a hyperconverged infrastructure platform with its own control plane (Prism), its own hypervisor (AHV), and integrations with multiple public clouds. It’s not tied to any single cloud provider, which is both its strength and its limitation.

How They Compare

Let me break this down across a few dimensions that matter most to customers making this choice.

Management Model

Azure Local is managed through Azure. Full stop. Your on-premises clusters show up in the Azure portal alongside your public cloud resources. Policies, RBAC, monitoring, updates, all flow through the same management plane. The upside is consistency. The downside is dependency on Azure.

AWS Outposts is managed through the AWS console. Same principle, different cloud. Your Outpost resources appear alongside your AWS resources, managed by the same IAM, CloudWatch, and Systems Manager tools.

Google Distributed Cloud in its connected variant is managed through the Google Cloud console. The air-gapped variant has a local management interface, which is an interesting differentiator for sovereign scenarios.

Nutanix is managed through Prism, its own management plane. This makes it cloud-agnostic, which is appealing if you genuinely want to avoid dependency on any single cloud provider. The trade-off is that you’re managing a separate management plane that doesn’t natively integrate with any public cloud’s control plane.

Hardware Model

Azure Local runs on OEM hardware from Dell, Lenovo, HPE, and others. You choose your hardware partner, and the solution is validated and supported as a combined offering. Dell AX with Premier Solution status represents the highest tier of this model.

AWS Outposts is AWS hardware. Amazon designs it, ships it to you, installs it, and maintains it. You don’t choose the hardware, you consume it as a service. This simplifies some decisions but removes flexibility.

Google Distributed Cloud uses certified hardware from partners, similar to the Azure Local model but with a smaller set of certified configurations.

Nutanix runs on hardware from most major server vendors, giving you the broadest hardware choice but with varying levels of integration and validation depending on the vendor.

Workload Support

All four platforms support VMs and containers. Azure Local adds Azure Virtual Desktop and is bringing Microsoft 365 workloads. AWS Outposts supports a broad set of AWS services including RDS, ECS, and EMR. Google Distributed Cloud focuses heavily on Kubernetes and AI/ML workloads. Nutanix supports VMs on AHV and has Kubernetes integration through NKE.

Sovereignty and Disconnected Operations

This is where the platforms diverge most significantly. Azure Local is investing heavily in disconnected operations and sovereign cloud scenarios. Google Distributed Cloud’s air-gapped variant addresses similar requirements. AWS Outposts requires a persistent connection to the parent AWS region, which limits its applicability in truly disconnected or sovereign scenarios. Nutanix can operate fully independently since its management plane is local.

My Take

Every one of these platforms has scenarios where it’s the right choice. The decision should be driven by your existing cloud investments, your workload requirements, your sovereignty needs, and your operational preferences.

If you’re an Azure shop, Azure Local is the natural extension. The management consistency, the Azure Arc integration, and the expanding set of Azure services running locally make it the obvious choice for organisations already invested in the Azure ecosystem. Dell AX with Premier Solution status provides the hardware assurance layer on top.

If you’re an AWS shop, Outposts provides similar consistency with the AWS ecosystem. The managed hardware model is appealing if you want to treat on-premises infrastructure as a fully managed service.

If sovereignty and air-gapped operation are primary requirements, Azure Local and Google Distributed Cloud are currently ahead of the curve, with Nutanix also capable by virtue of its independent management plane.

If you genuinely want to avoid cloud provider dependency, Nutanix gives you the most flexibility, at the cost of managing a separate ecosystem.

The Real Multicloud

Here’s what I think the honest multicloud conversation looks like in 2025. Most organisations will standardise on one primary cloud provider for the majority of their workloads, and extend that provider’s management model to their on-premises infrastructure. True multi-provider architectures, where different clouds are used deliberately for different workloads based on capability and policy, exist, but they’re more complex and expensive to operate than vendor marketing would have you believe.

The most pragmatic approach is to choose your primary cloud, extend it on-premises with the corresponding hybrid platform, and use additional clouds deliberately and sparingly for specific capabilities that your primary provider doesn’t offer. That’s not as exciting as the “run anything anywhere” vision, but it’s realistic, and it’s what the most successful organisations I work with are actually doing.