Azure Services
Purpose
This section explains Azure services from a practical cloud engineering perspective and focuses on the services that power the current learning path.
It is meant to help you understand how services fit into real systems, not just memorize short definitions in isolation.
Definition
This section is a curated guide to the Azure services used most directly across the site's projects, patterns, and provider-specific learning path.
It is not a full Azure catalog. It is a working set of services chosen because they help explain the main architectural decisions a cloud engineer has to make: identity, authorization, runtime, storage, data movement, observability, secrets, and AI platform design.
In simple terms:
This section is the Azure service map for the systems this site teaches you to build.
What Problem This Section Solves
Cloud service catalogs are broad, and that breadth can make early learning messy. People often read isolated service descriptions without understanding how those services work together in a real workload.
This section narrows the scope. It helps you answer practical questions such as:
- which service solves this problem,
- where that service belongs in an architecture,
- what tradeoffs come with choosing it,
- and what identity, networking, observability, and cost implications follow from that choice.
How To Read This Section
These pages are intended to make the current provider path easier to understand by answering a focused set of questions.
- What problem does this service solve in Azure?
- How does it fit into a project or pattern?
- What identity, networking, and observability assumptions come with it?
- How does it compare to the surrounding runtime, data, and governance choices?
This section is most useful when you read it alongside a project or pattern rather than as a disconnected glossary.
A practical reading order is:
- Start with a project or pattern.
- Use the relevant service pages to understand the main building blocks.
- Compare nearby services when a design choice is not obvious.
- Return to the foundations pages when a service keeps depending on the same core concept.
What This Service Set Is Designed To Teach
The Azure path emphasizes the services most useful for learning:
- identity-centered governance and authorization,
- application hosting and runtime choice,
- object storage and application data boundaries,
- data movement and analytics-platform design,
- monitoring and operational visibility,
- secret handling and safer runtime configuration,
- and how AI features fit into normal cloud engineering rather than sitting outside it.
Service Categories
Identity and Access
Azure systems start with trust boundaries. These pages explain how user identity, workload identity, and Azure resource authorization should be separated.
Application Hosting and Delivery
These services define how application code or containers are delivered. The main question here is whether the workload is a function, a managed containerized service, or a container delivery path.
Storage and Data
These services hold files, application records, or broader analytics-platform components. The key boundary is whether the system needs durable objects, an operational database, a pipeline control plane, or a larger analytical platform.
Integration and Scheduling
These services help systems receive API traffic or sit behind a governed API edge rather than exposing every backend directly.
Observability and Operations
These services help teams detect failures, watch health, and operate workloads like systems instead of demos.
AI and Agentic Platforms
These pages explain how AI features become part of a real Azure application architecture, including model access, retrieval, safety controls, and managed agent behavior.
Security and Secrets
These services focus on sensitive runtime configuration and the operational discipline around secret access.
How The Categories Connect
Typical Azure workloads in this site follow a pattern like this:
- Entra ID, RBAC, and managed identities define who or what can act.
- API Management, Functions, or Container Apps provide the entry and runtime boundary.
- Blob Storage, Cosmos DB, and Key Vault support data, state, and sensitive configuration.
- Data Factory and Microsoft Fabric extend the architecture into movement and analytics when the workload needs broader data-platform capabilities.
- Azure Monitor and Application Insights provide the operational view.
- Foundry, Azure OpenAI, Azure AI Search, and Content Safety build on top of that same application foundation rather than replacing it.
The important lesson is that Azure service choice is not a list-building exercise. It is a system-design exercise.
What This Section Does Not Try To Do
This section does not try to summarize every Azure product or give certification-style one-liners for the whole platform.
It is intentionally narrower than that. The goal is to build judgment about which services belong in a practical architecture and why.
Project and Pattern Connections
Use this section together with the Azure project and pattern pages:
How This Fits Into Cloud Engineering
Cloud engineers need service knowledge that supports design, deployment, and operations. This section helps you explain how Azure services work together in a system and what tradeoffs they introduce.