EXPLAINER

Azure Fundamentals for Application Developers

Azure is Microsoft's cloud for compute, data, identity integration and AI hosting. Application teams usually start with App Service or containers, a database, storage, Key Vault and Entra ID, not with every service in the catalog.

Short answer: Azure is Microsoft's cloud platform: compute, databases, storage, functions and managed AI endpoints. Identity for those apps is usually Entra ID. It is not the same product as Microsoft 365.

What it is

Microsoft Azure is a public cloud: you rent compute, storage, databases, networking and higher-level APIs instead of buying servers. Resources sit in a subscription, inside resource groups, in a region (a geographic cluster of data centres). An App Service plan runs a web app. Azure Functions runs small pieces of code on demand. Azure Storage holds blobs and queues. Azure SQL and PostgreSQL flexible server are managed databases. Key Vault holds secrets and keys. Entra ID, covered separately, is the identity layer most Azure apps use.

Azure is not Microsoft 365. M365 is mail, files and Teams. Azure is where you host the system you are building. They connect when your Azure app calls Graph or when a company uses the same Entra ID tenant for both.

Why and when it is used

Choose Azure when the organisation already standardises on Microsoft identity, when you want Microsoft-managed databases and certificates close to M365, or when you are calling Azure OpenAI or other Azure AI services under the same contract. It is a reasonable default for a company that already pays for Microsoft and has admins who know the portal.

It is not automatically better than AWS or Google Cloud for a startup with no Microsoft footprint. Pick the cloud your team can operate. Do not start by enabling twenty services. A small app needs a place to run, a database, a secret store and logs.

How it works

You authenticate with Entra ID. Role-based access control (RBAC) grants roles such as Contributor on a resource group, which is separate from your application's user login. The control plane (creating a database) is Azure Resource Manager. The data plane (querying that database) uses the database's own connection string and firewall. Confusing those two planes causes "I am Owner on the subscription but the app cannot log in to SQL".

Deployments should be described as infrastructure as code (Bicep or Terraform) so a second environment is not a click-path nobody remembers. Configuration comes from app settings, which appear to the process as environment variables. Secrets should be references to Key Vault, not values pasted into the portal and forgotten. Outbound calls to Graph or to a model API leave your app and need the right network rules. Private endpoints exist when the database must not face the public internet; they add complexity you should add deliberately.

Technologies and dependencies

For a typical web or AI backend: App Service or Container Apps, a managed PostgreSQL or SQL database, Storage if you keep files, Key Vault, Application Insights for logs, and an Entra app registration if users sign in. Azure OpenAI is a model-hosting service with its own endpoint and key or Entra credential; it is optional, not the definition of Azure. The Azure CLI (az) and the portal are how humans operate. Containers are one way to package the app so local and cloud match. CI should deploy the same artifact you tested.

How to get started

  1. Create a dev subscription or a resource group you are allowed to spend in. Set a budget alert.
  2. Install the Azure CLI and sign in with az login.
  3. Deploy a tiny web app (App Service or Container Apps) that reads a setting MESSAGE and returns it. Prove configuration before you prove features.
  4. Put a connection string in Key Vault and reference it. Do not commit it.
  5. Add a managed database only when you have data. Open the firewall to your IP for learning, then close it.
  6. Look at Application Insights or Log Analytics for one failed request so you know where stdout went.
  7. Delete the resource group when the experiment ends. Abandoned Azure resources are how learning becomes an invoice.

Cautions and trade-offs

The portal makes it easy to create resources nobody can rebuild. Click-built production is a risk. Regions and SKUs affect both latency to your users and price; a GPU SKU left running is a surprise bill. "Contributor on the subscription" is too much access for an application identity. Use a managed identity for the app to read Key Vault instead of embedding a secret.

Azure's service names overlap (several ways to run containers, several databases). Standardise on one path for your team. Free tiers sleep or throttle and are not a performance test. Compliance features (regions, private networking, customer-managed keys) are real work; do not promise them because the checkbox exists. And do not put Microsoft 365 tenant data into an Azure storage account without a retention and access story. Hosting the app in Azure does not make that copy compliant.