Microservices is an approach to building software in which an application is made up of many small, independent services, each responsible for one business function, such as payments, search or user accounts. Each service runs as its own process, can be developed and deployed independently, whether its code sits in a separate repository or a shared one, often has its own data, and talks to the others over the network through defined interfaces, usually APIs. Services can be updated, deployed and scaled separately, which is the main reason organizations adopt the approach and also the source of most of its costs.
At a glance
- An application is split into small services, each owning one function and often its own data.
- Services communicate over the network through APIs or messaging, rather than through calls inside one program.
- Each service can be released and scaled on its own, often by a separate team.
- Commonly run in containers on an orchestration platform, though not required.
- Adds operational complexity: more components to deploy, monitor, secure and pay for.
What problem it solves
Traditional applications are often built as one large program, a monolith, where all functions are packaged and deployed together. As the application and its development team grow, that becomes a bottleneck. A small change to one feature means testing and redeploying everything; a busy feature can only be scaled by running more copies of the whole application; and one fault can bring the entire system down. Many teams working in one code base slow each other down.
Microservices break that coupling. Teams can change and release their service without coordinating a big release, scale only the parts under load, and use different technologies where it makes sense. A failure in one service can be contained instead of taking down the whole application, if the design allows for it. For organizations building and running large digital products, this can speed up development and improve resilience.
How it works
Service boundaries. The application is divided around business functions. Each service has a clear interface and, ideally, owns its own data store, so other services do not reach into its database directly.
Communication. Services call each other over the network using APIs, or exchange messages and events through a message queue or streaming platform. Each call can fail or be slow, so services are designed to handle timeouts and retries.
Packaging and running. Services are commonly packaged as containers and run on an orchestration platform that schedules, scales and restarts them, which is where container management comes in. Some services run as serverless functions or on a platform as a service.
Automation. With dozens or hundreds of services, manual deployment becomes impractical. Teams rely on automated build and release pipelines and infrastructure as code, core DevOps practices.
Observability. Following a single user request across many services requires centralized logging, metrics and distributed tracing, usually through application performance monitoring and observability tools.
Security. More services means more network interfaces to protect. Traffic between services is often encrypted and authenticated, and APIs exposed to the internet need web application and API protection.
Our public cloud page covers the platforms most microservices applications run on.
When it matters for buyers
- Commissioning or buying custom software. A development partner’s choice of architecture shapes hosting, tooling and staffing costs long after delivery.
- Modernizing legacy applications. Breaking a monolith into microservices is one option during cloud migration; it is costly and not right for every application.
- Cloud cost reviews. Many small services, each with minimum capacity, plus monitoring and data transfer, can add up; check where the spend goes.
- Choosing monitoring and security tools. Microservices typically need distributed tracing and API security that simpler applications may not.
- Evaluating SaaS and platform vendors. Vendors often cite microservices to suggest scalability and reliability; ask for evidence such as uptime history and release practices instead.
Questions to ask vendors
- Why is microservices the right architecture for this application, and what simpler option did you consider?
- How many services will there be, and who will own and operate each one after delivery?
- Where will the services run, and what will hosting, monitoring and data transfer cost at our expected load?
- How will we trace a problem across services, and which tools are included?
- How is communication between services secured and authenticated?
- How do you handle a failing service so it does not cause failures elsewhere?
- What skills will our team need to support this, and what documentation will we receive?
How it differs from cloud-native and containers
Cloud-native is a broader approach to building and running applications that take full advantage of cloud environments: automation, elastic capacity and managed services. Microservices is one common design pattern within it, but a cloud-native application does not have to be split into microservices. Containers, and the container management platforms that run them, are packaging and runtime technology. They are the usual home for microservices but can equally run a single large application. In short: microservices describe how the application is divided, containers describe how it is packaged and run, and cloud-native describes the overall approach.