Azure Platform and Resource Journey

Understand what Azure is

Every later topic rests on one definition, so it is worth getting exactly right. Microsoft Azure is a cloud computing platform for building, deploying, and managing solutions.

The most common beginner error is to call Azure a datacenter. Azure is not a datacenter. Its services are hosted in Microsoft's global network of datacenters, while Azure itself is the platform that manages and delivers them. The buildings are the where; the platform is the what.

What the platform delivers is grouped into service families: compute, storage, networking, databases, analytics, and AI. Customers can use those services to develop and scale new applications, or to run existing applications in the cloud.

Notice what those families are not. They are not the physical plant of a datacenter — buildings, generators, cooling, security — and they are not business functions such as payroll or procurement. They are the technical capabilities an application is built from.

See where Azure reaches and how you pay

The reason organizations move to the platform is usually economic before it is technical. Azure addresses the time and expense of maintaining every layer of on-premises infrastructure — the hardware, the space, and the people who keep it running.

Its reach is not limited to the cloud either. Azure supports applications across cloud, hybrid, and edge environments. Azure hybrid solutions extend Azure services to on-premises, multicloud, and edge environments, and give one unified platform for managing, governing, and securing servers, Kubernetes clusters, and applications wherever they run.

The billing model follows the same logic. Organizations can dynamically adjust Azure resources as demand changes and pay only for what they use.

That combination is what an on-premises purchase cannot match. Consider a retailer whose traffic triples for three weeks each December:

Learn the core vocabulary

Three words are used constantly and are easy to blur. Separating them once saves confusion everywhere else.

A service is a capability available from the Azure platform. An Azure resource is a manageable item such as a virtual machine, storage account, web app, database, or virtual network — the deployed item that you create and manage. A resource provider supplies Azure resource types.

The provider examples make the distinction concrete: Microsoft.Compute supplies virtual machine resources, and Microsoft.Storage supplies storage resources. A provider never holds your resources or manages them; it makes the type available so that a resource of that type can exist at all.

Group resources by lifecycle

Once you have more than a handful of resources, you need somewhere to put them. A resource group is a container for related resources that an organization wants to manage as a group.

The rule for deciding what goes in is lifecycle, not similarity. Resources in a resource group should share a lifecycle so they can be deployed, updated, and deleted together. Two web apps that retire on different dates belong in different groups, even though they are the same kind of thing.

Membership is exclusive but not isolating. Each resource can exist in only one resource group, although it can connect to resources in other groups. A web app in one group can still talk to a database in another; the grouping governs management, not network traffic.

That exclusivity is what makes the group a useful target for a management setting. Put the resources that must be treated alike in one group, and the group boundary becomes the boundary of the rule.

Read the management hierarchy

Management settings need a place to be applied, and Azure gives four. Azure has four management scopes: management groups, subscriptions, resource groups, and resources. The order runs from the broadest scope to the narrowest.

The scope you choose for a management setting determines how widely it applies, because lower levels inherit settings from higher levels. A policy assigned to a subscription applies to its resource groups and to their resources. A policy assigned to one resource group applies to that group and its resources, but not automatically to another resource group.

Read that inheritance in both directions when you plan. Applying a setting high is efficient and hard to escape; applying it low is precise and easy to miss. Choose the level that matches how far the rule should actually travel.

Keep providers and scopes apart

These two ideas arrive at the same time and get confused for years afterward, so pin them down now. A resource provider supplies resource types. A management scope defines where resources and management settings sit.

Microsoft.Compute is not a level of the hierarchy; it is the reason a virtual machine resource type exists. A management group is not a supplier of types; it is a place where a setting can be applied and inherited downward.

Keeping the two separate answers a practical question quickly: if you are asked where a rule applies, the answer is a scope; if you are asked what kind of thing you can create, the answer comes from a provider.

Move through the Azure portal

The Azure portal is a web-based unified console for creating and managing Azure resources through a graphical interface. It is where most people meet everything described so far.

A first journey through it runs in a predictable order. It starts at portal Home, where you can select Create a resource to create one in the current subscription, choose a service to start working in, or reopen a recently visited resource. The portal also provides guided wizards for creating resources, which is what makes the first deployment approachable.

From there the journey continues. Related resources that share a lifecycle are placed in a resource group, and the portal then supports managing and monitoring those resources. Global search in the page header can locate a resource, a service, or documentation. Once a resource is open, its service menu provides the commands specific to that resource or service.

Understand Azure Resource Manager

The portal is a face, not the engine. Azure Resource Manager is the deployment and management service for Azure, and it provides the common layer used to create, update, and delete resources.

Every management request travels the same path. When a request arrives through an Azure API, tool, or SDK, Resource Manager authenticates and authorizes it, and only then forwards it to the appropriate Azure service. Access is checked before anything is created, whichever door the request came through.

Because that layer is common, the interface you use is a preference rather than a limitation. Capabilities available in the portal are also available through PowerShell, the Azure CLI, REST APIs, and client SDKs.

A resource created from the CLI is therefore fully manageable in the portal, and vice versa: they are two doors into one management layer.

Key takeaways

• Platform, not datacenter: Azure is a cloud computing platform for building, deploying, and managing solutions, and Microsoft's datacenters host the services it delivers.
• Vocabulary: resources are manageable Azure items, resource providers supply resource types, and resource groups contain related resources that share a lifecycle.
• Hierarchy: the four management scopes run from management groups through subscriptions and resource groups to individual resources, with inheritance flowing downward.
• Portal: the Azure portal supports creating, managing, and monitoring resources, from Home through resource groups, global search, and the service menu.
• Resource Manager: it is the common management layer, reached equally from the portal, PowerShell, the Azure CLI, REST APIs, and client SDKs.