Introduction
Microservices architecture splits an application into a collection of small, independently deployable services, each responsible for a single business capability, instead of building one large monolithic codebase. Cloud platforms did not invent microservices, but managed cloud services — container orchestration, serverless compute, service discovery, and API gateways — removed much of the operational burden that made microservices hard to run at scale.
Cricket analogy: A national team splitting duties across a dedicated batting coach, bowling coach, and fielding coach rather than one overworked head coach mirrors microservices splitting an app into focused services, and cloud tools like managed containers and API gateways removed much of the burden of running that specialist structure at scale.
Explanation
In a monolith, all functionality lives in one codebase and one deployable unit: a single change requires redeploying the entire application, and all internal calls are simple in-process function calls. In a microservices architecture, each service is deployed independently — a team can update the 'orders' service without touching or redeploying 'inventory' or 'payments'. This deployment independence is powerful but introduces a new problem: since services are separate processes (often on separate machines), what used to be an in-process function call now becomes a network call between services, with all the latency, failure modes, and versioning concerns that implies.
Cricket analogy: A club with a single administrative office redeploys everything to change one policy, with all requests handled in person; splitting into an independent ticketing office and a separate coaching office means updating ticketing rules doesn't touch coaching, but now the two offices must phone each other instead of shouting across the same room, introducing delay and version mismatches.
Cloud platforms provide the building blocks that make this manageable. Managed container platforms (e.g. Kubernetes-based services or managed container runtimes) or serverless functions let each microservice be deployed, scaled, and billed independently without a team having to manage the underlying servers. Service discovery lets a service find the current network location of another service even as instances are created and destroyed dynamically. An API gateway sits in front of the services, providing a single entry point for external clients that handles routing, authentication, rate limiting, and request aggregation, so client applications don't need to know about the internal service topology.
Cricket analogy: Managed container platforms let a board deploy its scoring service without owning servers; service discovery lets the commentary team find the current stats service even as instances change; an API gateway is the single media desk that handles all journalist requests, routing them internally without reporters needing to know the backend structure.
Example
E-commerce app as microservices:
┌────────────────┐
Client ──►│ API Gateway │
└───────┬────────┘
┌───────────┼───────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Orders │ │ Inventory│ │ Payments │
│ service │ │ service │ │ service │
│ (managed │ │ (serverless│ (managed │
│ containers)│ function) │ containers)│
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ network call via │
└───► service discovery ◄─┘
Deploying a new version of 'Inventory' does not
require redeploying 'Orders' or 'Payments'.Analysis
The trade-off is clear: microservices gain independent deployability, independent scaling (the Orders service can scale separately from Payments during a sale), and technology flexibility (each service can use a different language or datastore). In exchange, teams take on distributed-systems complexity — network calls can fail or time out where a function call couldn't, request tracing across services is harder, and data consistency across services requires careful design (often eventual consistency instead of a single database transaction). Cloud-managed services reduce the operational cost of that trade-off but do not eliminate the architectural complexity of designing well-bounded services and handling network failures gracefully.
Cricket analogy: Splitting scoring and commentary into separate services lets the scoring team push a fix during a live match while commentary is unaffected, and each can use different tools — but now a scoring glitch that used to be a simple bug becomes a network timeout to diagnose, and reconciling live stats with the final scorecard needs careful design instead of one shared record.
Key Takeaways
- Microservices split an application into small, independently deployable services, unlike a monolith's single deployable unit.
- What used to be an in-process function call in a monolith becomes a network call between services in a microservices architecture.
- Managed containers/serverless, service discovery, and API gateways are the cloud building blocks that make microservices operationally practical.
- The trade-off is independent deployability and scaling versus added distributed-systems complexity (network failures, tracing, data consistency).
Practice what you learned
1. What fundamentally changes when moving from a monolith's internal function calls to a microservices architecture?
2. What is the role of an API gateway in a microservices architecture?
3. What does service discovery solve in a microservices deployment?
4. Which of the following is a genuine trade-off introduced by microservices compared to a monolith?
Was this page helpful?
You May Also Like
Container Orchestration Basics
Understand what container orchestrators like Kubernetes do — scheduling, self-healing, scaling, and service discovery — and core concepts like Pods, Deployments, and Services.
Serverless Computing
Understand Function-as-a-Service (FaaS), event-driven execution, per-invocation billing, and the cold-start tradeoff behind serverless computing.
Load Balancing in the Cloud
Learn how cloud load balancers distribute traffic across instances using Layer 4 and Layer 7 techniques and health checks.
Auto-Scaling Basics
Learn the difference between horizontal and vertical auto-scaling and how scaling policies use metrics like CPU utilization to trigger scaling actions.