Microsoft Azure
Why Azure keeps coming up when your business already runs on Microsoft
The short answer
Azure is Microsoft's cloud: computing, storage, databases and AI services rented by consumption rather than bought. At the level most business software needs, it's much like its competitors. What's genuinely different for a Microsoft business is identity. Your staff sign-in already exists there, and an application built on Azure can use it.
Somebody put Azure in the proposal, and the reason attached was that the business already runs on Microsoft. That can sound like an excuse for not looking any further. It usually isn't, though it's worth knowing what the argument rests on, and where it runs out.
Rented computing, and the machines aren't the interesting part
Azure is Microsoft's cloud. Under a long catalogue of named services it's the same offer as the other large providers: servers, storage, databases, networks and AI services rented by consumption instead of bought, running in Microsoft's data centres.
Most business software uses a short list from that catalogue. Somewhere to run the application, a database, file storage, something to queue work, and a way of signing people in. At that level the big providers are close enough that the technical differences rarely decide anything on their own. What decides it is usually what's already in the building.
One thing worth learning before you read the quote: Azure has three nested boxes above the machinery, and proposals use those words as though you know them.
Your Microsoft directory
Who
One list of people and their sign-ins, shared with Office and Teams. It decides who gets in anywhere.
Subscription
The bill
Where the spending and the limits sit. Separate subscriptions are how one project's bill stays separate from another's.
Resource group
Moves together
A labelled box holding the parts of one system, so they get handed over, copied or deleted together.
The resources
What runs
The servers, databases, storage and services the application actually runs on.
The Microsoft argument is a real argument
Being a Microsoft business gets treated as the lazy reason for a platform choice. It's usually the opposite. Of everything on a platform shortlist, it's the only factor specific to your company rather than generic to the technology.
Your staff have one sign-in that opens their email, their files and Teams. It lives in Microsoft's directory, called Microsoft Entra ID since a rename in 2023, and that's the same directory Azure uses. So an application built there can hand the sign-in back to the directory instead of keeping its own list of usernames and passwords.
That reads like a detail and it isn't. No new password for anybody. The second-factor prompt and the sign-in rules the business already applies cover the new thing from day one. And when somebody leaves, disabling their account closes this application too, rather than leaving a login nobody thought to check.
The rest of the argument is commercial and still real. There's an agreement in place, a supplier finance has approved, one bill instead of two. If the business owns Windows Server or SQL Server licences with active Software Assurance, Microsoft's Hybrid Benefit lets those apply to Azure rather than paying twice.
01
Someone opens it
They follow the link. The application doesn't ask for a password. It hands the question of who they are to the directory.
02
The usual sign-in
The same account they use for email, with whatever second factor and sign-in rules the business already applies to everything else.
03
A signed token
A signed statement of who they are and which groups they belong to. No new password exists anywhere to be forgotten or reused.
04
The account is closed
IT disables one account and this application closes with the rest. Nobody has to remember it separately.
Where the identity advantage stops
All of that is about your staff. So ask who signs in to the thing being built. If the answer is employees, contractors and the occasional supplier you'd put in the directory anyway, the Microsoft argument is strong.
If the answer is your customers, it mostly doesn't apply. Members of the public aren't in your company directory and shouldn't be. Microsoft sells a separate product for signing them in, and it competes on its own merits with everything else that does that job. One proposal can be right about the staff side and wrong about the other.
Worth checking too: some identity controls people assume come with the directory sit in a paid tier of it. Ask which tier the business is on before a design leans on a rule you haven't got.
What the compliance answer really covers
Azure gets chosen for regulated work often enough that the reasons deserve stating plainly. Microsoft publishes the audit reports and certifications for the platform, and will commit in writing to the regions your data sits in. It also runs separate clouds for governments whose rules ordinary commercial hosting can't meet.
What gets misread is what those certificates cover. Every large provider publishes a shared responsibility model, and Azure's says what the others say. The buildings, the hardware and the platform are Microsoft's problem. Who can see which record inside your application is yours. A certified platform doesn't produce a compliant application, and an auditor asks about your controls rather than Microsoft's.
So a proposal that answers a compliance question by listing the provider's certifications is incomplete rather than wrong. The question after it is what the build does about access, retention and records.
Where it stops, and it's the same ceiling as any cloud
Nothing about Azure reduces the work of running software. The portal makes things easy to create, which makes them easy to leave running long after anyone remembers asking for them. Spend accrues quietly, machines need patching, backups need testing, alerts need somewhere to arrive.
For a marketing site, or a content site with a few forms behind it, this is the wrong tool, and a managed platform gets you live with far less to look after. The case for a cloud starts when the thing behaves like an application: accounts, records that belong to one customer and not another, work that carries on when a machine dies.
One practical annoyance is worth knowing in advance. Microsoft renames its products often enough that a proposal, the documentation you find and the invoice can use three names for one thing. When two documents seem to disagree, it's usually a rename rather than a disagreement.
Who has to be around afterwards
This decides more builds than anything technical, and it's answered in people rather than money.
Three roles have to exist somewhere. Somebody at your company, not your vendor's, holds the top-level administrator account. Somebody owns the bill and looks at it monthly. And somebody is reachable when it breaks at an awkward hour, which is an internal person, a written arrangement with whoever built it, or a risk you've decided to accept. All three answers are fine. Unnamed is not.
There's a wrinkle specific to being a Microsoft business. The directory that makes the identity story work usually belongs to your IT provider, so a product build needs them at the table. They'll be asked to register an application, approve permissions and maybe adjust a sign-in rule. Small in week one, a scheduling problem the week before launch.
Write those names down before anyone argues about the platform. The argument gets shorter once they exist.
Worth knowing before you start
Ask whose name the Azure tenant and the subscription are in, and get your own company on both before the last invoice is paid. A tenant set up under a vendor's account is slow to unpick.
Put a budget with an alert on the subscription before launch, not after the first surprising invoice. The figures it reads lag actual usage, so treat it as an early warning rather than a cap.
Ask for the list of Azure services the design depends on, in writing. That list is what leaving would cost you later, and it's cheap to read while it's short.
If the business owns Windows Server or SQL Server licences with Software Assurance, ask whether the design uses them. Hybrid Benefit sits on the procurement side, so a technical team often won't think to raise it.
Common questions
Microsoft 365 is the software your staff use: email, Teams, the documents. Azure is where you'd build something of your own. What connects them is the directory of people, which both read, and that shared piece is why the names, the admins and the bills bleed into each other.
Not reliably, and list prices are a poor guide. What moves the number is the shape of what you build and what your Microsoft agreement already covers. Ask procurement as well as the engineers.
Both. It's one product, renamed in 2023. Plenty of documentation, training material and proposals still use the older name and will for years.
Yes. Microsoft runs Canadian regions, and you choose which one your data sits in. Two cautions. Not every service exists in every region, so a residency rule can quietly narrow what the design may use. And where data sits matters less than who can reach it.
Not necessarily a hire, but yes an arrangement, named in advance. Most Microsoft businesses already have an IT provider, and the question is whether that agreement covers a custom application or only the desktops, email and network. Usually the latter.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.