This chapter introduces microservices architecture at a conceptual level. AZ-900 tests this under objective 1.2, as one of several modern application architecture concepts.
Jump to a section
A simple way to picture Microservices Architecture Concepts
A single giant kitchen preparing an entire restaurant's menu means if one part of that kitchen breaks down, the whole menu might be affected. A food court made up of independent stalls — each responsible for one type of dish — means a problem at one stall doesn't stop the others from serving customers, and each stall can be updated, staffed, or scaled independently. Microservices architecture applies the same idea to software: instead of one large, tightly connected application, the application is broken into smaller, independent services, each responsible for a specific function.
What microservices architecture is
Microservices architecture structures an application as a collection of small, independent services, each responsible for a specific piece of functionality, rather than one large, tightly interconnected application (often called a "monolith").
Key characteristics
Independent deployment: each microservice can be updated or deployed without necessarily affecting the others.
Independent scaling: a specific microservice experiencing heavy demand can be scaled independently, without scaling the entire application.
Loose coupling: services typically communicate through well-defined interfaces (often APIs or messaging, connecting to the Service Bus concepts covered earlier), rather than being tightly interconnected internally.
How this compares to a monolithic application
A monolithic application bundles all functionality together as a single unit — simpler to build initially, but a single change or failure can affect the entire application, and scaling means scaling everything together, even parts that don't need it.
Why this matters for cloud computing
Microservices architecture pairs well with cloud computing's emphasis on scalability and flexibility, since individual services can take advantage of features like autoscaling and containers (covered in their own chapters) independently, rather than the whole application scaling as one unit.
Break the application into independent services
Functionality is divided into smaller, independent services, each responsible for a specific piece of the overall application.
Define communication between services
Services communicate through well-defined interfaces, like APIs or messaging services, rather than being tightly interconnected internally.
Deploy and scale services independently
Each service can be updated, deployed, or scaled on its own, without necessarily affecting the rest of the application.
An e-commerce application splits its checkout, inventory, and recommendation functionality into separate microservices, allowing the team to scale up just the checkout service during a big sale, without needing to scale the entire application together.
Objective 1.2 expects a conceptual understanding of microservices architecture — independent, loosely coupled services — contrasted with a traditional monolithic application.
A common wrong answer is describing microservices as simply "a smaller application" — the key distinguishing trait is the independence and loose coupling between services, not just smaller overall size.
Stable terms: microservices, monolith. Memory trick: microservices = many small, independently deployable and scalable services, loosely connected — versus one large, tightly bundled monolithic application.
Microservices architecture structures an application as a collection of small, independent services, each responsible for specific functionality.
Key traits include independent deployment, independent scaling, and loose coupling between services.
This contrasts with a monolithic application, where all functionality is bundled together as a single unit.
Microservices pair well with cloud computing's scalability features, since individual services can scale independently.
These come up on the exam all the time. Here's how to tell them apart.
Monolithic Application
Single, tightly interconnected application
Scales and deploys as one unit
Simpler to build initially
Microservices Architecture
Multiple small, independent services
Each service can scale and deploy independently
More flexible, but more architectural complexity
Mistake
Microservices just means a smaller application overall.
Correct
The defining trait is independence and loose coupling between services — each can be deployed and scaled on its own — not simply having a smaller overall codebase.
Mistake
A monolithic application is always the wrong choice.
Correct
Monolithic applications can be simpler to build and manage initially — the right architecture depends on the specific application's needs and scale, not a universal preference for microservices.
It's an approach to structuring an application as a collection of small, independent services, each responsible for a specific function, rather than one large, tightly interconnected application.
A monolithic application bundles all functionality together as a single unit, deploying and scaling as one piece. Microservices architecture breaks functionality into independent services that can each be deployed and scaled on their own.
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?