This chapter covers microservices architecture concepts, a foundational cloud computing pattern that Azure supports natively. Understanding microservices is critical for the AZ-900 exam because it tests your ability to differentiate between monolithic and microservices architectures, and to identify the benefits of decoupling applications in the cloud. This objective area (Cloud Concepts, Objective 1.2) carries approximately 25-30% of the exam weight, so mastering this topic is essential for passing.
Jump to a section
Imagine a restaurant kitchen that used to have one massive chef who did everything: chopping vegetables, grilling steaks, plating desserts, and even washing dishes. This is like a monolithic application. If the chef got sick, the entire kitchen shut down. Scaling meant hiring another equally skilled all-in-one chef, which was expensive and inefficient. Now, the restaurant switches to a team of specialist chefs: one chef only chops vegetables (the 'Chopping Service'), another only grills steaks (the 'Grilling Service'), and a third only plates desserts (the 'Plating Service'). Each chef has their own station with exactly the tools they need. They communicate through a standardized order ticket system (an API gateway). If the Grilling Service is overwhelmed during a dinner rush, the restaurant can hire two more grill chefs without affecting the chopping or plating stations. If the Plating Service needs to be updated to use a new sauce, the chef can be retrained without shutting down the entire kitchen. Each service (chef) runs independently, can be scaled individually, and can be updated without downtime. This is the core mechanism of microservices: independent deployment, scaling, and failure isolation.
What Are Microservices and What Business Problem Do They Solve?
Microservices architecture is an approach to building applications as a collection of small, independent services that each run a unique business capability. Each service is self-contained, has its own database or data store, and communicates with other services via well-defined APIs (usually HTTP/REST or messaging queues). This contrasts with monolithic architecture, where all functionality is bundled into a single deployable unit.
The primary business problem microservices solve is the complexity of scaling and maintaining large applications. In a monolith, a small change to one feature requires rebuilding and redeploying the entire application. This slows down release cycles, increases risk, and makes it difficult to scale individual components. For example, if a video streaming platform’s recommendation engine becomes popular, you might want to scale only that component, but in a monolith you must scale the entire application, wasting resources. Microservices allow you to scale each service independently based on demand.
How Microservices Work — Step by Step Mechanism
Decomposition: The application is broken down into bounded contexts. For an e-commerce app, you might have services for Product Catalog, Shopping Cart, Order Processing, Payment, and User Authentication. Each service is owned by a small team that can deploy independently.
Inter-service Communication: Services communicate using lightweight protocols. The most common approach is synchronous HTTP REST calls via an API Gateway. The API Gateway acts as a single entry point, routing requests to the appropriate service, handling authentication, rate limiting, and request aggregation. Alternatively, asynchronous messaging using Azure Service Bus or Event Grid allows services to communicate without waiting for a response, improving resilience.
Data Management: Each microservice has its own database or data store, ensuring loose coupling. This is known as the Database-per-Service pattern. For example, the Order service might use a SQL database for structured order data, while the Recommendation service uses a NoSQL database like Cosmos DB for flexible product data. This prevents a single database from becoming a bottleneck.
Deployment and Orchestration: Services are typically containerized using Docker and orchestrated with Kubernetes (AKS in Azure) or Azure Container Instances. Containers ensure consistent environments across development, testing, and production. Orchestrators handle scaling, load balancing, and service discovery.
Monitoring and Logging: With many services, centralized logging and monitoring are essential. Azure Monitor and Application Insights aggregate logs and metrics from all services, providing a single pane of glass. Distributed tracing (e.g., using OpenTelemetry) tracks a request as it flows through multiple services.
Key Components in Azure
Azure Kubernetes Service (AKS): Managed Kubernetes for orchestrating containerized microservices.
Azure Container Instances (ACI): Simple, serverless containers for smaller workloads.
Azure Functions: Serverless compute for event-driven microservices.
Azure API Management: API Gateway for exposing, securing, and managing APIs.
Azure Service Bus: Enterprise messaging for asynchronous communication.
Azure Cosmos DB: Globally distributed, multi-model database for service-specific data.
Azure DevOps: CI/CD pipelines for automating build, test, and deployment of each service.
Pricing Models
Microservices incur costs from compute (VMs, containers, serverless), storage (databases), networking (data transfer, API Gateway), and management tools. Azure offers pay-as-you-go pricing. For example, AKS charges for the underlying VMs, not the control plane. Azure Functions has a consumption plan where you pay per execution. Cost management is critical because many small services can lead to higher overall costs if not optimized.
Comparison to On-Premises Equivalent
On-premises, microservices require significant upfront investment in hardware, networking, and middleware. Scaling a service involves purchasing and configuring new servers, which takes days or weeks. In Azure, you can scale services in minutes using auto-scaling rules. On-premises, deploying a new version of a service requires manual coordination; in Azure, you can use blue-green deployments or canary releases with minimal downtime. Azure also provides managed services for messaging, databases, and monitoring, reducing operational overhead.
Azure Portal and CLI Touchpoints
In the Azure Portal, you can create an AKS cluster via "Create a resource" > "Containers" > "Kubernetes Service". For Azure Functions, go to "Function App". For API Management, search for "API Management services".
CLI examples:
Create an AKS cluster:
az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keysCreate a Function App:
az functionapp create --resource-group myResourceGroup --consumption-plan-location westeurope --runtime python --runtime-version 3.9 --functions-version 4 --name myFunctionApp --storage-account mystorageaccountDeploy a container to ACI:
az container create --resource-group myResourceGroup --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --dns-name-label mycontainer --ports 80Decompose Application into Services
Identify bounded contexts in your application. For example, in an e-commerce platform, separate services for inventory, orders, payments, and user profiles. Each service should have a single responsibility. Define APIs for inter-service communication. Avoid creating services that are too fine-grained, as that increases complexity. Azure API Management can help design and document these APIs.
Containerize Each Service
Package each service into a Docker container. Create a Dockerfile that specifies the base image, dependencies, and startup command. Build the image using `docker build`. Test locally. Push the image to Azure Container Registry (ACR) for secure storage. Containerization ensures consistency across environments and simplifies deployment.
Choose an Orchestrator
Decide between Azure Kubernetes Service (AKS) for complex orchestration or Azure Container Instances (ACI) for simple, serverless containers. AKS provides auto-scaling, load balancing, and rolling updates. ACI is ideal for batch jobs or event-driven tasks. For exam purposes, know that AKS is the recommended choice for production microservices.
Set Up API Gateway
Deploy Azure API Management as the single entry point for all client requests. Configure policies for authentication (e.g., OAuth2), rate limiting, and request transformation. The gateway routes requests to the appropriate microservice. This decouples clients from service endpoints and provides a centralized security layer.
Implement CI/CD Pipelines
Use Azure DevOps or GitHub Actions to automate building, testing, and deploying each microservice independently. Each service has its own pipeline. For example, when code is pushed to the 'product-service' repository, the pipeline builds the Docker image, runs unit tests, pushes to ACR, and deploys to AKS using kubectl. This enables frequent, safe updates.
Scenario 1: E-commerce Platform An online retailer with a monolithic application experiences slow release cycles and scaling inefficiencies. During Black Friday, the entire site must scale up even though only the product catalog and checkout services are under heavy load. The team decomposes the monolith into microservices: Product Catalog, Shopping Cart, Order Processing, Payment, and User Authentication. Each service runs in containers on AKS. The API Gateway (Azure API Management) handles authentication and routes requests. The Product Catalog service uses Cosmos DB for low-latency reads, while Order Processing uses Azure SQL. During peak traffic, auto-scaling rules increase the number of Product Catalog pods. The team can deploy updates to the Payment service independently without affecting other services. Cost is optimized by scaling down non-critical services during off-peak hours. A common mistake is not setting resource limits, causing one service to starve others.
Scenario 2: Financial Services Application A bank wants to modernize its loan processing system. The monolith is difficult to change and has frequent outages. They adopt microservices: Application Intake, Credit Check, Document Verification, and Approval. Each service is deployed in AKS with strict network policies using Azure Network Policies. Communication uses Azure Service Bus for asynchronous messaging, ensuring that if the Credit Check service is slow, the Application Intake service doesn't block. Azure Monitor and Application Insights provide end-to-end tracing. The team uses blue-green deployments to minimize downtime. A misconfiguration in the API Gateway could expose internal endpoints, so they implement OAuth2 and IP whitelisting. The bank saves costs by using reserved instances for baseline capacity and spot instances for batch processing.
Scenario 3: IoT Device Management A manufacturing company collects telemetry from thousands of IoT devices. The monolith cannot handle the volume. They create microservices: Device Registration, Telemetry Ingestion, Alerting, and Dashboard. Telemetry Ingestion uses Azure Functions (serverless) to scale automatically based on message volume. Device Registration uses Cosmos DB. Alerting uses Azure Logic Apps. The Dashboard service queries a read-only replica of the database. This architecture handles spikes in telemetry without provisioning excess capacity. A common problem is tight coupling between services; for example, the Dashboard directly calling the Telemetry service, causing cascading failures. The fix is to use asynchronous messaging or a separate data store.
Exam Objective: Describe cloud concepts (25-30%) – Objective 1.2: Describe microservices architecture.
The AZ-900 exam tests your ability to identify characteristics and benefits of microservices versus monolithic architecture. You will NOT be asked to design microservices or write code. Focus on understanding the core concepts.
Common Wrong Answers and Why Candidates Choose Them: 1. "Microservices always use a single shared database." – Wrong. A key principle is Database-per-Service to ensure loose coupling. Candidates confuse microservices with service-oriented architecture (SOA) where shared databases are common. 2. "Microservices are only suitable for large applications." – Wrong. Microservices can benefit small applications too, especially if they are expected to grow. Candidates think microservices add too much overhead for small apps. 3. "Microservices eliminate all communication failures." – Wrong. Distributed systems are inherently more complex; network failures are a reality. Candidates overestimate the reliability of microservices. 4. "Microservices require containers." – Not strictly true. Containers are a common deployment mechanism, but microservices can run on VMs or serverless. However, containers are the recommended approach.
Specific Terms and Values: - API Gateway: Know that it is a single entry point for clients. - Container orchestration: Azure Kubernetes Service (AKS) is the managed service. - Serverless: Azure Functions can implement microservices. - CI/CD: Continuous Integration and Continuous Delivery.
Edge Cases: - The exam might ask which Azure service is best for orchestrating microservices. Answer: AKS. - They might ask about the difference between microservices and serverless. Microservices are an architectural pattern; serverless is a compute model. You can have serverless microservices (e.g., Azure Functions).
Memory Trick: The M in Microservices = Multiple independent services, each with its own database. The M in Monolith = Massive single codebase.
Microservices are an architectural style where an application is composed of small, independent services that communicate via APIs.
Each microservice has its own database (Database-per-Service pattern) to ensure loose coupling.
Azure Kubernetes Service (AKS) is the primary managed orchestrator for containerized microservices.
Azure API Management acts as an API Gateway for routing, security, and rate limiting.
Microservices enable independent scaling, deployment, and failure isolation.
Serverless compute like Azure Functions can be used to implement microservices without managing servers.
Microservices are not always the best choice; they add complexity and are best for large, evolving applications.
These come up on the exam all the time. Here's how to tell them apart.
Monolithic Architecture
Single codebase and deployable unit
Scales as a whole (all components)
Tight coupling between components
Shared database (single point of failure)
Slower release cycles (full redeployment)
Microservices Architecture
Multiple independent services
Scales individual components independently
Loose coupling via APIs
Each service has its own database
Faster, independent deployment cycles
Mistake
Microservices always use REST APIs for communication.
Correct
While REST is common, microservices can use any communication protocol, including gRPC, message queues (Azure Service Bus), or event-driven patterns (Event Grid). The key is loose coupling, not the protocol.
Mistake
Microservices are the same as service-oriented architecture (SOA).
Correct
SOA typically uses an enterprise service bus (ESB) and shared databases. Microservices emphasize decentralized data management, lightweight communication, and independent deployment. SOA is often more heavyweight.
Mistake
Microservices automatically improve performance.
Correct
Microservices can introduce network latency and complexity. Performance depends on design. Overly fine-grained services increase overhead. Proper caching, async patterns, and data denormalization are needed.
Mistake
You must use containers to implement microservices.
Correct
Containers are a common deployment method, but microservices can run on VMs, Azure App Service, or Azure Functions. Containers provide consistency and ease of scaling, but they are not mandatory.
Mistake
Microservices eliminate the need for a database.
Correct
Each microservice typically has its own database. This is the Database-per-Service pattern. Microservices do not eliminate databases; they distribute them to avoid a single point of failure.
In a monolith, all features are in one codebase and deployed as a single unit. In microservices, the application is split into small, independent services. Monoliths are simpler to develop initially but harder to scale and maintain. Microservices allow independent scaling, deployment, and fault isolation, but introduce network complexity. For AZ-900, remember that microservices enable agility and scalability.
Azure Kubernetes Service (AKS) is the recommended service for orchestrating containerized microservices. It provides automated deployment, scaling, and management of containers. For simpler scenarios, Azure Container Instances (ACI) or Azure Functions can be used. The exam expects you to know AKS as the primary orchestration tool.
No, microservices can be deployed on VMs, Azure App Service, or as serverless functions. However, containers are the most common and recommended approach because they provide a consistent runtime environment, simplify scaling, and integrate well with orchestration tools. For the exam, know that containers are a common enabler but not a requirement.
An API Gateway is a single entry point for client requests. It routes requests to the appropriate microservice, handles authentication, rate limiting, and request aggregation. In Azure, Azure API Management provides this functionality. The exam may test that the gateway simplifies client interaction and adds a security layer.
In a pure microservices architecture, each service has its own database to ensure loose coupling. Sharing a database creates tight coupling and defeats the purpose. However, in practice, some teams use shared databases for simplicity, but this is considered an anti-pattern. For the exam, remember the Database-per-Service pattern.
Microservices introduce complexity: network latency, distributed data management, service discovery, and inter-service communication failures. They require robust monitoring and DevOps practices. The overhead of managing many services can be higher than a monolith. The exam may test that microservices are not always the best choice, especially for small applications.
Azure provides a full ecosystem: Azure Kubernetes Service (AKS) for orchestration, Azure Container Registry for storing container images, Azure API Management for API Gateway, Azure Service Bus for messaging, Azure Cosmos DB for distributed databases, and Azure Monitor for observability. Azure DevOps enables CI/CD pipelines. The exam expects familiarity with these services.
You've just covered Microservices Architecture Concepts — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?