CLOUDY MUSINGS

My last post was an apology to Azure Backup for evaluating today's product with yesterday's assumptions. This one is less apologetic, because this time the confusion isn't entirely our fault. Microsoft named a vault "Recovery Services Vault" and then made it the primary home of Azure Backup. They named another vault "Backup Vault" and then made it hold almost none of the backups people think of when they say the word backup. If you designed a naming scheme specifically to mak

The most convincing form of technical arrogance is the kind that masquerades as experience. You spend enough years in tech, you accumulate enough scar tissue, and eventually your opinions calcify into something faster than reasoning: reflex. Someone mentions a product, and you already know what you think before they finish the sentence. No deliberate evaluation required...that's just pattern recognition, right? Maybe. But pattern recognition trained on a snapshot of 2021 is n

Every platform migration eventually presents its toll booth. I have been doing more of my day-to-day Azure work from a Mac lately, which meant getting PowerShell, the Az modules, Git, and VS Code all cooperating on the same machine. Most of it was surprisingly uneventful. PowerShell runs perfectly well on macOS, the Azure modules install normally, and VS Code gives me roughly the same scripting experience I am used to everywhere else. Then I ran the single most routine comman

Every legacy server eventually meets its Ragnarök. It doesn't matter if it's humming away on a rack in a closet, running as a VM on a vSphere or Hyper-V host, sitting in colo, or parked in an Azure subscription nobody's touched since the migration project wrapped. Support ends, the patches stop, and the only thing standing between that server and the wolves is whether you paid Microsoft's toll for a few more years of borrowed time. That toll is called Extended Security Update

Everybody loves AI until the invoice shows up! Not the cute "we spent a few hundred dollars experimenting" invoice that gets hand-waved away as innovation spend. I mean the kind of invoice that makes finance suddenly become deeply curious about architecture decisions they previously considered engineering trivia, while operations and/or product teams insist everything is still technically a pilot, and leadership starts asking whether we can "optimize this" as though that thou

Infrastructure changes have a way of producing unexpected side effects! (a.k.a. gather around for another lively lesson learned the hard way...) Sometimes it's a routing issue that doesn't surface until something tries to use the affected path. Sometimes it's a service dependency that nobody documented because it always just worked. And sometimes it's discovering that cloud management platforms don't automatically resume where they left off after you've changed the environmen

As with previous blog posts, all code can be found here! The Norns sat beside the Well of Urd weaving fate into the roots of Yggdrasil. The thread was already spun long before anyone knew how the story would end, and by the time the consequences arrived, they were simply discovering decisions that had already been made. I found myself thinking about that recently (HUGE Norse mythology fan) after yet another conversation about cloud billing, because the parallels are stronger

After spending years working across Azure, AWS, and GCP, I can tell you the most frustrating part of FinOps is rarely the optimization itself. The hard part is getting everyone in the room to agree on what the data actually means before anyone can act. Every provider exports billing differently, every tool invents its own abstraction layer on top of that, and every dashboard ends up starting with translation instead of analysis. You spend the first hour of every cost conversa

This topic comes up constantly. Sometimes it's at the start of a discovery conversation before we get into modernization, governance, platform engineering strategy, security, or cost optimization. Sometimes it's during a migration discussion where the existing documentation is incomplete or just plain wrong in the way only cloud infrastructure documentation can be. And sometimes it's simpler than any of that: someone just needs to know what's actually running in Azure across

As with previous posts, all source code and a corresponding GitHub repository can be found here! This is one of those questions that seems like it should have a straightforward answer, but it doesn't because what good fun would that be if there were a straightforward answer? I'm sure you've been here before: someone spots an enterprise application in Microsoft Entra ID, notices it has permissions or credentials attached, and naturally asks: who created this thing? If you star

This keeps coming up in real conversations, and it usually surfaces right when decisions start to matter. Someone says they are "in GCC," and from there the assumption creeps in that Azure Government is somehow already in the picture. That leap feels small in the moment, but know it is not. The reference and assumption snowballs into bad architecture, wrong scoping, and uncomfortable conversations when compliance teams start asking harder questions. People are not being carel

There's a very specific moment in almost every Azure File Sync conversation where things go from "this is going great" to "wait, what do you mean we can't do that?" P.S. That happened this week and it took me back, hence the blog post. This usually happens right after the POC looks successful. You've synced a few hundred gigs from the D: drive of an on-premises file server, cloud tiering is working, ACLs look intact, and everyone feels good. Then someone asks how you expose

Let me tell you about a moment that happens to almost everyone working with Azure networking. You're designing a network, you discover service endpoints, and you think "Great! This keeps my traffic on Microsoft's backbone instead of the public internet." You enable them for Storage, SQL, maybe Key Vault. Everything makes sense. Then you stumble across service endpoint policies and think "Oh cool, I can add more control to all these services!" You start setting them up for SQ

So you're looking at Azure Data Box, and it seems pretty straightforward. Microsoft sends you a physical box, you load it up with data, ship it back, and boom: your data's in Azure. Simple, right? Then you actually start planning the migration. You open the portal, dive into the docs, and suddenly you're reading the same paragraph about "regions" for the third time, still not entirely sure what it means. Here's the question I've been asked from time to time: If I create my Da

Note, the companion code and corresponding full GitHub repository is located here . Azure costs are tricky enough without licensing contracts adding another layer of confusion on top. One of my long-running jokes from my time working at Microsoft was that you needed an advanced degree just to understand Azure billing, and then a second one to understand how that billing intersects with real-world consumption in Azure. What tends to catch teams off guard is that the agreement

When I wrote Azure Savings Plans, Finally Explained with Math That Actually Makes Sense , I was very focused on solving one specific problem. People were looking at Savings Plans and feeling like they were missing something obvious. They saw the hourly commitment. Then they saw their bill. They did not see a discount. And that disconnect was driving a lot of unnecessary anxiety. Once that post went live, I started finalizing this post as I knew there would be immediate follow

Math IS hard and mathing isn't my strong suit. I am writing this blog because I STILL get tripped up at times with Savings Plans. You guessed it...this becomes a cheat sheet for ME in the future, too! Azure Savings Plans are one of those topics that routinely make smart people feel like they missed a prerequisite class. I see it in customer meetings, I see it in internal chats, and I definitely see it in the way people react to Azure Advisor recommendations. The issue is not

Like all my previous blogs, code to accompany this post exists here . If you have ever tried to answer the question “what kind of Azure subscription is this?” using automation, you probably assumed there was a clean, authoritative answer somewhere. An API call. A property. A single source of truth. And if you have spent any real time with Azure billing or FinOps work, you already know how quickly that assumption falls apart. Most people eventually land on Offer ID. The Azure

a.k.a. How to migrate file data without breaking apps, users, or your weekends! All code for this blog can be found here ! In my time of supporting customers embracing a "digital transformation", every file migration starts the same way: “We just need to move our file shares to the cloud.” That sentence hides an enormous amount of complexity. Files are not just bytes on disk (I wish they were...life would be easier!). They encode how people collaborate, how applications behav

There has been a lot of noise lately about Microsoft “changing support” for Azure Pay As You Go subscriptions. Depending upon who you ask, this has turned into everything from “PAYG is being deprecated” to “Microsoft is forcing everyone into CSP.” None of that is actually happening. Microsoft doesn't always make this straightforward in messaging, so my hope is to help you out a bit! This is what I want to land clearly with you all and will repeat it a few times: Microsoft is