Loading...
Split the application into small independent services that ship and scale separately.
Quick Definition
Microservices is an architectural style that structures an application as small, independently deployable services communicating over APIs. It enables scalability and team autonomy but increases operational and networking complexity, with distributed cost and observability challenges.
Microservices is an architecture style that breaks an application into small, independently deployable services, each owning one capability and communicating over the network. Teams ship their services on their own schedules, scale them independently, and contain failures within smaller blast radii.
The economics cut both ways. Independent scaling means you grow only the busy parts: scale checkout for the sale, not the whole monolith. But every service carries overhead, a deployment, monitoring, often its own balancer and datastore, and inter-service chatter creates network and cross-zone traffic charges a monolith never pays. Too many tiny services is its own waste pattern.
Example. A retailer's search service needs 10 times the capacity of its account service. As a monolith, everything scaled together at peak size. As services, each scales to its own demand, cutting compute spend by a quarter while improving search performance.
Allocation by service also becomes natural, which is why microservices and cost allocation pair well. See the container orchestration primer and the Kubernetes Cost Management Guide for the platform that usually runs them.
Sometimes. Independent scaling saves money; per-service overhead and network traffic spend it. Granularity should match team and traffic reality.
Big enough to own a meaningful capability, small enough for one team to own completely. Counting lines of code misses the point.
Network traffic between services, duplicated infrastructure overhead, and the observability needed to debug distributed behavior.